I never understood why anyone would prefer the H3 hex tiles over Google’s much simpler S2 system: http://s2geometry.io/

Sure, hex tiles make certain circular nearest neighbour searches slightly more accurate… but still have an error.

And then… everything else that’s inconvenient with hex tiling, like that issue that subdivisions of a cell leak into the neighbouring cells and hence don’t add up to 100% of the parent! This makes many database queries return lies, or the queries need very complex and slow(!) code to compensate.

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.

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.

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

S2 is attractive, but the corpus of use cases outside the Pokemon Go community is quite small. The sheer number of companies and hobbyists using H3 for analytics across a wide spectrum makes it much more attractive than S2. H3 functions are built directly into Snowflake DB for example, and h3 extensions / plugins are widely available. I tried and tried to use S2 in my company but the lack of available use cases and examples made it tough to adopt.

It also uses pentagons in some places because a hexagonal grid can‘t tile a sphere. They made sure that the pentagons are located in water, but this feels like it will add even more edge cases to handle.