[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [geometry] Querying for Points nearest to a Segment.
From:       Menelaos Karavelas <menelaos.karavelas () gmail ! com>
Date:       2014-07-30 8:43:00
Message-ID: 53D8B014.2050701 () gmail ! com
[Download RAW message or body]

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@gmail.com> 
>> wrote:
>>
>>> 2014-07-29 3:07 GMT+02:00 Jeremy Murphy 
>>> <jeremy.william.murphy@gmail.com>:
>>>
>>>> Veering slightly off topic but still related to Geometry development,
>>> I've
>>>> hit some hurdles with the rtree index.  I could create an index of 
>>>> points
>>>> easily but then couldn't query for the nearest neighbour of a segment.
>>>   (I
>>>> 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?
>>>
>> 1.55.
>>
>>   Ahh, I had an almost identical test program except for one line.  I 
>> had:
>>
>>      typedef boost::geometry::model::d2::point_xy<double> Point;
>>
>> Is that type meant to have different behaviour to the general point 
>> model?
>
> 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 
bg::model::point<...>.

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.

Best,

- m.


> In any case it will be fixed in develop and you will be able to use 
> either one of the point models in discussion.
>
> Best,
>
> - m.
>
>> Thanks for your help, cheers.
>>
>> Jeremy
>>
>> _______________________________________________
>> Unsubscribe & other changes: 
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]