I really want to do a DuckDB extension someday, I think it would be pretty cool. I had looked into it 2 years ago but didn't dig further.

Now that H3 provides one, maybe I should take another look at it.

Very impressive results, cool to see innovation in this space! I’d definitely be interested in a follow up post going into the details of the geometric algorithms.

I’m working on my own DGGS, A5, the first (and only) to use pentagons. It offers true equal area cells and a much higher cell fidelity (below 1cm compared to 1m for H3).

I’m looking for contributors to get involved and you seem to have the perfect skill set. It would be amazing to have you join the project :) https://a5geo.org/ https://github.com/felixpalmer/a5

h3o-zip is really impressive! I've been wanting to play around with it more, and I've been meaning to ask you if you have any good references for that encoding approach. I understand how it works in h3o-zip, but I'd be interested to know more about where else that approach has been used.

As one example, the U.S. Federal Communications Commission uses it in its Broadband Data Collection program. You can see some of how it's been implemented here: https://broadbandmap.fcc.gov/

Edit: It seems some people get a blocked message when visiting the base url. The home path may work better? https://broadbandmap.fcc.gov/home

H3 was integrated into ClickHouse in 2019, and since then, I have heard many interesting stories. There are unusual ones, e.g., when it is used not to map data on Earth, but for astronomy (stars, galaxies).

H3 is commonly used for creating visualization aggregates e.g. creating visual summaries of data distribution. That was its primary design case.

I’ve used h3 for a game. Since they align with an unique hex, I can ensure that one cell grid aligns and is placed on the same place in the world, where players could then compete on.

amo is using it quite a lot, mainly for the scratch map feature in the Bump Map application, but not only.

Use cases are: - data storage - data aggregation/clustering - spatial indexing - geometrical computation (as long as you're OK with approximation, you can speed up a lot of things by working with CellID instead of actual geometries) - data visualization

I've seen it used by Databend, Helium, Breakroom (they did an Erlang binding on top of h3o), beaconDB, Greptime, Meilisearch. But I don't exactly know what they are using it for (just that they pulled h3o in their projects).

Overture maps docs use it to visualize the coverage of Overture address data.

https://docs.overturemaps.org/guides/addresses/

Picture url: https://docs.overturemaps.org/assets/images/address-coverage...

We use it at Neighbor.com for a lot of data analysis in our marketplace, things like our price recommendations, supply and demand balances, etc.

They have a page about pros and cons: https://h3geo.org/docs/comparisons/s2/

For my use case, the visual distortion of S2 was quite a no-go.

As for DB queries, it really depends on your use case and how you store your data, but you can get some good results. But yeah, if you really need exact parent-child containment, S2 is easier to work with.

H3 is preferred for geo analytics because it produces a more uniform spatial index with low distortion and consistent distances between cells

Its primary use case was efficient spatial aggregation for applications like pricing, demand forecasting, positioning etc.

Some of the original developers of H3 gave a presentation about it that goes over the tradeoffs between those different systems, would recommend watching it.

https://www.youtube.com/watch?v=wDuKeUkNLkQ

The main advantages of hexagons are that the distance to each neighbour is always the same, and the distortion across the globe is much less, because of the way H3 creates its grid (compared to the earlier Google S2 which uses squares and distorts a lot). There’s an excellent Uber blog post about this, I’ll see if I can find the link.

The main advantage of hexagonal spherical tiling systems is that they are roughly equal area at a given resolution. This makes them particularly suitable for generating visualizable aggregates when you primarily care about spatial distribution rather than specific boundaries (like borders).

The main disadvantage of non-congruent tiling systems like H3 is poor scalability and performance when running analytical computations. In most cases you wouldn't want to shard your underlying data this way even if this is how you want to visualize it.

It is easy to get the best of both worlds. You can shard data models as 3-space spherical embeddings (efficient for large-scale analytic computation) and convert query results to an H3 tiling at wire speed on demand.

One of the big ones that hasn't been mentioned is all of a hexagon's neighbors are equidistant. As a result, h3 is a better fit for flow modeling - stuff like telematics. This has some nice properties for ML too.

You can see one of my jupyter notebooks that dives deep into this with h3 here: https://drive.google.com/file/d/18jIVEbE_1QbwTbHdMqj0AVqguf2...