Subject: Re: [geometry] [index] r-tree concerns
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2012-06-25 06:15:48
Adam Wulkiewicz wrote:
W dniu 2012-06-23 12:22, Adam Wulkiewicz napisal(a):
> feverzsj wrote:
> W dniu 2012-06-23 08:13, feverzsj napisal(a):
>> In old style, rtree (or query result) is traversed by visiter pattern.
>> While in GP style, concerning the characteristic of rtree, the single
>> pass range concept could be a good choice. But the implementation of
>> this range and iterator may be complex.
>> So, my suggestion is using the visiter pattern as the basic traverse
>> concept, you or users may develope more complex usage based on this.
>> For convenience, there may be a interface that return query results as a
>> sequence of values(like rtree.v1 dose);
> In the old rtree result is returned as a std::deque of values copies.
> The same is in the new one. So in both cases it's not possible to modify
> some properties of values stored in the r-tree as it is possible with
> values stored in std::map. E.g. to find some objects in the area and
> change their color to red using only one container - the rtree. You may
> still store your objects in the std::vector and just indexes in the
> rtree. But you can't do it using only the rtree. Because you can't
Ah, and yes, one may write his own visiting algorithm. In fact there are
some, not included by default.
But I'm thinking about the default behavior. Would returning some
references to Values stored in the rtree be desired?
This probably means that these Values would not be the ones passed as
template parameter (like in the case of std containers). To change the
Key/Indexable one must remove Value from the container and insert it
again with changed Key/Indexable.
rtree<Point> -> const Point
rtree<pair<Box, D>> -> pair<const Box, D>
rtree<Something*> -> const Something*
The use case is presented below. This would call modify_me() for values
stored in the rtree.
// default translator
rtree<pair<Box, Data>, ...> t;
// insert something
// perform the query, return range of references
BOOST_FOREACH(pair<const Box, Data> & v, t.query(...))
v.first = Box(...) // compilation error
Would it be confusing?
And if someone would like to store his own Values he would be forced to
write his own Translator and take care not to modify stored Value's
internal data related to the returned Indexable.
Geometry list run by mateusz at loskot.net