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?
> Geometry mailing list
Geometry list run by mateusz at loskot.net