Geometry Boost List: [ggl] boost geometry rtree

Subject: [ggl] boost geometry rtree
From: Barend Gehrels (barend)
Date: 2011-07-09 15:32:48

On 9-7-2011 13:30, Adam Wulkiewicz wrote:
> 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?

Default strategies are not related to differences of point and point_xy, 
as long as they have the same coordinate system.

Besides that, the default strategy fpr area is defined (though not used) 
for every cartesian and spherical point type.

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

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

The 'because' is incorrect, this cannot be the reason.

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

Everything in Boost.Geometry that is working for a cartesian point is 
working for point_xy. No difference. If you spot one, please notify me.

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.

About area, do you need that for a 3D box? You need probably the volume 
of a box there?

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.

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

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.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110709/44a6c563/attachment.html