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" wrote:

...

2014-07-29 3:07 GMT+02:00 Jeremy Murphy :

...

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