Geometry Boost List: [ggl] spacial index

Subject: [ggl] spacial index
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-03-28 15:27:12

Bruno Lalande wrote:
> Hi,
>
>
>     It should be up to the translator to provide proper type which may
>     be indexed. Spatial indexes which are able to handle boxes should
>     take translator translating Value to Box or Point. For indexes of
>     spherical objects it should probably translate to Sphere or Point.
>     But translator only extracts some indexable type from Value.
>
>
> Agreed, I was about to answer that. The translator should dictate the
> Value type used, and everything should be derived from that.
>
> We could almost avoid the Value argument itself (since itself deductible
> from Translator) but we would have a chicken-egg problem: default
> translator is deduced from Value. So either we have both, or we don't
> default the translator (i.e. let the user explicitly specify a default
> translator when nothing special is needed). It might actually be better:
> if the user wants to use a special translator, he has one less thing to
> specify (a redundant thing, furthermore). And if not, he would have had
> to specify the Value anyway so he will simply write something like
> "rtree<default_translator<my_value> >" rather than "rtree<my_value>".
> It's not a big deal and it makes clear straight away that the tree will
> not actually store values (like a vector<my_value> would do).

The thing is, it stores values in leafs. Classic approach will be to use 
Value of type std::pair<Box, Id> but it may be anything. IMO it's better 
to have Value argument on the parameters list: rtree<Value>. So the user 
knows that there is a hierarchy of nodes and at the bottom values are 
stored, and values will be retrieved by some query. And the translator 
just translates Value to Indexable. Btw now
the Translator parameter parameter can be of type 
index::default_parameter and the default translator type is build inside 
the tree.

Regards,
Adam