David Winslow had just presented geogig and I wanted to follow up with thoughts on other ways of indexing the data to support efficient querying by more than an ID.
David indicated that although its not currently supported, there is a potential opportunity to store multiple trees per commit where each tree can be organized to support particular queries. Alternatively it comes to mind that the identifiers for the features just need to be a consistent hash, but could be prefixed by something such as a space filling curve value to control sort order within a key value store.
So I am seeing if I could help with a spatially organized tree - I'm not sure if a variant of an R-Tree would be the most suitable because of the re-balancing required and representing the tree efficiently in a key value store can be counter-productive.
GeoWave and GeoMesa attempt to use space filling curves to reduce n-dimensional data to a single dimension that preserves locality. I'm a GeoWave developer so I am most familiar with that so I can say that to get a good SFC value for a geometry should be a simple one-liner that is completely decoupled from the storage (such as accumulo). Is this a good way to be thinking of the problem initially? Would it make sense to try that out to see how well you can keep the features (hashes) within the tree to organize themselves spatially?
Rich
