How can you accurately aggregate and compare point-based data from different parts of the world? When analyzing crime rates, population, or environmental factors, how do you divide the entire globe into equal, comparable units for analysis?

For data scientists and geospatial analysts, these are fundamental challenges. The solution lies in a powerful class of tools called Discrete Global Grid Systems (DGGS). These systems provide a consistent framework for partitioning the Earth’s surface into a hierarchy of cells, each with a unique identifier. The most well-known systems, Google’s S2 and Uber’s H3, have become industry standards for everything from database optimization to logistics.

However, these systems come with inherent trade-offs. Now, a new DGGS called A5 has been developed to solve some of the critical limitations of its predecessors, particularly concerning area distortion and analytical accuracy.

Why Gridding the Globe is Harder Than It Looks

The core mathematical challenge of any DGGS is simple to state but difficult to solve: it is impossible to perfectly flatten a sphere onto a 2D grid without introducing some form of distortion. Think of trying to apply a perfect chessboard or honeycomb pattern to the surface of a ball; the shapes will inevitably have to stretch or warp to fit together without gaps.

All DGGS work by starting with a simple 3D shape, a polyhedron, and projecting its flat faces onto the Earth’s surface. The choice of this initial shape and the specific projection method used are what determine the system’s final characteristics. As a simple analogy, consider which object you’d rather be hit on the head with: a smooth ball or a spiky cube? The ball is a better approximation of a sphere. When you “inflate” a spiky polyhedron to the size of the Earth, the regions nearest the sharp vertices get stretched out the most, creating the greatest distortion.

A Quick Look at the Incumbents: S2 and H3

To understand what makes A5 different, it’s essential to have some context on the most popular existing systems.

Google’s S2: The Cube-Based Grid

The S2 system is based on projecting a cube onto the sphere. On each face of this conceptual cube, a grid like a chessboard is applied. This approach is relatively simple but introduces significant distortion at the cube’s vertices, or “spikes.” As the grid is projected onto the sphere, the cells near these vertices become stretched into diamond shapes instead of remaining square. S2 is widely used under the hood for optimizing geospatial queries in database systems like Google BigQuery.

Uber’s H3: The Hexagonal Standard

Uber’s H3 system starts with an icosahedron — a 20-sided shape made of triangles. Because an icosahedron is a less “spiky” shape than a cube, H3 suffers from far less angular distortion. Its hexagonal cells look more consistent across the globe, making it popular for visualization. H3’s immense success is also due to its excellent and user-friendly ecosystem of tools and libraries, making it easy for developers to adopt.

However, H3 has one critical limitation for data analysis: it is not an equal-area system. This was a deliberate trade-off, not a flaw; H3 was built by a ride-sharing company trying to match drivers to riders, a use case where exact equal area doesn’t particularly matter. To wrap a sphere in hexagons, you must also include exactly 12 pentagons — just like on a soccer ball. If you look closely at a football, you’ll see the pentagonal panels are slightly smaller than the hexagonal ones. This same principle causes H3 cells to vary in size. The largest and smallest hexagons at a given resolution can differ in area by a factor of two, meaning that comparing raw counts in different cells is like comparing distances in miles and kilometers without conversion. For example, cells near Buenos Aires are smaller because of their proximity to one of the system’s core pentagons, creating a potential source of error if not properly normalized.

Introducing A5: A New System Built for Accuracy

A5 is a new DGGS designed from the ground up to prioritize analytical accuracy. It is based on a dodecahedron, a 12-sided shape with pentagonal faces that is, in the words of its creator, “even less spiky” than H3’s icosahedron.

The motivation for A5 came from a moment of discovery. Its creator, Felix Palmer, stumbled upon a unique 2D tiling pattern made of irregular pentagons. This led to a key question: could this pattern be extended to cover the entire globe? The answer was yes, and it felt like uncovering something “very, very fundamental.” This sense of intellectual curiosity, rather than a narrow business need, is the foundation upon which A5 is built.

A5’s single most important feature is that it is a true equal-area system. Using a specific mathematical projection, A5 ensures that every single cell at a given resolution level has the exact same area. This guarantee even accounts for the Earth’s true shape as a slightly flattened ellipsoid, not a perfect sphere.

This is a game-changer for analysis. By providing cells of identical size, A5 eliminates the need for analysts to perform complex area-based normalization. This prevents a common source of error and dramatically simplifies workflows when calculating metrics like population density, risk exposure, or any other value that depends on a consistent spatial unit.

A5 vs. H3 vs. S2: A Head-to-Head Comparison

The choice of base polyhedron and projection method results in significant differences between the major DGGS. Here is a direct comparison of their key technical characteristics.

Metric | A5 | H3 | S2

Base Polyhedron | Dodecahedron (12 pentagonal faces) | Icosahedron (20 triangular faces) | Cube (6 square faces)

Equal-Area Cells | Yes (Exact) | No (Up to 2x area variation) | No

Max Resolution | ~30 square millimeters | ~1 square meter | ~1 square centimeter

Global Hierarchy | Yes (Single top-level world cell) | No (122 top-level cells) | Yes (6 top-level cells)

The A5 Ecosystem and its “Polyglot Mirroring” Approach

The success of H3 proves that a powerful mathematical system is not enough; it needs a rich ecosystem of accessible tools to gain adoption. A5 is being built with this principle in mind, but with a novel development strategy.

This approach is called “polyglot mirroring.” Instead of building a single core library in C and creating language bindings, A5 maintains separate, complete, and equivalent codebases in multiple languages, including TypeScript, Python, and Rust. To keep these distinct codebases synchronized, Large Language Models (LLMs) are used to port changes and new features from one language to another. This strategy makes the system more accessible and maintainable for developers within each language’s native community.

The power of this approach was proven in a true “wow moment” during A5’s development. The creator, having never written a single line of Rust, fed the existing TypeScript and Python versions and a comprehensive test suite to an LLM. After about a week of guided iteration, the model produced a complete, working, high-performance Rust library. This demonstrates how modern tools can enable a single developer to build and maintain a truly multi-lingual ecosystem, something that would have been impossible just a few years ago.

Conclusion: When Should You Choose A5?

A5 offers a powerful and precise alternative to existing global grid systems. Its primary advantages make it the ideal choice for specific, demanding use cases.

Statistical Validity: Any analysis where equal-area cells are paramount for accuracy is a prime candidate for A5. This includes density mapping, demographic studies, environmental modeling, and financial risk assessment.

Extreme Resolution: For applications requiring precision beyond what H3 or S2 can offer, A5’s ability to index down to cells of approximately 30 square millimeters provides unmatched granularity.

Efficient Global Hierarchy: Workflows that need to query data at a global scale benefit from A5’s simple hierarchy, which starts from a single cell representing the entire world. In contrast, loading global data with H3’s 122 top-level cells could require 122 separate requests, creating unnecessary complexity and inefficiency.

To explore the A5 system, see detailed visualizations, and understand the technical comparisons in more depth, visit the official website at a5geo.org.

In Conversation

From Physics to High-Performance Web Graphics

Daniel: Hey Felix, welcome to the podcast. I’ve just listened to your talk. We’re here at FOSS4G 2025 in Oakland. You were talking about something called A5 — fascinating stuff. Is it correct you’re a maintainer of deck.gl?

Felix: Yeah, that’s true. I’ve been maintaining deck.gl — not just me — for the last four years. deck.gl is a visualization framework on the web, written in JavaScript, and it gets used for a lot of big data visualization. If something like MapLibre or a Google Maps app can’t handle a million points, people often reach for deck.gl, or if they want to do something a bit more interactive or interesting.

Daniel: Before we start talking about global grid systems, how did you get involved? What was your path to this?

Felix: The path was a complicated one. My background is physics — I studied at Oxford — so I’m coming more from the maths side than the programmer or geospatial side. But I always liked the more real-world visual side of physics. As a teenager I tried to build an electric organ. After finishing physics I ended up working in software, but I always gravitated toward visual things. As a side project — quite a long time ago now — I started making a visualization framework called Procedural, something similar to Google Earth, where you’d visualize a 3D landscape in the browser. After that I moved on to deck.gl, which is related in terms of technology but a very different kind of project. Through some twists and turns I found a niche for myself in high-performance graphics programming on the web. When I tell people I’m a web developer, they say “Oh, can you make me a WordPress site?” And it’s like — not quite the same thing.

Global Grid Systems 101: What They Are and Why They Matter

Daniel: I don’t want to bury the lead too much, but just so the listeners know, A5 is a global grid system. Before we talk about the specifics and why we might choose it over others, would you mind giving us the 101 on global grid systems? What are they, what do we use them for, and why should we care?

Felix: Sure. In data analysis — and geospatial data analysis in particular — we often want to divide some region into equal or near-equal-sized cells. If we want to understand where people are living or what crime rates look like, we need some kind of bucketing system. As a society we’ve made things like ZIP codes for this, but for science and analysis it’s more useful to have a general system that works across the whole world.

Felix: If the world were flat, this would be fairly easy — you could subdivide it like a chessboard or a honeycomb. But the world is a sphere, and not even quite a sphere; it’s a slight ellipsoid. If you try to divide it, you can do it fine in one local region — it’s not hard to divide a city into city blocks — but as you extend further and further out, you end up with distortion or cells that don’t mesh perfectly. This same problem comes up when you’re looking at the night sky and want to represent patches of it, or when a space probe needs to sample a planet. One of the earliest grid systems was basically a sensor on a spacecraft in the 1970s. There’s a long history of grappling with this mathematical problem: you can’t flatten a sphere perfectly. Just to be clear, we’re talking about using these for analysis, not navigation.

Felix: One key use case is joining two datasets that come in completely different formats. Say you want to draw a connection between income and temperature — you have two datasets with no common key. These grid systems give you a way to divide the world into equal cells in a fixed coordinate system. If each cell has an identifier, you can join on those with a very simple SQL query. It reduces the dimensionality of something as complex as the entire Earth down to one dimension: everything is just a cell with one ID.

S2 and H3: Strengths, Trade-offs, and the Distortion Problem

Daniel: A couple of systems a lot of people will have heard of are S2 and H3.

Felix: Yes. These aren’t the first systems but they’ve become the most widely used. S2 was developed at Google and they actually use it under the covers in a bunch of their services — in BigQuery, for example, if you want to speed up a geospatial query it’s using S2 underneath. The way to think about S2 is that you take a cube, pretend the cube is the Earth, and on each face you put a chessboard. That chessboard can be made finer and finer for smaller cells, or coarser for bigger ones. The problem is the Earth is not a cube, so you have a projection step where each flat face gets projected onto the sphere, and depending on the projection you choose, you get different behaviors — exactly the same issue as general map projections. There’s no perfect projection.

Daniel: So you said dividing the world into equal squares, but they’re not actually equal in distance?

Felix: It depends which squares we’re talking about. On the surface of the cube they are all equal, but in projecting them to the sphere they become unequal and they also have angular distortion — they become diamond shapes rather than squares. It’s the same as with map projections: Greenland starts looking huge, even though in reality it’s completely different in size.

Daniel: Where does most of the distortion end up? Around the edges of the sides, or at the spikes?

Felix: At the vertices — the spikes. Think about which object you’d rather be hit on the head with: a ball is probably the best one, not going to hurt much. A pyramid is going to be pretty bad, a cube is going to be pretty bad. If you are going to be hit by a cube, you’d prefer the flat surface. When you “inflate” that cube with the projection, the regions nearest the corners get stretched out the most. The bits in the centre are pretty close to the sphere, so they’re much less distorted.

Daniel: Okay, what about H3?

Felix: H3 was brought out by Uber, maybe eight years ago, building on ideas from the 1990s. What they did very well was provide an ecosystem — a JavaScript library, a visualization tool, integrations into various database systems. Because of that ecosystem it became very popular. H3 starts with a shape called an icosahedron, which has 20 triangular faces. It looks much closer to a sphere than a cube does, so it’s a less spiky shape and you get far less angular distortion when you project it. The hexagons that are perfect hexagons on the face of the icosahedron almost remain perfect hexagons when projected onto the sphere — not quite, but at first glance they do. With S2 it often just looks a bit off. For certain use cases — like optimizing a database — visualization doesn’t matter, but for visualization purposes H3 is just more pleasing.

A5: The Dodecahedron Difference and Equal-Area Accuracy

Daniel: I’d really like to have the 101 on A5, and then compare and contrast these things so we get an idea of the strengths and weaknesses.

Felix: Now that we know what S2 and H3 are, we’re basically saying: we start from some approximation of the Earth in the form of a polyhedron, we stick some tiling system on each face, and then project it to end up with a collection of cells that subdivide the world in some useful way. A5 starts with a dodecahedron — a shape with 12 pentagonal faces. It’s even less spiky than the icosahedron, which means you get less angular variation when you do the projection. In many ways you can use it for the same things you’d use H3. You give it a bunch of latitude/longitude points, it converts them into cells, you aggregate by cell ID, and you can see which cells have the highest density.

Felix: So why would you use A5 over H3? One of the choices H3 made — and remember this was a system built by a ride-sharing company trying to match drivers to riders, that was their use case — is that for that particular purpose it doesn’t actually matter if cell sizes aren’t exactly the same. So they chose a projection where the hexagons, once projected to the sphere, don’t have exactly the same size. There’s roughly a factor of two between the smallest and the largest. This comes from the inflation of the icosahedron to the sphere — some places are getting stretched and some are not. A5 uses a different projection that maintains exact equal area, and it even accounts for the fact that the Earth is not spherical but ellipsoidal. The cells you get out are all exactly the same size, so you don’t have to worry about normalizing in your analysis.

Felix: For certain types of analysis this matters a lot, and for others it might not. If you’re just matching a driver to a rider, you don’t really care. But I do see a lot of people taking point data — say, population density — converting it into H3 cells, and then applying a colour ramp based on how many people are in each hexagon. That’s just not valid, because each hexagon has a different size. You’re comparing things without normalizing. It’s like measuring commute distances where London uses miles and Paris uses kilometres — you can’t compare like with like. The difference between a mile and a kilometre is less than 2x, and that’s essentially the kind of inadvertent error you can end up with in a non-equal-area system like H3.

Daniel: You had this brilliant example earlier about Buenos Aires. Would you mind talking me through that one?

Felix: Without the visual aid it’s a bit harder to explain, but I’d encourage anyone listening to check out the a5geo.org website — there are visualizations there that show not just what you can do with A5, but how it works, and one in particular really helps explain this issue.

Felix: If you imagine a football — a soccer ball — it has exactly the same configuration as the icosahedron we’ve been talking about. It has 12 black pentagons and in between them are white hexagons. H3 has pentagons for exactly the same reason a football has them: without them it wouldn’t be round. And if you look at a football you can see the pentagons are a little bit smaller than the hexagons — logically, because both have the same edge lengths but one has five sides and one has six. When constructing H3 they had to decide where to put these pentagons, and they did a pretty clever job of placing them mostly in the ocean, so you rarely land on a pentagon directly. But it’s not just the pentagon itself that’s small — the closer you get to one, the smaller the cells become. The pentagon near Buenos Aires is quite close to the city, so cells in that region are very small. Compare that to somewhere in the middle of the US where the cells are comparatively large. If you’re computing density across those two locations, the results are incompatible without normalization. I have a direct example on the site comparing Oslo and Malta — within each city the cells are consistent, but between the two cities one is basically double the area of the other.

Choosing a DGGS: Key Metrics and Resolution Range

Daniel: This is going to be a hard question, but when choosing a global grid system, what key metrics should someone be looking at?

Felix: One is the equal-area aspect we’ve already discussed. Another is the range of cell sizes — both at the fine end and the coarse end. At the fine end: some people have raster imagery and ask whether they can convert it into H3. The answer is no for high-resolution imagery, because an H3 cell at the greatest resolution is about 1 square meter. If you want to represent something smaller than that it’s going to be very blurry. H3 was not designed for raster imagery, but if that’s what you want, it won’t work. S2 by comparison goes down to about 1 square centimetre. A5 goes one level further than that — approximately 30 square millimetres. And when I talk about “going down to a level,” I mean being representable by a single 64-bit integer, which can be used as a key in databases. That’s the meaningful constraint — not just having a smaller cell, but having one you can efficiently index.

Felix: At the coarse end it’s more subtle. S2, built as a cube, has six top-level cells covering continents. H3 starts with 122 top-level cells — I always forget exactly why, but it’s related to the number 12 — and that can become an issue. If you have a web map and want to download data in tiles grouped by H3, and you want to load the whole world, you have to make 122 requests if that’s your key on the URL. With A5 I’ve chosen to have the hierarchy go all the way up to the whole world — there’s a concept of the world as the global cell, you divide it into the dodecahedron faces, and then keep going down. Everything has a child and a parent, all the way down to 30 square millimetres.

Building the Ecosystem: Polyglot Mirroring and LLMs

Daniel: Could you tell me a little about the ecosystem around A5? I think one of the reasons H3 has been so successful in terms of distribution is the ecosystem. It’s easy to use.

Felix: Undoubtedly. Without any implication that this is unique to H3, there are many examples where the technically inferior product wins because it gets greater adoption and distribution. Sometimes the easiest solution wins because it reduces friction. You don’t have to go to a shop, you don’t have to buy anything — it’s just available. Uber and the community around H3 did a great job of explaining what you can do with the system and making it available in many languages. You can have a workflow where you import an H3 integration into your database, process your data, save it to a file, import it in Python, run analysis, and then visualize it in QGIS or deck.gl. Each part strengthens all the others.

Felix: With this in mind I had a strategy: I’ve written A5 in TypeScript because that’s what I know and that’s my visualization world, but that’s not what most people want. They’re going to want Python for data science, and Rust as the high-performance option. This is where I really leaned on the tools we have today — LLMs and agent models, in particular Claude Code — to help translate from JavaScript to Python, and then from Python to Rust. And this essentially works. I coined a term for it: polyglot mirroring. Rather than having one core language with bindings, you have a collection of languages that are equal and you mirror between them using LLMs to keep them in sync. If I make a change in one language, I just say “port it to Rust and port it to Python.” And then if someone in the future wants to make an improvement and they’re a Rust developer, they can do it in Rust and it gets ported back. The LLMs are very good at recognizing these patterns across languages — they don’t necessarily understand what’s going on at a deep level, but they’re excellent at going “you did this there, and that’s how you multiply two vectors in Rust.”

Felix: The real wow moment came when I got to Rust. I had never written a line of Rust in my life. I thought I’d have to find someone to do it. But I just set Claude off running with the existing TypeScript and Python codebases plus a comprehensive test suite. Often it would run out of credits, so I’d come back in the middle of the night and just press continue. After a week of doing this, it produced a working codebase with a few bugs, which we then managed to fix. I didn’t have to write anything manually. It was a true translation, and now with some help from actual Rust developers it’s been made faster than the original TypeScript. This is the “why now” moment — for next to no money, a single developer can have a team of tools helping them do something that just would not have been possible a year ago.

Daniel: A lot of people will hear that and say “he’s using LLMs — they hallucinate, there are bugs everywhere.” What would you say to that?

Felix: The functions being translated are very often just some kind of numeric input and numeric output. And a lot of time was spent making sure the precision was right — many painful hours, because you’re essentially trying to make a model of the Earth, and if your maths moves a point by a fraction of a millimetre, that’s not good enough. You’re at the limit of what floating point can represent. But if you have tests that verify a bunch of inputs and outputs — say, take a location, convert it to a cell, convert the cell back to a location, generate a thousand of those and check they round-trip correctly — you can be pretty confident. It’s a very decomposable codebase. UI code or complex business logic is where LLMs can trick you — they make a test pass without actually implementing what you want. But implementing a mathematical function is much easier to verify. A nice side effect of writing the code twice in different languages was that precision issues got filtered out because the languages rounded things slightly differently. Actually improved the codebase by porting it.

Why A5? The Motivation Behind a Fundamental Discovery

Daniel: Why are you doing any of this? My guess is your brain enjoys the challenge, and it’s a better system in some ways — but what’s the real motivation?

Felix: The original motivation was that I stumbled across a tiling system in 2D with irregular pentagons. I hadn’t seen it before, and I’d often heard that pentagons are the one shape that can’t tile. When I saw this pattern, it looked very much like a discrete grid system. If you’re a deck.gl developer, everything starts to look like a grid system — you’re walking down the street admiring architecture and thinking “that looks like H3 tiles.” Real fun at a party. So yes, I came across this tiling pattern and thought: could this actually be made to extend over the whole globe? The answer turned out to be yes, and it really goes quite deep — down to low-level geometry, space-filling curves, threading a single line through every cell on the globe exactly once to define the index.

Felix: After a while I wanted to share it and see what people thought. People found it interesting but, as I was saying, that’s not enough to get people to use it. And I found it a completely different but equally fascinating challenge: how do you get adoption? It’s not just a maths problem — it’s a people problem. How do you get people excited? How do you do marketing? Which is partly why I’m here talking to you now. I want people to listen and hopefully go look at the site and think, maybe I could use this for something.

Felix: The motivation is, I’d say, altruistic in a sense. I found it very interesting, it’s a deep rabbit hole, but it also felt like one of the only projects where I felt I actually discovered something very fundamental. There’s a difference between adding a button to a UI and stumbling across something new. I haven’t come across anyone who took this tiling pattern and applied it to a sphere, and I thought — this is what I can do with it. I’ve even had some other ideas: geodesic domes in architecture could use the same principle. And if you look at a golf ball, very often the arrangement of dimples is the same as H3 — hexagons and pentagons — and I’ve made an A5 golf ball on the site just for fun. I briefly entertained the idea of going to a golf manufacturer. But let’s not go there.

Daniel: Has anyone ever accused you of being a nerd?

Felix: Maybe once or twice.

Daniel: Lovingly. It’s really refreshing to meet someone who has the technical understanding first and foremost, sees the possibility, and then follows through — not just with the great idea, but with the ecosystem, the tooling, and yes, the marketing. The ideas that spread are the ones that win. I really hope people check out the links in the show notes, go to a5geo.org, and get in touch. Thanks very much for your time, Felix.

Felix: Happy to be here. Thanks a lot.