Subject: AW: [ggl] Re: rtree ?
From: Bernhard (Bernhard.Schmitz)
Date: 2011-12-02 15:13:56
Adam Wulkiewicz wrote
> 2011/12/2 Bernhard <Bernhard.Schmitz_at_.uni-stuttgart>:
>> 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
>>> 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
>> And as I already mentioned, I need to iterate over all my objects anyway,
>> 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
>> 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
>> 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
> want it.
> Other thing is that it probably should be better described in the
I can now see the rationale behind the current design.
However, I'm not convinced it is a good design idea for a library, as it
forces the user to use the library in different ways depending on the type
of object that he wants to store, due to of the inner implementation of the
library. It is as if std::list would have a different interface depending on
whether one wants to store pointers or objects.
For me, it's not a problem, I will go back to simply indexing my object
container, so this is just as a general Feedback.
Have a nice weekend!
-- View this message in context: http://boost-geometry.203548.n3.nabble.com/rtree-tp3437687p3555124.html Sent from the Boost Geometry mailing list archive at Nabble.com.
Geometry list run by mateusz at loskot.net