#9759 closed Bugs (fixed)
boost::geometry::index::rtree does not work properly spherical_equatorial
Reported by: | Owned by: | Barend Gehrels | |
---|---|---|---|
Milestone: | To Be Determined | Component: | geometry |
Version: | Boost 1.55.0 | Severity: | Problem |
Keywords: | Cc: |
Description
When spherical_equatorial coordinate system is used with index::rtree, the query(nearest) gives wrong results.
My example insert 30.000 waypoint and query(nearest) mostly returns point east of the query point. When using cartesian, it works ok, except for the expected domain mismatch. Tested with boost 1.55.0 on Linux with g++ 4.4.3 and g++ 4.6.3 (identical results). The attached map plots shows the results from the two tests (cartesian and spherical_equatorial). Full source code, inclduing all waypoint data available upon request.
typedef bg::model::point<double, 2, bg::cs::cartesian> geo_point_ok; typedef bg::model::point<double, 2, bg::cs::spherical_equatorial<bg::degree> > geo_point; typedef std::pair<geo_point, unsigned int> geo_vg_value; void test() { double lon=10.0, lat=60.0 geo_point pt(lon, lat); rtree.insert(std::make_pair(pt, wp->id)); std::vector<geo_vg_value> result; geo_point here(targetLat, targetLat); rtree.query(bgi::nearest(here, 20), std::back_inserter(result)); }
Attachments (3)
Change History (6)
by , 9 years ago
Attachment: | boost-geometry-with-cartesian.jpg added |
---|
by , 9 years ago
Attachment: | boost-geometry-with-spherical.jpg added |
---|
Result from query(nearest) with spherical_equatorial
comment:1 by , 8 years ago
The geometry::comparable_distance() is now used in the rtree nearest query so this should be fixed.
by , 8 years ago
Attachment: | spherical_equatorial.cpp added |
---|
Test file finding the nearest neighborsusing the rtree and std::sort()
comment:2 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Version: | Boost 1.55.0 → Boost 1.56.0 |
I attached a test file containing the code searching for the nearest neighbours using the rtree and std::sort(). The input data contains the values for which the query failed for the user plus a big number of random values. The result is the same in both cases.
Furthermore I'm guessing that the problem isn't caused by the way how comparable_distance() was calculated. Before 1.56 the cartesian comparable_distance() was always used so the result of a query should be the same as for the cartesian Points. But since this behavior was invalid I'm closing this ticket as 'fixed', not 'worksforme'.
comment:3 by , 8 years ago
Version: | Boost 1.56.0 → Boost 1.55.0 |
---|
Result from query(nearest) with cartesian