H3: Uber’s Hexagonal Hierarchical Spatial Index https://www.uber.com/en-DE/blog/h3/
I ended up making it an icosahedron and recursively subdividing each face into four new ones by inscribing a new triangle. The project went nowhere for different reasons, so I never figured out if it would have worked, and given this isn’t one of the examples I suspect it wouldn’t have.
Google's S2 is all about performance and prefix-matching.
Uber's H3 makes the math a bit more complex to prioritize less variation in centerpoint-to-centerpoint distances (because they care most about driving times).
This makes the math even more complex to prioritize less variation in area covered by far away tiles (most applicable to e.g. analyzing density of something).
The primary benefit is indeed the ability to treat cells as if they are equal areas. This is something people do currently with H3, but it introduces a bias. Contrary to popular belief, this is not only an issue near the poles or in the ocean.
The other difference is aesthetics, people generally find H3 more pleasing to look at than S2, which is why it gets used in visualization more. You can make the same argument for A5, although of course it is a matter of taste!
Finally, you are correct that H3 was originally developed at Uber for their specific use case, however it has since been used in many other contexts and I think it doesn’t hurt to have some alternatives as conceptually S2/H3/A5 are similar
The plan is certainly to release versions in other languages, if you would like to be involved, please get in touch. I agree the porting shouldn't be too difficult, as by design the library has just one simple dependency and the code should translate nicely to other C-style languages
The octahedron has a much higher angular defect (https://en.wikipedia.org/wiki/Angular_defect) than the dodecahedron, and thus when it is projected onto the sphere the cells are warped a lot. So while their areas may be the same, the shapes vary.
This article explains the geometric construction, and how it leads to the cells being a similar size and shape: https://a5geo.org/docs/technical/platonic-solids
Also from a data visualization point of view, the rectangular cells of Healpix (like S2) are arguably less pleasing to look at than hexagons/pentagons: https://h3geo.org/docs/comparisons/s2#visualization
As a result, when A5 is used as a spatial index, it will generally not have jumps in the cell index values when querying nearby locations on land
This feels like an uncommon need to optimize for. Can't think of a reason I would reach for this over S2 or H3
carderne•8h ago
The ones that seem obvious:
- You need very high resolution. H3 is also 64 bit I think, but it seems like A5 highest resolution is about 4 orders of magnitude higher.
- Equal cell size: are the cells exactly equal in size (in m2)? H3 they vary by up to ~2x.
What are the downsides? The shapes are irregular, distances between centroids are not uniform...
pheelicks•8h ago
The downsides are the characteristics that make h3 or s2 useful. For h3, the single neighbor type means it is well suited to flow analysis and S2 having exact cell subdivision means it is great for simplifying geometry.
However, there a number of use cases where choosing a spatial index is a more stylistic choice, like for visualization.
The aim of A5 is not to replace S2/H3 but rather to offer an alternative that has different strengths and weaknesses compared to existing solutions
spencerflem•4h ago