Boost logo

Geometry :

Subject: [ggl] boost geometry rtree
From: Barend Gehrels (barend)
Date: 2011-07-11 12:24:08

> Barend Gehrels wrote:
>> On 9-7-2011 13:30, Adam Wulkiewicz wrote:
>>> Barend Gehrels wrote:
>> They are not used for, for example, calculating the area of a point (0),
>> linestring (0) and also not for a box (though that might change).
> Yes, the area of a box must be calculated in my case.

Sorry, you did not get the point. Of course area-of-a-box is implemented.

>> Within does already work for point/box and box/box for *all* dimensions.
>> What is happening is that you (probably) need >= instead of >, like
>> Frank does. That will be solved soon.
> Operator doesn't matter. The querry may return values which aren't on border. within() didn't compile for some reason I can't remember why.

OK. Anyway, it should, so please report if it does not.

> I now realised there should be additional queries. For objects within and overlapping/intersecting some other object. Both with/without borders. The best would be to have only one spatial_filter and use some additional technique, e.g. parameters, manipulators, filters, tags to enable specific behaviour.
>> About area, do you need that for a 3D box? You need probably the volume
>> of a box there?
> Yes for 3d I use the volume of a box. The thing is I calculate generalized volume of a n-dimensional box. I just used 'area' name for this but 'volume' is probably better because it referes to 'hypervolume'. Other possible names are hypervolume or content

Content is the right word for that. It was reserved for that but it was not implemented.

> ( because in dimensions greater than 4 3d volume may have different meaning. Hypersurface of a 4d object is 3-dimensional and someone may call it the volume, like 2d surface of a 3d object is called the surface.
> I use also a function calculating the margin of a box (this term is taken from: R*tree: An Efficient and Robust Access Method for Points and Rectangles by Beckmann at al.). I assumed that this is nD hypersurface so for 2d it's the perimeter of a box, for 3d it's surface, for 4d it's 3d hypersurface etc. (

OK, good idea. If "margin" is the right term for that, we should use that. Thanks.

>> I would like the spatial index to use the "official" algorithms and not
>> adapted ones. If the official do not suffice, please notify that and we
>> can solve that. Now that the Release is nearly there, we can concentrate
>> on these kind of things again.
> I'm happy to hear that :)
> I use also a function calculating squared distance between points. This could be usefull to the others as well. Comparing two distances is common thing and it's faster to do this without calculating sqrt.

This is the "comparable_distance" which is implemented long ago. Please use that one, I prefer that index is using the standard functionality instead of its own ones. Again, if something is not working the way you expect, please report that.

Regards, Barend

Geometry list run by mateusz at