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

Sorry for the late reply! To be honest I hadn't considered it because when I wrote this it was originally to solve a specific problem and that situation always has them in lat/lon rather than lon/lat, but what I'll add to the future to do list is maybe a toggle so if you have them in lon/lat order you can society that and feed them in that way.

I get your point on "DD" being cryptic, I will consider that. Maybe rather than DD, DM, DMS, DecDeg, DegMin, DegMinSec or something slightly more descriptive. Hm.

It is a common misconception that h3 is equal area. At any resolution level the cell size varies by a factor of 2, which is (roughly) the same as S2.

See the following visualizations for an illustration:

https://a5geo.org/examples/area

https://a5geo.org/examples/airbnb

Note that I wrote “roughly equal area”. True equal area doesn’t exist. I am on record that for analytical purposes, equal area largely doesn’t matter.

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

Ha, yeah, I remember reading about your project back in April (I think someone shared it on the GeoRust Discord). Really cool stuff you have here!

Can't say I understand all the math behind it, as it's not my forte (even for H3, for the more numerical parts, I rely on the work of the original authors: I could never have come up with this myself), but your doc is really great!

For the follow-up article, I hope I can get to it eventually. But spare time is a rare currency ^^

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.

I actually made a Ask HN about it just today https://news.ycombinator.com/item?id=45091607 but for some reason the HN algorithm never even showed it on the Ask page :/

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

To get started, take a look at https://a5geo.org/docs/quickstart/python

Yes, such indices (S2 & H3) are widely used for providing a index in databases, so geospatial features that are close by in the world and stored in nearby databases rows. https://cloud.google.com/bigquery/docs/grid-systems-spatial-...

Thanks. I always enjoy when geospatial topics show up on here. My background it geo, but unfortunately I have slowly drifted away. Geohash is about where I left off in the same general realm of concepts, so S2 / H3 are essentially new to me as well.

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

If you're aggregating and comparing data across different locations for example: https://a5geo.org/examples/airbnb

The base platonic solid that Healpix is based on is the octahedron (https://en.wikipedia.org/wiki/Octahedron), which A5 uses the dodecahedron(https://en.wikipedia.org/wiki/Regular_dodecahedron).

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

Not sure I understand—healpix starts from the rhombic dodecahedron and then bisects the generalizations of the 12 squares each time. Where do octahedra come into play?

My mistake, you are correct. The base solid is indeed the rhombic dodecahedron. I believe the point about the angular defect is still valid though.

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