pheelicks

A5 - a pentagonal geospatial index: https://a5geo.org

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

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

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

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

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.

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-...

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

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

For a visual explanation of how the system works, as well as interactive examples, check out the project website at https://a5geo.org/examples/

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

Yes, those are the obvious ones. This example: https://a5geo.org/examples/airbnb shows why the equal area is valuable in practice, while https://a5geo.org/examples/area shows the area variation vs h3.

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.

A pentagonal geospatial indexing system: https://a5geo.org/

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

The code is open source: https://github.com/felixpalmer/a5

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.

Yes, I’ve tried it with the Eiffel Tower. You can see overhangs on the tv tower at the start of this demo https://3dtiles.carto.com/

I was involved in building the interactive story map using deck.gl that you can view at https://3dtiles.carto.com

It’s really cool to have access to all this amazing data! Shout out to Google for working with us to bring support to multiple open source rendering engines.

Happy to answer any questions

This was built using the just released Photorealistic 3D tiles announced at Google IO: https://cloud.google.com/blog/products/maps-platform/create-...

We worked on providing an integration with deck.gl to make it easy to combine 3D tile data with interactive visualizations. Happy to answer any questions!

Take the night train via Regensburg (book via cd.cz) and arrive rested. Goes every Thursday

Impressive performance, I remember trying this technique a while back a the number of steps required made the frame rate drop. Is the code public?

By the way, you might like https://felixpalmer.github.io/volcanoes-of-japan/

Great work, runs very smoothly! Where do you do the shadow calculation? Do you have precomputed tilesets or do you do it on the client?

Nice writeup, I always like it when the shaders are highlighted like this. I got started in a similar way 7 years ago and have been making 3D terrains with THREE.js & WebGL since.

The real fun begins when you need to implement some sort of Level-of-Detail system and streaming in data to give the illusion of high detail everywhere without sacrificing performance.

Last year I released an open-source framework (https://github.com/felixpalmer/procedural-gl-js) for creating 3D terrains for web applications, you can see Uluru here: https://www.procedural.eu/map/?longitude=131.036&latitude=-2... (unfortunately the aerial imagery from our default provider isn't as high resolution as other places in Europe)

Great thanks - perhaps obvious, but worth running the PNGs through something like pngcrush.

I'm thinking about it the other way also, that is could your approach be used to reduce the size of DEMs encoded as PNGs. While I can see brotli being more efficient, by not using a image compression algorithm you perhaps lose out on exploiting the 2D nature of the data, as if I understood correctly when you're compressing the data you treat the tile as a 1D blob of binary data.

Great visualization and approach with compressing the tile data. Do you have a comparison of how much smaller the payload ends up being compared to simply sending PNG files?

I use PNGs to encode elevation data in my 3D mapping library (https://github.com/felixpalmer/procedural-gl-js/) and this does a pretty good job of compressing the data, for example in the ocean the PNG files are also very small as the image is mostly black. Different use case I now as your data is much more sparse, but I wonder how close the PNG compression would be compared to your approach.

Bug reports are welcome at: https://github.com/felixpalmer/procedural-gl-js/

Also the geocoding quota issue has been resolved