Geohash and H3: Spatial Indexes Explained, with Real Data

A spatial index turns a coordinate into a cell ID. Two points in the same cell share an ID, so you can group, count and join location data with an ordinary GROUP BY or a key lookup instead of geometry maths. Geohash and H3 are the two cell systems developers meet most often.

They split the world in very different ways. To see what that means in practice, we took one real dataset, all 8,466 post boxes mapped in OpenStreetMap in the European Netherlands, and bucketed it with both systems at several sizes. This article explains how each index works and reports what we measured: cell sizes, occupancy, radius queries and how the hierarchies behave.

How geohash works

A geohash names a rectangle. The encoder starts with the whole world, longitude from -180 to 180 and latitude from -90 to 90, and halves one range at a time, alternating between longitude and latitude. Each halving writes one bit: 1 for the upper half, 0 for the lower. Every five bits become one character from the alphabet 0123456789bcdefghjkmnpqrstuvwxyz.

That gives geohash two useful properties, which the Redis GEOHASH documentation states plainly: you can shorten a geohash by removing characters from the right and it still points to the same area, and strings with a similar prefix are nearby, while strings with different prefixes can be nearby too.

This is the encoder we use on this site, from src/lib/geohash.ts, trimmed:

const BASE32 = '0123456789bcdefghjkmnpqrstuvwxyz';

function encodeGeohash(lat, lon, precision = 7) {
  let latR = [-90, 90], lonR = [-180, 180];
  let hash = '', bits = 0, value = 0, even = true;
  while (hash.length < precision) {
    const range = even ? lonR : latR;
    const coord = even ? lon : lat;
    const mid = (range[0] + range[1]) / 2;
    if (coord >= mid) { value = (value << 1) | 1; range[0] = mid; }
    else { value = value << 1; range[1] = mid; }
    even = !even;
    if (++bits === 5) { hash += BASE32[value]; bits = 0; value = 0; }
  }
  return hash;
}

encodeGeohash(52.3731, 4.8926, 7); // 'u173zq4', Dam Square, Amsterdam

Because the grid is regular in degrees, a geohash cell has a fixed size in degrees and a variable size on the ground. Lines of longitude converge towards the poles, so cells get narrower as latitude rises. We computed the sizes on a sphere of radius 6,371 km, the same one H3 uses:

The equatorial columns match the table in the Elasticsearch geohash grid documentation. At 52°N, the latitude of Utrecht, every cell covers 62% of its equatorial area. At 60°N, Oslo and Helsinki, it is exactly half.

How H3 works

H3 names a hexagon. Uber built it for analysing rides in cities and announced it in June 2018. It projects the Earth onto an icosahedron, starts with 122 base cells (110 hexagons and 12 pentagons), and subdivides each cell into roughly seven children per resolution, down to resolution 15.

Hexagons have one property squares lack. In Uber's words, hexagons have only one distance between a hexagon centre point and its neighbours', compared to two distances for squares. A geohash cell has four neighbours across an edge and four more across a corner; an H3 cell has six, all equally far away.

The price is the hierarchy. Seven hexagons cannot tile a larger hexagon exactly, so an H3 parent covers only approximately the same ground as its children. Cell areas also vary somewhat with position on the icosahedron: the H3 resolution table puts the ratio between the largest and smallest hexagon at close to 2 at fine resolutions, much less than geohash's variation between the equator and the Arctic.

The Dutch column is the mean area of the cells our post boxes landed in. Cells in the Netherlands are about 15% smaller than the global average, which is the icosahedron distortion at work. Within the country the spread is small: resolution 8 cells ranged from 0.605 to 0.646 km².

In JavaScript, with the current h3-js (version 4 names):

import { latLngToCell, cellToParent, gridDisk, cellArea } from 'h3-js';

const cell = latLngToCell(52.3731, 4.8926, 8);   // '881969c9b3fffff'
const parent = cellToParent(cell, 7);            // the coarser cell it belongs to
const nearby = gridDisk(cell, 1);                // the cell plus its 6 neighbours
const km2 = cellArea(cell, 'km2');               // area of this exact cell

The same post boxes, bucketed both ways

The dataset is every node tagged amenity=post_box in the European Netherlands, downloaded from the Overpass API on 29 September 2026. Post boxes follow population, so they cluster in cities and thin out in the countryside, which is the usual shape of location data.

We counted how many cells each system needs and how full they are:

Three findings from the table:

• The two ladders do not line up. Geohash cells shrink 32 times per character; H3 cells shrink about 7 times per resolution. Geohash 5 (14.6 km²) falls between H3 resolutions 6 and 7, so if you need a cell size between those steps, only one of the systems has it.
• Fine cells stop adding information quickly. At geohash 7 and H3 resolution 9, 98% or more of occupied cells hold exactly one post box. For this dataset, anything finer turns the index into a list of unique IDs.
• The densest cells are in Amsterdam. The fullest geohash 5 cell, u173z, covers the city centre and holds 62 post boxes. The fullest H3 resolution 7 cell, 21 post boxes, is centred in Amsterdam-Oost, which our reverse geocoder resolves to Van Musschenbroekstraat.

Radius queries: which cells to search

The most common job for a spatial index is "find everything within 500 m of this point". Neither system answers it directly. You look up a set of cells, collect the candidates, and then check the real distance. The trade-off is how many cells you touch and how many wasted candidates you have to check.

3,648 of the 8,466 post boxes have at least one other post box within 500 m, which gives 6,034 neighbour pairs, counted from both ends. We tested several lookups against that ground truth:

The first and fourth rows are the classic mistake. Grouping by cell and treating "same cell" as "nearby" missed 59% of real neighbours with geohash 6 and 51% with H3 resolution 8, because a post box near a cell edge has its neighbours in the next cell.

The rows that found everything differ in their guarantee, which we computed by sampling points inside one cell and measuring the distance to the edge of the searched area:

• Geohash 6 plus its 8 neighbours covers at least 611 m in every direction here, the height of one cell, so a 500 m search is always complete.
• H3 resolution 8 plus one ring covers at least about 465 m from a point near a cell corner. It found every pair in this dataset, but a 500 m search is not guaranteed. Two rings cover 1.2 km and cost more than twice as many candidates.
• H3 resolution 9 plus three rings covers at least 710 m and checked the fewest candidates, 4.5 per real neighbour, at the cost of 37 key lookups.

The geohash block has one more catch: its reach depends on latitude. At 60°N a precision 6 cell is 611 m wide, so the guarantee holds, but further north the width shrinks below 500 m. Compute the reach from the smaller of cell width and height at your latitude.

Hierarchies: exact prefixes vs approximate parents

Geohash nesting is exact by construction. Every one of our 8,466 post boxes has a precision 7 geohash whose first six characters are its precision 6 geohash. You can roll counts up from fine to coarse by cutting characters.

H3 nesting is approximate. For each post box we compared two things: the resolution 8 cell that contains it, and the parent of the resolution 9 cell that contains it. For 604 post boxes, 7.1%, the two differ. The same happened for 600 points between resolutions 8 and 7, and for 554 points between 10 and 7.

That is expected behaviour, since a parent is defined by the centre of its children, but it matters when you aggregate. Counts rolled up from resolution 9 to 8 with cellToParent put about 7% of points in a neighbouring cell compared with indexing at resolution 8 directly. Pick one method and use it everywhere in a pipeline.

The rectangle hierarchy has its own sharp edge. Two post boxes in Klarenbeek, Gelderland, stand 54 m apart, at Zutphenseweg and Oude Ardeweg. Their 9-character geohashes are u1k2cvzdp and u1k2fjbhh: they share only four characters, because a precision 5 cell boundary runs between them. Grouped by five-character prefix, they land in two different 15 km² cells.

Which one to use

• Use geohash when you need a string key that works in any database, exact parent and child relationships, or compatibility with systems that already speak it (Redis, Elasticsearch, many mobile SDKs). Account for latitude when you pick a precision.
• Use H3 when cells need comparable areas across a large region, when you smooth or compare neighbouring cells, or when you draw hexbin maps. Store the resolution you aggregate at, and index each point directly at every resolution you need instead of deriving parents.
• For radius searches with either, look up the cell plus a ring of neighbours, then filter on real distance. Check that the ring covers your radius at your latitude.

Method and limits

• Data: 8,471 nodes tagged amenity=post_box returned by the Overpass API for the Netherlands (OpenStreetMap data as of 29 September 2026, 21:43 UTC). We dropped 5 in the Caribbean Netherlands and kept 8,466. © OpenStreetMap contributors, ODbL.
• Encoders: geohash from this site's own src/lib/geohash.ts; H3 from h3-js 3.7.2, which has the same cell grid as version 4 under older function names.
• Distances: great-circle distance on a sphere of 6,371 km. Cell areas are spherical, as H3 computes them.
• What this does not measure: query speed in a real database, which depends on the storage engine more than the cell shape, or how complete OpenStreetMap's post box map is.

Related

To see the two scales in practice, draw a circle with the radius map or measure a cell-sized polygon with the area calculator. The coordinates tool converts any point you want to encode. For the maps these indexes usually feed, see how to build a heat map in JavaScript and the choropleth map guide. For the box a radius search starts from, read what a bounding box is.