S2 and H3: hierarchical cells

Why it matters

Geohash works, but its rectangles are different shapes at different latitudes, neighbours across a boundary share nothing, and a cell's eight neighbours are at two different distances (edge versus corner). When a company's core product is maps, pricing by area or matching supply to demand across a city, those flaws cost real money and accuracy. Google's S2 and Uber's H3 are the two grid systems built to fix them, and they are what large location platforms index with today.

The idea

Both systems assign every point on Earth a cell id at each of many resolutions, with the property that a cell's id encodes its position in a hierarchy, so coarser cells contain finer ones. Both avoid latitude-longitude rectangles by projecting the sphere onto a better-behaved shape. They differ in what cells look like and what they optimise.

S2: a cube, a Hilbert curve and 64-bit ids

S2 projects the sphere onto the six faces of a cube and recursively quarters each face into cells, 30 levels deep down to a centimetre. Cells at a level are nearly equal in area everywhere on Earth. Within a face, cells are ordered along a Hilbert curve, a space-filling curve that keeps nearby cells close in the one-dimensional ordering far better than geohash's Z-order, so a range of ids is a compact region. A cell id is a 64-bit integer whose prefix structure encodes its ancestors, making "is this cell inside that one" an integer comparison. S2 also computes coverings: a small set of cells of mixed levels that approximate any region (a polygon, a circle), which turns "is the point in this delivery area" into "is the point's cell id in this set of ranges".

H3: hexagons at 16 resolutions

H3 tiles the Earth with hexagons (plus exactly twelve pentagons needed to close the sphere) at resolutions 0 through 15, from continent-sized to under a square metre. Hexagons have a property squares lack: every neighbour is the same distance from the centre, so distance-based operations (rings of neighbours, smoothing, flow between adjacent cells) are uniform in all directions. Each finer resolution subdivides a cell into roughly seven children, which is approximate rather than exact nesting, a deliberate trade for the hexagon's geometry. Ids are 64-bit integers too, with fast functions for neighbours, rings, parent and children.

Which to use for what

Need	Geohash	S2	H3
Simple nearby lookup in an existing store	Good	Good (int64 ranges)	Good (cell + k-ring)
Exact hierarchical containment	Prefix strings	Exact: integer prefix	Approximate: children do not tile parent exactly
Region coverage (is point in polygon)	Awkward	Excellent: coverings as id ranges	Good: polyfill to cells
Aggregation and analytics by area	Uneven cells	Equal-area cells	Equal-area hexagons; uniform neighbours
Distance-based smoothing, rings, flows	Poor	Fair	Excellent
Ecosystem	Everywhere	Google, open-source library	Uber, open-source, strong analytics tooling

Using cells in a system

Index points by cell id at a chosen resolution in any store (a sorted set, a B-tree column, a partition key) and query by cell plus neighbours or by covering ranges. Aggregate demand, supply and prices per cell per time window for heatmaps and surge pricing; H3's uniform rings make spreading a signal to adjacent areas simple. Partition data geographically by coarse cells so each shard holds a region. Store cell ids as 64-bit integers, which compress, sort and compare fast. Resolution choice follows the same logic as geohash precision: match the cell to the question's spatial scale and go finer where density demands.