Is the big thing here that those hexagons have the advantages of a circles (almost even max distance in all directions from center) with the advantages of squares (no overlap)?
Hexagons. Are the bestagons. https://m.youtube.com/watch?v=thOifuHs6eY
- 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.
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/#polygontocellsexperiment... [1]: https://duckdb.org/docs/stable/extensions/spatial/r-tree_ind...
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.
There are some nice things with this. It contains cells at different levels (sizes). So you can use very small cells if you care about small areas, or large cells if you care more about larger areas. Those are given here https://h3geo.org/docs/core-library/restable/#average-area-i...
From a coordinate it is fast to get the cell at any level, so it's fast to group coordinates at whatever level you want.
If is less about comparing two coordinates, it is more about bering able to group large numbers of coordinates such that they go into non-overlapping groups, where everything in the same group is 'close' to each other.
Thus most screen projections are derived from wgs84. The idea behind h3 (as I see it) that when moving the map to lets say top-right, you'd need to fetch 1 leaf comparing to 3 leafs with rtree
H3 doesn't have that property between levels. Cells at a level don't overlap. But the the seven children of a cell might overlap with neighboring parent cells.
Of course rectangles aren't rectangular when projected on a sphere. Because there are no straight lines. Rectangles and hexagons are 2d shapes that are applied to the 2d projections of spheres. They only look like rectangles or hexagons in 2D.