Geometry Boost List: Re: [geometry] R-tree spacial predicates (intersects(Ring) ...) in boost 1.59 upwards

Subject: Re: [geometry] R-tree spacial predicates (intersects(Ring) ...) in boost 1.59 upwards
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2016-05-11 06:43:45

Hi Mike,

Mike Vasiljevs wrote:
> Good day to everyone,
>
> Tried the latest boost versions, however *rtree insersects query* does 
> not accept ring, polygon and multipolygon any more - since 1.59 - when 
> applied on boxes. However it is still present in the documentation 
> (http://www.boost.org/doc/libs/1_60_0/libs/geometry/doc/html/geometry/spatial_indexes/queries.html#geometry.spatial_indexes.queries.spatial_predicates).
>
> One could run a query on R-tree of boxes using a ring in boost 1.58.0 
> but not any longer. I could not find any relevant discussion but 
> perhaps there is a good reason for this?
>

Thanks for the info! No, this is a bug. Could you please report it here 
(https://svn.boost.org/trac/boost/newticket)?

As a workaround, instead of using
bgm::d2::point_xy<double>
you could use
bgm::point<double, 2, bg::cs::cartesian>
unfortunately this is also true for user-defined Point types.

Have in mind that typically running a query passing complex Geometries 
like Polygons is not advised. Typically one would perform a query using 
only boxes (so envelopes of Polygons) to perform intersection tests with 
nodes and values as fast as posible. Then perform intersection tests for 
Geometries represented by boxes returned by the query and the original 
Polygon.

Furthermore, currently a copy of geometry is kept inside a predicate 
object, so potentially big Polygon can be copied. Though I susspect that 
compiler could optimize it.

But indeed if areas of polygons and their envelopes differed greately 
and many nodes/values could be pruned when Polygon was passed instead of 
its evelope then the speed might be better. So in other words if 
polygons was "big" but had small areas, had wierd shapes (thin arms) 
and/or big/many holes. Do you have such use case or are you passing 
Polygons into a query from a different reason? E.g. have you measured 
that this approach is faster?

Regards,
Adam