Every digital map trades accuracy for the shape it needs

Computers never store “the world.” They store lists of numbers. Those lists only agree when everyone uses the same rulebook for what each number means: how Earth is modeled, whether you stay in latitude and longitude or flatten it onto a flat map in meters or square tiles, and whether a boundary is measured geometry or just enough detail to paint pixels.

When you choose H3, S2, or how web tiles chop the map, you choose one rulebook for your stack.

Latitude and longitude are angles on an agreed Earth model

Latitude and longitude are not Cartesian meters on the ground. They are angles measured against a reference ellipsoid plus a datum that nails that ellipsoid to the planet’s crust well enough for the job. Change the datum or realization and “the same” pair of numbers can land meters away from someone else’s notion of the same spot.

WGS 84 is the usual answer when GPS phones and web maps talk to each other. People bundle that habit under registry codes such as EPSG:4326 (geographic longitude/latitude on the WGS 84 datum). Saying “4326” is shorthand for “these angles assume this Earth.” Skip the shorthand in boundary-sensitive work and you get silent drift between datasets collected years apart.

That matters before you ever pick H3 or S2. Both libraries assume you already handed them spherical-ish coordinates consistent with how they document their inputs.

Projection: stretching the sphere so rectangles tile

Longitude/latitude is awkward for screens and many geometric tricks on a plane. A projection maps the curved Earth onto 2D coordinates in meters or arbitrary units.

Most slippy maps use Web Mercator, commonly labeled EPSG:3857. Tiles become squares at each zoom level; math stays cheap for billions of requests. The trade is honesty about area and shape far from the equator. Web Mercator is built for consistent tiles on the web, not for rigorous acreage.

Microsoft’s tile-system write-up spells out another blunt detail under the hood: web tiling stacks often use a spherical Mercator variant because it simplifies implementation, accepting small scale distortion versus an ellipsoidal Mercator (Bing Maps tile system). Basemap pipelines routinely bake that compromise in.

Mix up 4326 (degrees on the ellipsoid) with 3857 (meters on the Mercator plane) in one pipeline and features swim into the ocean. The coordinates still parse; they just describe the wrong place once you overlay another layer.

Boundaries as files versus boundaries as tiles

Software expresses boundaries in layers:

Exact-ish geometry interchange. GeoJSON ships points, lines, and polygons as nested coordinate arrays plus JSON properties. The Internet Standard fixes coordinate semantics to WGS 84 and longitude/latitude order as described there. Older approaches tried optional CRS tags; RFC 7946 trimmed that surface area so parsers interoperate. If you truly need another CRS, you transform elsewhere or pick another container.

Database lingua franca. Well-known text (WKT) and well-known binary (WKB) come out of OGC Simple Features. PostGIS and friends store geometries plus an SRID so “this polygon lives in this CRS.” The bytes are useless metadata unless both ends agree on that SRID story.

Tiles for pixels. Classic raster maps split the projected plane into 256×256 cells addressed by zoom z and indices x/y. Conventions called XYZ or slippy tiling line up with how OpenStreetMap-style stacks fetch imagery (Slippy map tilenames).

Quadkeys. Another naming trick encodes parent tiles as prefixes of child strings by interleaving bits of x and y (same tile-system doc). Prefix containment maps cleanly onto caches and key-value layouts.

Vector tiles. Mapbox Vector Tiles (MVT) pack clipped, simplified geometries into protobuf blobs keyed by tile coordinates. They are a delivery optimization for rendering layers at zoom. Treat them like JPEGs for maps: great over the wire, not your archival survey record.

Prefix buckets. Geohash trades arbitrary polygons for approximate rectangles keyed by strings good enough for proximity caches or rough prefixes in databases. Nearby places do not always share long prefixes across hash borders; naïve string ranges duplicate or miss neighbors.

Those formats answer different questions than global grids: preserving drawn semantics, shaving bytes over the wire, cheap prefix lookups, or stable buckets shared across teams.

Two global grids: Uber H3 and Google S2

Both slice the sphere into hierarchical cells with compact 64-bit identifiers. Neither replaces legal parcels or shoreline surveys.

Uber H3: hexagons with twelve unavoidable exceptions

H3 builds a discrete global grid meant for analytics where neighborhood steps matter more than owning strict quad containment.

The docs sketch construction roughly:

Start from an icosahedron embedded in the sphere.
Lay out hexagonal-ish cells per face and project with an inverse face-centered gnomonic mapping back onto the sphere.
Orientation follows a Fuller-style placement so icosahedron vertices sit in oceans as much as practical.

Resolution 0 exposes 122 base cells: mostly hexagons plus exactly twelve pentagons anchored at icosahedron vertices. You cannot tessellate a sphere with regular hexagons alone; Euler’s bookkeeping insists on twelve degree-five vertices somewhere. Those pentagons remain special cases at every resolution.

Hierarchy steps use aperture 7: each cell subdivides into about seven finer cells across fifteen finer resolutions (overview). APIs emphasize uniform edge-adjacent neighbors (six on hex cells, five on pentagons) and rings such as grid disks for spreading aggregation outward.

H3’s own comparison with S2 stresses where its guarantees differ from quad schemes: hex neighborhoods behave uniformly for smoothing-style workflows; parent-child containment after truncating IDs is approximate, which bites pipelines that assumed bitwise ancestry equals geometric containment.

If your mental model is “six-ish symmetric neighbors” and fleet-wide buckets that analysts can reuse without bespoke polygons, H3 matches how people talk about space more often than quads do.

Google S2: cube quads and Hilbert-shaped locality

S2 is a spherical geometry workspace where cells are one primitive among predicates, coverings, and distances.

Mechanically (cell hierarchy guide):

Project six cube faces onto the unit sphere with a nonlinear warp so projected cells stay closer to uniform area than naive linear cube mapping allows.
Each face subdivides into four spherical quadrilaterals per level (aperture 4), up to thirty refinement bits in the packed cell ID layout.
Cell IDs trace a stitched Hilbert curve across faces so sorting IDs tends to preserve spatial locality on disk or in logs.

Square cells split adjacency into two notions you cannot pretend away: four edge neighbors, and corners where two cells touch only at a vertex. Hilbert ordering gives strong forward locality when you sort IDs, but nearby geography does not always imply nearby IDs (same hierarchy doc).

Cell boundaries are treated as closed sets in typical predicates: boundary points can belong to multiple cells unless your calling convention trims overlaps. That detail fuels duplicate counting bugs when naive dedupe assumes each GPS fix owns exactly one leaf cell.

Reach for S2 when bitwise parents should track geometry, when messy regions ship as unions of cells, or when sorted IDs ought to keep sequential disk reads warm.

Putting the contrast to work

Pressure	H3 leans…	S2 leans…
“Neighbors should mean one obvious graph step.”	Hex adjacency plus rings (comparison).	Separate edge neighbors from vertex-touch neighbors (hierarchy doc).
“Truncating my ID must equal climbing the spatial tree.”	Approximate unless you verify containment assumptions (comparison).	Quad refinement aligns exact parent-child containment for indexed points (curve ordering discussion).
“Singularities live somewhere ugly.”	Twelve pentagons forever (overview).	Cube vertices and projection seams shaping adjacency counts (hierarchy doc).

Uber wrote about using hex buckets for ride demand (Uber blog on H3). Google released S2 as open source after building geographic products on it (announcement). Blog posts motivate the shapes; API docs state what truncating an ID actually implies.

Before you argue grids

Pin down coordinates first (datum, EPSG code), projection if any (especially 4326 versus 3857), and whether your geometry is authoritative (GeoJSON, database WKT) or rendered (vector tiles, XYZ tiles).

Then ask what failure looks like:

Double-counted riders along shared tile edges?
Heatmaps biased because neighborhoods mean diagonal touching plus orthogonal touching differently?
Analytics keyed on truncated cell IDs assuming inheritance properties the math never promised?

Earth stays round; recorded parcel lines stay political; disk and CDN caches stay rectangular. Ship the approximation you can defend when two dashboards disagree by a city block.