Subject: [ggl] spacial index construction interface
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-03-02 13:01:51
Bruno Lalande wrote:
> Hi
>
>
> I thought about traits approach too. The reason why I've decided to
> use some object passed to rtree (I've called it translator) is that
> if someone wants to store values of the same type in two spacial
> indexes but interpret it differently then traits should have some
> additional tag. In addition, someone may store values which don't
> contain data needed by the spacial index.
> E.g. someone have two containers one with boxes, second with points
> and he can store just indexes of boxes in one spacial index and
> indexes of points in the second one. He must pass the reference to
> the container somehow and can do it in the translator.
>
>
> Yep that's the kind of situation I had thought about too, and that's
> probably what justifies most the use of the translator. I might have a
> slightly different way to do that (although very close) but I still have
> to think about that further, and check your source code to figure out
> how feasible it is.
I'm working on
https://svn.boost.org/svn/boost/sandbox-branches/geometry/index_080_nhch/ branch
now. I've implemented different nodes hierarchy. There is abstract class
rtree_node and both rtree_leaf and rtree_internal_node(previous
rtree_node) are derived from it. I've done it to avoid duplication of
unused std::vector containing children nodes in leafs.
> BTW, have you considered including boost::ref in the possible things the
> default translator can handle? Some users might need that, I think.
I haven't thought about this but this is probably a good idea. I plan to
handle tuples as well. But I'm waiting for the clarification of the
interface design.
Regards,
Adam