Boost logo

Geometry :

Subject: Re: [geometry] R-Tree to GIST
From: Vladimir Voznesensky (vvoznesensky_at_[hidden])
Date: 2016-01-29 02:02:19


GiST could be seen as a generalization of R-tree. In the common case, tree internal nodes are not restricted to describe their subtrees by bounding rectangular boxes. Some things could be described by ellipsoids or, even more exotic, by Bloom filters.

I would like to add some traits defining algorithms for calculation of:
 - Subtrees overlapping cost;
 - Insertion cost and resulting internal node subtree aggregate;
 - Querying criteria.

User could also need to have weighted points and be able to calculate an overall sum weight of all points in a given region, so internal tree nodes could have aggregate weights of each subtree.

29.01.2016, 02:07, "Adam Wulkiewicz" <adam.wulkiewicz_at_[hidden]>:
> Hi Vladimir,
>
> Vladimir Voznesensky wrote:
>> šAnother strange question, please.
>> šCurrently, rtree code deals with continious data values. Each value is
>> štreated as a spatial coordinate. The question is: would it be painful
>> što treat some coodinates as 32, 64 or 128 bits bitsets? In other
>> šwords, is it possible to refactor R-Tree to Generalized Index Search Tree?
>> šWithout messing too much the code, of course,
>
> Sorry, but I'm not a GiST expert, besides this looks like a specific
> case. AFAIU you'd like to perform the indexing and querying differently
> than it's done by the R-tree. Could you please explain what would you
> like to do exactly?
>
> Regards,
> Adam
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry


Geometry list run by mateusz at loskot.net