Subject: Re: [geometry] R-tree spacial predicates (intersects(Ring) ...) in boost 1.59 upwards
From: Mike Vasiljevs (mike.vasiljevs_at_[hidden])
Date: 2016-05-11 08:53:32
Adam, many thanks for the answer!
On 11 May 2016, at 11:43, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
> 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
> you could use
> bgm::point<double, 2, bg::cs::cartesian>
> unfortunately this is also true for user-defined Point types.
Indeed it does compile with with bgm::point<..,2,..>.
> 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.
Indeed I am doing now exactly this!
> 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?
Good point too. In my case no holes (rings) and probably very few thin arms, if any. Though I will create more test cases do a few performance tests at some point.
Geometry list run by mateusz at loskot.net