-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introducing a spatial index interface #131
Comments
Great to read your thinking on spatial indexing, we absolutely need this in the ecosystem. As far as I'm aware, indices do not necessarily query on the same thing, depending on the type of index. There can be (k-)nearest neighbour lookups, combined with retrieving distance(s). Or indeed, (possible) candidates in an area of interest (with variations for different dimensions/distance metrics). What you're proposing has been implemented to some higher-level extent in https://github.com/evetion/GeoAcceleratedArrays.jl. it uses the API from Acceleratedarrays to do these lookups. The package could be refactored to work with other index packages (provided they implement geointerface) as package extensions. The remaining work then is to make (spatial) joins make use of these indices. |
The join part is already implemented in JuliaGeo/GeometryOps#75 - we would just need a way to get an arbitrary index from, say, a database, or a pregenerated index. LibSpatialIndex is also not threadsafe, so I would rather use SpatialIndexing.jl or RTrees.jl. I think the lowest common denominator is that all of these spatial indexing methods return a list of neighbor indices given some area of interest, though? For spatial joins and other similar tasks, getting a list of neighbours is all you need, since they have to be filtered by some predicate afterwards in any case. Perhaps we could pass arbitrary kwargs through here, though. (Now that you mention it, perhaps knn trees may not follow this interface - but I haven't heard of those being used for GIS much either...) |
Now that I think about it, we could implement this first in GeometryOps, to see if it makes sense, and then upstream to GeoInterface once we've hashed it out...package extensions in GeometryOps should do the work for this! |
Absolutely, playing with new ideas is pretty hard post 1.0. Even |
There are multiple implementations of spatial index trees in Julia: SortTileRecursiveTree, SpatialIndexing, LibSpatialIndex. The problem lies in that there is no single API to query any of these. They all return the same thing, we just need a common API to query them.
If we get GeoPackage.jl going then there is even the possibility of extracting the SQLite R-tree from there, which would be interesting. In any case, to my mind it makes sense to have some form of interface here - maybe the following on the implementor's side,
Then, in GI,
The text was updated successfully, but these errors were encountered: