The Genius Behind H3: Turning the Earth into a Football

I've recently found myself diving into system design, the algorithms behind large-scale software, and the historical innovations that shaped the systems we use today. One project from Uber has fascinated me more than most: H3.

At first glance, it looks like just another mapping library. In reality, it's a clever solution to a deceptively difficult problem:

How do you help computers reason about geography at scale?

So, What Is H3?¶

H3 is Uber's open-source hexagonal hierarchical spatial indexing system. Sounds like a mouthful, but the idea is simple. H3 divides the Earth into a hierarchy of mostly hexagonal cells, each with its own compact numeric ID, instead of raw coordinates or messy ZIP codes.

That one idea is why H3 quietly powers driver matching, surge pricing, demand forecasting, delivery logistics, and heatmaps at Uber.

Now here's the fun part: tiling a sphere with perfect hexagons is mathematically impossible. So H3 borrows a trick from a football. A football's surface is almost entirely hexagonal panels, with twelve pentagons scattered in to let the flat pattern curve into a sphere.

H3 does nearly the same thing. It projects the Earth onto a twenty-sided icosahedron, then builds hexagonal grids on top, with twelve unavoidable pentagons where the geometry demands them.

That's the headline. The rest of this post is just answering why: why Uber needed this, and why hexagons beat squares, ZIP codes, and raw coordinates.

The Problem¶

Imagine you're building a ride-sharing app. Thousands of passengers and drivers are moving around a city at any given moment.

The second someone requests a ride, your system needs answers fast: Which drivers are nearby? Which regions have unusually high demand? Where should surge pricing kick in?

Here's the catch: computers understand coordinates, but businesses operate on regions. A rider doesn't care whether a driver is at (37.775, -122.418). They care whether a driver is nearby.

Why Latitude and Longitude Alone Aren't Enough¶

The most obvious approach? Just compare coordinates directly. Unfortunately, precision isn't the same thing as organization.

Say you want every driver within a radius of a passenger. A naive approach means checking every driver's coordinates, calculating distances, and filtering results. That gets expensive fast as users grow.

Coordinates also give you no natural notion of neighborhoods. Two nearby points can have wildly different values.

Latitude and longitude tell us where something is. They don't help us organize the world.

Why Not Use ZIP Codes?¶

What about grouping users by ZIP codes, postal codes, or districts instead? Works fine for humans. The problem is these boundaries were built for governance, not computation.

Regions vary wildly in size and shape. Population density swings everywhere. Every country does it differently.

A ZIP code in Manhattan might cover a few streets. One in rural Karnataka might cover hundreds of square kilometers. For a global platform, that's a real headache.

A Better Idea: Divide the Earth into Grids¶

What if we made our own regions instead? Picture covering a map with graph paper: every location belongs to a cell, and operations happen on cells, not coordinates.

That gets you natural neighborhoods, easier aggregation, and faster searches in one move. The simplest version uses squares.

The Problem with Squares¶

Squares look great on paper. But stand inside one and four neighbors share an edge, while four more only touch you at a corner.

Not all neighbors are equally close. Moving north behaves differently than moving diagonally, and that bias is bad news for proximity search and clustering.

Ideally, every neighbor should relate to us the same way. That's where hexagons come in.

Why Hexagons?¶

Every hexagon has six neighbors, and every single one shares a full edge, no exceptions. Center-to-center distances stay far more uniform.

No "corner neighbor" weirdness like with squares. That makes searches, clustering, and neighborhood operations far more consistent.

So, problem solved? Just hexagon-grid the Earth and call it a day? Unfortunately, the Earth has one objection: it isn't flat.

The Earth Refuses to Cooperate¶

Covering a flat surface with hexagons is easy. Covering a sphere is not. It's mathematically impossible to tile a sphere with only perfect hexagons.

This is exactly the football problem from earlier. Twelve pentagons let the flat pattern curve into a sphere.

H3 runs the same play: project the Earth onto an icosahedron, build hexagonal grids on top, and slip in twelve pentagons wherever the geometry demands it.

Hierarchy: The Real Superpower¶

The geometry is impressive. The hierarchy is what actually makes H3 powerful.

Say we divide the Earth into millions of cells, what size should each be? Large cells lose precision. Small cells generate too much data. H3 sidesteps this entirely by maintaining multiple resolutions at once.

Think of Google Maps. Zoomed out, countries. Zoom in, states, cities, roads, buildings. H3 gives you the same idea: the same location, represented at whatever level of detail the problem needs.

import h3

cell = h3.latlng_to_cell(37.775, -122.418, 9)
h3.cell_to_parent(cell, 7)     # zoom out
h3.cell_to_children(cell, 10)  # zoom in

Adaptive Precision¶

A nice side effect of hierarchy: applications pick whatever resolution fits. Demand forecasting at neighborhood scale, heatmaps at medium resolution, driver matching at street level.

Dense cities get finer resolutions. Sparse rural areas get bigger cells. You decide the tradeoff.

Hexagons Are Nice. Indices Are Better.¶

Geometry alone doesn't solve everything. Once you've divided the Earth into millions of cells, you still need to identify each one.

H3 packs resolution, base cell, and hierarchical position into a single 64-bit integer:

h3.latlng_to_cell(37.775, -122.418, 9)
# '89283082837ffff'

Geographic regions become integers instead of floating-point coordinates. That means faster indexing, smaller storage, easier aggregation, better database performance.

Finding Nearby Cells with k-Ring¶

Back to ride-sharing. With H3, finding nearby drivers is just: find the passenger's cell, search it, then expand into neighbors. There's a utility for exactly this, k-Ring, which returns every cell within k steps of a target.

A k-Ring turns geographic proximity into graph traversal.

Mathematical Definition¶

$$kRing(c, k) = {x \mid d(c,x) \le k}$$

Where c is the origin cell, x is any cell, and d(c,x) is the shortest path distance on the hexagonal grid.

Predictable Growth¶

Hexagonal grids grow predictably. Cells exactly at distance k: 6k. Total cells within a k-Ring: 1 + 3k(k+1).

Conceptual Implementation¶

H3's real implementation is heavily optimized, but conceptually a k-Ring is just BFS over the hexagonal graph:

visited = {origin}
frontier = {origin}

for i in range(k):
    next_frontier = set()
    for cell in frontier:
        for neighbor in get_neighbors(cell):
            if neighbor not in visited:
                visited.add(neighbor)
                next_frontier.add(neighbor)
    frontier = next_frontier

return visited

# using h3 directly
h3.grid_disk(origin_cell, k=2)

How This Helps Uber¶

• Driver matching — check neighboring cells instead of the entire city.
• Surge pricing — aggregate demand and supply per cell.
• Heatmaps — collapse millions of coordinates into regions.
• Demand forecasting — analyze historical demand per cell for ML models.
• Delivery logistics — same tricks, food delivery, package routing, fleet management.

How Does H3 Compare to Other Approaches?¶

Geohash is mostly about efficient encoding. Google's S2 is built for spherical geometry. H3 leans into spatial analytics and locality.

You can find your regions h3 index from here