Spatial Data Structures for Better Map Interactions
chairnerd.seatgeek.com
Spatial Data Structures for Better Map Interactions
1–10 of 24 posts
Re: Spatial Data Structures for Better Map Interactions
#2The other way to do this, which is common in (older?) 3d video games, is to render your scene twice, once normally and once with each object shaded in a unique flat colour. Then sample your second bitmap at the mouse position and map the pixel value back to your list of objects. This is very fast and only falls over when you start to have transparent objects, in which case ray-casting and r-trees become appropriate.
Re: Spatial Data Structures for Better Map Interactions
#3Spatial data structures are great, and heavily used in all kinds of mapping applications. Most of the systems I've worked with used the more constrained quadtree structure, where the map is divided into uniformly-sized tiles, and a level-of-detail hierarchy is built. This is good for raster data, where each tile is a picture and the whole world is covered by tiles. The R-tree has great advantages when the complexity is not uniformly distributed across the map, for example, vector road data, where vast areas on earth have no data, and most of the data is concentrated in small urban areas.
I believe PostGIS, which adds spatial operations to Postgres, uses an R-tree as its spatial index.
An improvement on the R-tree, the R(star)-tree, uses a different node splitting algorithm and includes re-insertions (similar to balancing a B-tree), reducing both coverage and overlap. The insertion complexity is greater, but in general, R(star)-tree query performance tends to be a bit better for mapping applications. Generally, maps don't change that often, so building the tree tends to happen far less often than querying it.
There are many more specialized spatial data structures available, for example, Kd-trees, which can be perfectly balanced and are useful for storing point data.
If you're really interested in this stuff, the holy bibles for spacial data structures (which I keep in a special place on my bookshelf) are a pair of books written by H. Samet: The Design and Analysis of Spatial Data Structures, and Applications of Spatial Data Structures: Computer Graphics, Image Processing, and GIS.
EDIT: Formatting, and apparently you can't write the asterisk character on HN
R-Tree paper (1984): http://postgis.org/support/rtree.pdf
R(star)-Tree (1990): http://epub.ub.uni-muenchen.de/4256/1/31.pdf
PostGIS: http://postgis.net
H.Samet textbooks: http://www.cs.umd.edu/~hjs/design.html
Re: Spatial Data Structures for Better Map Interactions
#4If you find yourself doing big-time spatial queries, consider using the PostGIS extension for Postgres, which uses R-Trees-on-top-of-GiST indices: http://postgis.net/
In addition to ray-casting and R-Trees, there's another alternative for the "point in polygon test" not mentioned by the article: compute the Winding Number. Appropriate for a very low number of polygons where a full spatial index might be overkill.
http://en.wikipedia.org/wiki/Point_in_polygon#Winding_number...
I think seatgeek made the right choice in this case though with a client-side R-Tree.
Aside: does anyone know what browsers use for hit-testing polygons defined by the tag?
Re: Spatial Data Structures for Better Map Interactions
#5The other way to do this, which is common in (older?) 3d video games, is to render your scene twice, once normally and once with each object shaded in a unique flat colour. Then sample your second bitmap at the mouse position and map the pixel value back to your list of objects. This is very fast and only falls over when you start to have transparent objects, in which case ray-casting and r-trees become appropriate.
This is basically a grid[1] where the resolution is down to 1 pixel. Not a bad solution!
Re: Spatial Data Structures for Better Map Interactions
#6Spatial data structures are great, and heavily used in all kinds of mapping applications. Most of the systems I've worked with used the more constrained quadtree structure, where the map is divided into uniformly-sized tiles, and a level-of-detail hierarchy is built. This is good for raster data, where each tile is a picture and the whole world is covered by tiles. The R-tree has great advantages when the complexity…
PostGIS uses an R Tree implemented on a GiST index by default, with a pure R tree partially implemented.
http://postgis.net/docs/manual-2.1/using_postgis_dbmanagemen...
Re: Spatial Data Structures for Better Map Interactions
#7Spatial data structures are great, and heavily used in all kinds of mapping applications. Most of the systems I've worked with used the more constrained quadtree structure, where the map is divided into uniformly-sized tiles, and a level-of-detail hierarchy is built. This is good for raster data, where each tile is a picture and the whole world is covered by tiles. The R-tree has great advantages when the complexity…
Shameless plug of my Go R-tree implementation, which cites the Guttman R-tree paper and the Roussopoulos/Kelley/Vincent nearest-neighbor search paper in its implementation, and is therefore perhaps a useful resource: https://github.com/dhconnelly/rtreego
Re: Spatial Data Structures for Better Map Interactions
#8Spatial data structures are great, and heavily used in all kinds of mapping applications. Most of the systems I've worked with used the more constrained quadtree structure, where the map is divided into uniformly-sized tiles, and a level-of-detail hierarchy is built. This is good for raster data, where each tile is a picture and the whole world is covered by tiles. The R-tree has great advantages when the complexity…
PostGIS uses an R Tree implemented on a GiST index by default, with a pure R tree partially implemented. http://postgis.net/docs/manual-2.1/using_postgis_dbmanagemen...
Ahh, I stand corrected. Thanks!
Re: Spatial Data Structures for Better Map Interactions
#9the rtree implementation they found [1] isn't connected to leaflet except that the org that it lives in also manages some leaflet plugins, Vladimir, the author of leaflet, does have his own rtree implementation [2].
For the record I manage the one in the article.
1: https://github.com/leaflet-extras/RTree 2. https://github.com/mourner/rbush
Re: Spatial Data Structures for Better Map Interactions
#10the rtree implementation they found [1] isn't connected to leaflet except that the org that it lives in also manages some leaflet plugins, Vladimir, the author of leaflet, does have his own rtree implementation [2]. For the record I manage the one in the article. 1: https://github.com/leaflet-extras/RTree 2. https://github.com/mourner/rbush
Ah, you are right. I must have looked at Vladimir's implementation and then just associated him in my mind with the leaflet-extras implementation.