Subject: Re: [boost] [geometry] Querying for Points nearest to a Segment.
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2014-07-30 04:43:00
Hi again Jeremy.
On 30/07/2014 10:59 ÏÎ¼, Menelaos Karavelas wrote:
> Hi Jeremy.
> On 30/07/2014 05:30 ÏÎ¼, Jeremy Murphy wrote:
>> On 29/07/2014 11:46 AM, "Adam Wulkiewicz" <adam.wulkiewicz_at_[hidden]>
>>> 2014-07-29 3:07 GMT+02:00 Jeremy Murphy
>>>> Veering slightly off topic but still related to Geometry development,
>>>> hit some hurdles with the rtree index. I could create an index of
>>>> easily but then couldn't query for the nearest neighbour of a segment.
>>>> assume this is simply not supported at present; is it
>>>> forthcoming?) So I
>>>> created a ring or polygon from the segment and tried to query for the
>>>> points that it covers/intersects, which is a feature listed in the
>>>> documentation, but I've hit this compilation error:
>>> Which version of Boost are you using?
>> Ahh, I had an almost identical test program except for one line. I
>> typedef boost::geometry::model::d2::point_xy<double> Point;
>> Is that type meant to have different behaviour to the general point
> No, it should behave the same, and in that sense you have stumbled
> upon a bug.
> I reproduced the error, and I know how to fix it.
> I expect to create a PR for that within the day. I still have not
> figured out yet why
The PR is ready: https://github.com/boostorg/geometry/pull/119
> there is a need for a fix, so please bare with me until I can give you
> a more complete status report.
So here is the story: as part of the calls made by intersects (one of
your queries), there is struct called collinear_opposite that has a
set_tp method (that is called eventually by intersects) expecting a
single point type as the type of several of its arguments.
However, it is called with, in principle, two potentially different
point types (and my fix does that: it enables set_tp to be called by two
different point types).
Now when you call it from within rtree with bg::model::point_xy<...> as
your point type you have a case where it is called indeed with two
different point types: one your own point type, and the other is the
point type used for the boxes stored in the rtree, which is
In Adam's code example you do not see the problem since the point type
he uses is the same as the one used internally in the rtree and
therefore the problem does not appear.
I hope it makes sense.
> In any case it will be fixed in develop and you will be able to use
> either one of the point models in discussion.
> - m.
>> Thanks for your help, cheers.
>> Unsubscribe & other changes: