bg::cs::geographic and nearest query
Hi all!
I need to store geographic points in rtree and be able to answer nearest
query.
Can someone provide an example similar to this
https://www.boost.org/doc/libs/1_65_1/libs/geometry/doc/html/geometry/spatia...
but with point type bg::model::point
Hi, W dniu 14.10.2019 o 16:57, vexakul via Boost-users pisze:
Hi all!
I need to store geographic points in rtree and be able to answer nearest query.
Can someone provide an example similar to this https://www.boost.org/doc/libs/1_65_1/libs/geometry/doc/html/geometry/spatia... but with point type bg::model::point
>? Is that supported? For me it fails to compile. When you define the geographic point as R-tree element type the computation should be done in geographic CS by default using WGS84 ellipsoid and andoyer formula to calculate distances. So simply:
using boost::geometry;
using point = model::point
The tree itself compiles just fine. It's the nearest query that fails. Here is a minimal not working example. I'll send output as an attachment. What bothers me is Strategy=int in the output.
#include
Hi,
W dniu 14.10.2019 o 16:57, vexakul via Boost-users pisze:
Hi all!
I need to store geographic points in rtree and be able to answer nearest query.
Can someone provide an example similar to this https://www.boost.org/doc/libs/1_65_1/libs/geometry/doc/html/geometry/spatia... but with point type bg::model::point
>? Is that supported? For me it fails to compile. When you define the geographic point as R-tree element type the computation should be done in geographic CS by default using WGS84 ellipsoid and andoyer formula to calculate distances. So simply:
using boost::geometry;
using point = model::point
; using rtree = index::rtree
>; rtree rt;
// or
std::vector<point> pts;
rtree rt2{pts.begin(), pts.end()};
If you need different ellipsoid or more accurate formula it is also possible (since Boost 1.71) though it is not documented. It's because I'm not entirely sure what to do with the fact that with this approach the EqualTo is called with two or three arguments depending on the parameters passed into the R-tree so it may be confusing. So there is slight probability that the interface will change in case I found some better way of defining CS-specific parts of the computation. So if you e.g. need to pass a different ellipsoid you can wrap the R-tree parameters together with Index strategy and pass it into the R-tree like that:
using boost::geometry;
using formula = strategy::andoyer;// or more accurate strategy::vincenty srs::spheroid<double> sph(6378137.0, 6356752.3142451793);
using point = model::point
; using parameters = index::parameters < index::rstar<4>, strategy::index::geographic<formula> >; using rtree = index::rtree
; rtree rt{parameters{index::rstar<4>{}, strategy::index::geographic<formula>{sph}}};
// or
std::vector<point> pts;
rtree rt2{pts.begin(), pts.end(), parameters{index::rstar<4>{}, strategy::index::geographic<formula>{sph}}};
Have in mind that I didn't test the code above so there may be some mistakes.
Adam
W dniu 14.10.2019 o 20:21, Sergey Lukashev pisze:
The tree itself compiles just fine. It's the nearest query that fails. Here is a minimal not working example. I'll send output as an attachment. What bothers me is Strategy=int in the output.
This error message means that the geographic strategy for calculating the distance between point and box is not implemented or at least bg::strategy::distance::services::default_strategy (a utility used to get the type of default strategy for distance algorithm) for point and box is not specialized. This code compiles for me with boost-1.67.0 and newer for sure, maybe with 1.65 and/or 1.66. I get the same message as you with 1.64.0. Which version are you testing? Adam
1.65.1
14.10.2019, 23:10, "Adam Wulkiewicz"
W dniu 14.10.2019 o 20:21, Sergey Lukashev pisze:
The tree itself compiles just fine. It's the nearest query that fails. Here is a minimal not working example. I'll send output as an attachment. What bothers me is Strategy=int in the output.
This error message means that the geographic strategy for calculating the distance between point and box is not implemented or at least bg::strategy::distance::services::default_strategy (a utility used to get the type of default strategy for distance algorithm) for point and box is not specialized.
This code compiles for me with boost-1.67.0 and newer for sure, maybe with 1.65 and/or 1.66. I get the same message as you with 1.64.0. Which version are you testing?
Adam
I will but I'm afraid I cannot update Boost right now. Could you come up with a workaround for this version to define the strategy?
--
Kind regards, Sergey.
14.10.2019, 23:24, "Adam Wulkiewicz"
W dniu 14.10.2019 o 22:19, Sergey Lukashev pisze:
1.65.1
Right, could you check at least 1.67.0 or preferably the latest one (1.71.0)?
Adam
W dniu 14.10.2019 o 22:58, Sergey Lukashev pisze:
I will but I'm afraid I cannot update Boost right now. Could you come up with a workaround for this version to define the strategy? Not really. The easiest would be to update Boost to newer version.
You could get the files from the newer version of Boost: https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/str... https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/str... together with all other files that are needed by these two. I can't guarantee that it will work. You'd have to take care about it by yourself. And seeing how many files were changed in the pull request adding these strategies it wouldn't be trivial: https://github.com/boostorg/geometry/pull/438/files What makes it even harder is that it may depend on other changes made before and after it. But I guess you could try to traverse the header files and copy them from the newer version to the point when the code starts to compile and the program calculates correct results. But it is not guaranteed that the library will work this way. Using newer Boost.Geometry with the older rest of Boost is not an option because some libraries we depend on changed around 1.65/1.66 so you'd have to update them too. Approximating the computation with spherical CS is also not an option because I think the spherical strategies were added as well at this point. You can check it out by replacing cs::geographic with cs::spherical_equatorial. Adam
participants (3)
-
Adam Wulkiewicz
-
Sergey Lukashev
-
vexakul