Geometry Boost List: [ggl] boost geometry rtree

Subject: [ggl] boost geometry rtree
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-07-11 03:05:17

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.

> 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.

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 
(http://mathworld.wolfram.com/Content.html) 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. (http://mathworld.wolfram.com/Hypersurface.html).

> 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.

>> rtree<Value, linear<8, 4> > t;
>
> I like it! I will look to the indexes soon again. We need to move them
> to the Trunk once, if they are stable w.r.t. interface.

There will possibly be one additional, optional template and constructor 
parameter - the allocator.

Regards,
Adam