Subject: AW: [ggl] Re: rtree ?
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-12-02 14:31:35
2011/12/2 Bernhard <Bernhard.Schmitz_at_[hidden]>:
> Thanks for the quick fix.
> Adam Wulkiewicz wrote
>> Btw, maby it would be better to use std::pair<Box, Segment> and
>> Translator. Or even store segments in some vector and use
>> size_t>. The r-tree wouldn't be forced to calculate envelopes each time
>> it want something from the Value.
> That's what I was doing in my previous version when I was using the very
> rudimentary rtree that is in the non-sandbox boost geometry svn directory.
> And as I already mentioned, I need to iterate over all my objects anyway, so
> I can easily switch back. However when I found the new rtree version, I
> thought it would be more elegant to use the translator. I thought that the
> envelope would be calculated once during insertion and then in the
> background the envelope would be stored.
> If I understand that correctly, wouldn't that mean that this whole
> translator thing is useless, unless we have objects that store their
> envelope anyway and can provide a reference to it? That doesn't seem very
> reasonable to me. To me, the beauty of it seemed to be that given the right
> translator, I could just stuff all kinds of objects into the rtree and
> retrieve them with a query with no additional code on the outside. But if
> that is lost I don't really get the advantage of the current design.
Purpose of the translator is to translate Value into Indexable, not to
convert it and store both.
In the new design you explicitly define the type of object stored
inside the rtree by passing Value type.
If there were Indexables always stored in the rtree we would have the
previous design with std::pair<Box, T> as Value types. Storing of
objects which are Indexables (adapted to Box or Point concept) or has
Indexable inside would result in duplicating data.
It is possible to implement a rtree which stores types containing
indexable as they are and other types as std::pair<Indexable, T> but
it complicates things. Furthermore, it's not necessary because current
rtree desing makes it possible but you must explicitly say that you
Other thing is that it probably should be better described in the documentation.
Geometry list run by mateusz at loskot.net