4 ms·
Yes, but it's important to note that it's quite a specialized index. - It's an index that doesn't depend on the data, unlike traditional r-tree indices. This me
by cpa 2y ago
Yes, but it's important to note that it's quite a specialized index.
- It's an index that doesn't depend on the data, unlike traditional r-tree indices. This means non-uniform data won't be queried as efficiently as with rtree, but it may be faster to build.
- This data independence property is VERY important for distributed or streaming queries. For example, if you want to join datasets using Spark or other big data tools, each team can add a column for h3 cells independently and join somewhat efficiently. For large volumes of data, constructing the rtree is just not feasible, or more precisely, very disconnected from the rest of the "data ecosystem".
- It doesn't work with any coordinate reference system other than EPSG 4326 (which you may want if you only work on specific geographies to get more precision in your floats)
- It's clearly built with points in mind. Polygons, curves, or lines are an afterthought. For example, the polygonToCells function returns a set of cells that are entirely within the polygon. If you want to join, you'd need to also have the set of all cells that entirely contain the polygon. I've never found a reliable way to get that.
That being said, it's not bad at all, but if you don't have so much data that you can't compute rtree indices, just stick with PostGIS.
- riordan 2y ago> Polygons, curves, or lines are an afterthought. For example, the polygonToCells function returns a set of cells that are entirely within the polygon. If you want to join, you'd need to also have the set of all cells that entirely contain the polygon. I've never found a reliable way to get that. With v4 of h3 they (finally) have a clean syntax for this with polygonToCellsExperimental[0]. Now there’s options for - Cell center is contained in the shape (default) - Cell is fully contained in the shape - Overlapping (covering): Cell overlaps the shape at any point - BBOX: Cell bounding box overlaps shape Makes life a fair bit easier if you’ve gotta deal with H3 polys. And if you’re working locally, DuckDB Spatial’s r-tree indexing[1] can make for a nice stand-in for PostGIS as a quick point-in-polygon solution without the need to spin up a service. [0]: https://h3geo.org/docs/api/regions/#polygontocellsexperimental https://h3geo.org/docs/api/regions/#polygontocellsexperiment... [1]: https://duckdb.org/docs/stable/extensions/spatial/r-tree_indexes.html https://duckdb.org/docs/stable/extensions/spatial/r-tree_ind...
- cpa 2y agoNice, I did not know about polygonToCellsExperimental. As for DuckDB & rtree, it's alas not a replacement of postgis yet and the indices cannot be used (yet) in joins. In fact, I even have workflows where I iterate over rows in python and run duckdb queries one after the other rather than joining in just one query because of this very issue.