If you’ve used H3 the semantics should be familiar. The biggest differentiator is the fact that cells have exactly the same area globally, for why this matters see: https://a5geo.org/docs/recipes/a5-vs-h3
Since starting the project last year and providing implementations in TypeScript, Python and Rust it’s been great to see a community grow, porting or integrating into DuckDB, QGIS and many more: https://a5geo.org/docs/ecosystem
Nice library. Without trying to start the classic geo-flamewar, do you consider returning the DD coordinates as [longitude, latitude]? This is in line with a number of formats out there, including the popular GeoJSON that is often used in JavaScript apps.
Getting these backwards is a common frustration, so my vote would be for Lon/lat ordering.
Regardless of which you choose, I find DD to be quite cryptic and it would be nicer to spell out the order, eg parseToLonLat - then the order is clear to the user
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).
This agrees with my experience on a project I’ve been working on this year, in particular related to porting the code. I’ve developed a strategy that I’m calling “Polyglot Mirroring” where the code is written in multiple languages at once, with LLMs handling the mirroring.
https://news.ycombinator.com/item?id=43971314 got some attention here, when I originally released the TypeScript version, so following up with the news that the library has now been entirely ported to Python.
Not only is this an implementation of the library in a language that is better suited to data science, but there are also many improvements to the underlying A5 grid since the original launch, in particular a true equal area projection, which even accounts for the ellipsoidal shape of the earth. https://a5geo.org/examples/area
A5 cell boundaries are geodesics. One more difference that I thought of is that HEALPix is generally not aligned with the continents (makes sense as it is mostly used for astrophysics), whereas the hilbert curve used to index A5 is aligned with the continental land masses: https://a5geo.org/examples/globe
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
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.
Bear in mind that this is a "Show HN", the library was released just a few weeks ago! Whereas the other libraries have been around for a decade+
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
As a user, you generally don’t care about the math (and S2 is hardly simple either, as it warps the squares prior to projection). You just call the API and use the indices for spatial joins or computations.
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
Also check S2: http://s2geometry.io/, created at Google before H3, which uses squares and underpins the fast indexing in BigQuery amongst many other things
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
The cells being the same shape is useful in some use cases and irrelevant in others. For example, see the Airbnb demo: https://a5geo.org/examples/airbnb. The H3 tiles are very different sizes in the two cities, and make it appear that there is a much higher density of listings in Malta, even though that is not the case.
However the symmetry of H3’s hexagonal cells lends itself well to flow analysis, or routing - which is no surprise as it was developed at Uber.
As for the name, it follows the convention of S2 and H3, which come from group theory and refer (loosely) to the symmetry groups of the various systems
No, it is based on applying a lattice onto the faces of a dodecahedron (technically a pentakis dodecahedron). Take a look at https://a5geo.org/examples/teohedron-dodecahedron and other examples on the website.
H3 is based on a dodecahedron it is it the reason the cell areas range so much, the same is true of S2 - but this is based on a cube.
If you’ve used H3 or S2 it should be familiar, the major difference (apart from the fact it uses pentagons) is that the cell areas are practically uniform, whereas alternative systems have a variance of around 2 between the largest and smallest cells, making them less useful for aggregation. The site has many visual demos, e.g. https://a5geo.org/examples/area
Happy to share a project I've been working for the last few months: A5, a global, equal-area, millimeter-accurate geospatial index. If you you've come across S2 or H3 in the past, it has much in common, except that it uses pentagons for the cell shapes, and the underlying platonic solid it is based on is a dodecahedron (rather than cube, or icosahedron as are commonly used).
There are a number of visual examples on the website to show how it works, along with example use cases.
If you’ve used H3 the semantics should be familiar. The biggest differentiator is the fact that cells have exactly the same area globally, for why this matters see: https://a5geo.org/docs/recipes/a5-vs-h3
Since starting the project last year and providing implementations in TypeScript, Python and Rust it’s been great to see a community grow, porting or integrating into DuckDB, QGIS and many more: https://a5geo.org/docs/ecosystem