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

Planar index #76

Closed
rsbivand opened this Issue Nov 16, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@rsbivand
Member

rsbivand commented Nov 16, 2016

I just noticed RcppAnnoy, which, because the index is storable after building, might be a candidate for point data.

@edzer

This comment has been minimized.

Show comment
Hide comment
@edzer

edzer Nov 20, 2016

Member

Do we have k-NN functions now, and should they be part of a package providing simple feature access?

Member

edzer commented Nov 20, 2016

Do we have k-NN functions now, and should they be part of a package providing simple feature access?

@rsbivand

This comment has been minimized.

Show comment
Hide comment
@rsbivand

rsbivand Nov 21, 2016

Member

No we don't, this is "future-proofing". The GEOS STRTree is used a little in rgeos (could be more, but prepared geometries aren't predicate-ready), but only easily searches for intersecting envelopes, which don't work for points. We know too little yet about vector tiling, but indexing seems to be needed for that. GPKG has RTree Spatial Indexes extensions, I guess others will be close soon. I can't predict where this is going, but if spatial is big, then indices will be part of the solution.

Member

rsbivand commented Nov 21, 2016

No we don't, this is "future-proofing". The GEOS STRTree is used a little in rgeos (could be more, but prepared geometries aren't predicate-ready), but only easily searches for intersecting envelopes, which don't work for points. We know too little yet about vector tiling, but indexing seems to be needed for that. GPKG has RTree Spatial Indexes extensions, I guess others will be close soon. I can't predict where this is going, but if spatial is big, then indices will be part of the solution.

@edzer edzer added the enhancement label Nov 21, 2016

@edzer

This comment has been minimized.

Show comment
Hide comment
@edzer

edzer Feb 5, 2017

Member

but prepared geometries aren't predicate-ready

what did you mean by that remark?

Member

edzer commented Feb 5, 2017

but prepared geometries aren't predicate-ready

what did you mean by that remark?

@rsbivand

This comment has been minimized.

Show comment
Hide comment
@rsbivand

rsbivand Feb 5, 2017

Member

Do not recall now. The underlying idea IIRC was to try to prepare for vector tiling by providing a stored and update-able index as an adjunct to a geometry column. I haven't got any further.

Member

rsbivand commented Feb 5, 2017

Do not recall now. The underlying idea IIRC was to try to prepare for vector tiling by providing a stored and update-able index as an adjunct to a geometry column. I haven't got any further.

@edzer edzer referenced this issue Jun 2, 2017

Closed

GSoC 2018 #368

edzer added a commit that referenced this issue Jun 22, 2017

@edzer

This comment has been minimized.

Show comment
Hide comment
@edzer

edzer Jun 22, 2017

Member

The current implementation computes indexes on the fly for most binary operations, and discards them afterwards; see http://r-spatial.org/r/2017/06/22/spatial-index.html

Member

edzer commented Jun 22, 2017

The current implementation computes indexes on the fly for most binary operations, and discards them afterwards; see http://r-spatial.org/r/2017/06/22/spatial-index.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment