Boost C++ Libraries: Ticket #11987: Cannot find any way remove from an rtree if using a geographic type https://svn.boost.org/trac10/ticket/11987 <p> I cannot find any supported way to remove objects from an rtree using a 2d geographic type. I do see where Cartesian 2d works. No matter what method I try, it compiles with unsupported. I would like to remove as fast a possible, but I cannot even seem to find a way to search the whole rtree by values (instead of bounds and a value) to remove something. Maybe an rtree with geographic types is really experimental and not ready to be used? </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/11987 Trac 1.4.3 Barend Gehrels Sun, 28 Feb 2016 09:39:58 GMT owner changed https://svn.boost.org/trac10/ticket/11987#comment:1 https://svn.boost.org/trac10/ticket/11987#comment:1 <ul> <li><strong>owner</strong> changed from <span class="trac-author">Barend Gehrels</span> to <span class="trac-author">awulkiew</span> </li> </ul> Ticket awulkiew Thu, 10 Mar 2016 04:52:00 GMT status, milestone changed; resolution set https://svn.boost.org/trac10/ticket/11987#comment:2 https://svn.boost.org/trac10/ticket/11987#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> <li><strong>milestone</strong> <span class="trac-field-old">To Be Determined</span> → <span class="trac-field-new">Boost 1.61.0</span> </li> </ul> <p> It's because some required operations was not implemented for this CS. In this case (<code>remove()</code>) <code>covered_by()</code> was not implemented. It should be fixed in 1.61 at least for Points and Boxes, see: </p> <p> <a class="ext-link" href="https://github.com/boostorg/geometry/pull/345"><span class="icon">​</span>https://github.com/boostorg/geometry/pull/345</a> </p> <p> This bug should also be fixed in develop and master branches so you could pick the library from the repository if you need it now. </p> <p> Furthermore, some other algorithms might not work correctly for some cases in 1.60, e.g. when an rtree spanned across more than a half of a globe (bounds width &gt;= 180deg) or when stored boxes could cross antimeridian (e.g. longitude min-max = 170-190). So spatial predicates might not work correctly in such cases. </p> <p> So yes, it basically means that in 1.60 you could e.g. calculate boxes with <code>bg::envelope()</code> in geographic but then convert boxes to cartesian and store them in the rtree. And if you know that boxes could cross antimeridian perform some of the queries near the antimeridian 2 times, one for negative coordinates near -180 and the second one for corresponding coordinates greater than 180. </p> Ticket