Geometry Boost List: [ggl] boost geometry rtree

Subject: [ggl] boost geometry rtree
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-07-09 14:10:49

Barend Gehrels wrote:
> Hi Adam,
>
> On 9-7-2011 2:37, Adam Wulkiewicz wrote:
>>
>> Yes, this is because geometry::area don't work for all types it should.
>
> ??? geometry::area works for all types.
>
>> Try using model::point instead of model::d2::point_xy.
>
> So it also works for point_xy. If there is something not compiling, it
> is not because of the area.
>

I didn't want to dive into internals. Sorry for this generalization. 
Isn't it just some not implemented default strategy related to 
geometry::area?

>>
>> You can also try different rtree's implementation which you can find
>> here: https://svn.boost.org/svn/boost/sandbox-branches/geometry/index.
>> Interface is slightly different, e.g. elements numbers, and used
>> algorithms are passed as template arguments. Just check the examples
>> in geometry/index/tests.
>
> I agree, this should be tried, but does that work for point_xy? I assume
> so?
>

Yes, it works for point_xy and for points in arbitrary dimension because 
I'm using my own simplified versions of functions I need (e.g. area and 
within). They don't fits into the official interface, don't use 
strategies and works for all types implementing point/box concept. I've 
implemented them because rtree should work for all dimensions and since 
they're just temporaries will probably be removed later after the 
official functions will work for dimensions greather than 2.

>> Btw, I've implemented this new interface and moved repository as
>> described above. Since elements numbers are known in compile time
>> boost::arrays may be used instead of std::vectors but one can't pass
>> parameters to the rtree in run-time. There is new type of nodes
>> implemented which the tree creation is faster for and it takes less
>> memory space. Thoughts?
>
> I'm not sure if I understand you, but I've suggested compile-time
> parameters earlier and I thought it was not possible because you don't
> know the depth of rtree-levels before. Or do I confuse things?

If I remember correctly It was about using a static-size array as a 
stack in the creation/querry instead of using recursive calls. We can't 
do that because we don't know tree's depth. But we can use nodes of 
fixed size if max_elements parameter is passed in compile time.

But what do you think about the interface? Passing the algorithm which 
takes compile-time parameters.

rtree<Value, linear<8, 4> > t;

Regards,
Adam