Cell System Comparison | EtherData Blog

A matrix comparison of H3, S2, and Geohash across shape, hierarchy, equal-area, and containment behavior, and why cross-system conversion always goes through polygon union and re-fill.

Purpose

This knowledge base treats H3 as the canonical interchange grid, but not every input or platform is H3-native, and the generic documentation model must not silently assume properties that are true of H3 but false of the other discrete global grid systems in use elsewhere in the ecosystem. This page is the comparison matrix and the explicit statement of what must never be assumed generically across systems.

Why this knowledge base standardizes on H3

The AdCP (Ad Context Protocol) committee has accepted three cell systems as interoperable options: H3, S2, and quadkeys. This knowledge base recommends H3 as the default and treats it as the canonical interchange grid throughout; S2 and Geohash are documented here for contrast, not as alternates in active use. H3's hexagonal cells give every non-pentagon cell a uniform distance to its six neighbours and compact well into multi- resolution sets, which is why H3 rather than a quadrilateral or rectangular scheme is the standard.

Comparison matrix

Dimension	H3	S2	Geohash
Cell shape	Hexagon (mostly), 12 pentagons per resolution	Quadrilateral	Rectangle
Hierarchy model	Aperture-7; each parent has approximately 7 children	Quad; each parent has exactly 4 children	Base-32 prefix; each level adds 32x subdivision
Children per parent	~7 (not exact by area)	Exactly 4	32
Equal-area	Approximate (varies ~2x globally)	No	No (shrinks toward poles)
Exact parent-child geometric containment	No — logical index arithmetic, children can spill past parent boundary	Yes — 4 children exactly tile the parent	Yes — prefix relationship is an exact containment
Global coverage	Yes	Yes	Yes
Index representation	64-bit index, hex string	64-bit cell id (Hilbert curve position)	Base-32 string
Compaction support	Yes (`compactCells`/`uncompactCells`)	Yes	No
Key caveats	12 pentagons/resolution; face-crossing distortion; ~2x area variance	Not equal-area; 4 or more neighbours depending on position	Not equal-area; alternating aspect ratio; antimeridian/edge discontinuity between adjacent prefixes

What the generic model must not assume

No property below is universal across systems

Every one of these is true of H3 specifically and false of at least one other system in this table. Code, prose, or a schema field that encodes any of these as a general "cell system" property rather than an H3-specific one is a latent bug the first time a non-H3 system reaches it.

Hexagons: Only H3 has hexagon-dominant cells, and even H3 is not all-hexagon. S2 is quadrilateral, Geohash is rectangular.
Six neighbours: True only for non-pentagon H3 cells. S2 cells have 4 edge neighbours (more at corners); Geohash rectangles have 4.
Uniform cell shape: H3 mixes hexagons and pentagons; the other two systems are each uniform in shape, but that shape differs system to system — 'uniform' does not imply 'hexagon.'
H3 resolution numbering: H3's 0-15 scale, its aperture-7 area ratio per level, and its pentagon count per level are H3-specific. S2's 0-30 levels and Geohash's 1-12 character lengths are independent, with no direct level-to-level equivalence.
Identical hierarchy semantics: 'Hierarchical' does not imply the same containment guarantee. S2 and Geohash give exact geometric/prefix containment; H3 gives logical-only containment.
Exact parent-child containment: Only S2 (exact quad tiling) and Geohash (exact prefix containment) guarantee this. H3 explicitly does not — treating an H3 parent-child relationship as exact containment is a documented source of silent boundary error.

Cross-system conversion has no direct cell-to-cell map

There is no lookup table mapping an H3 cell index directly to an S2 or Geohash index, because the three systems tile the sphere with different geometries at different resolutions — no cell boundary in one aligns exactly with any boundary in another. The only correct conversion path is geometric, not index-based:

$\text{cells}_A \xrightarrow{\text{cellToBoundary (system A)}} \text{polygon} \xrightarrow{\text{union}} \text{region} \xrightarrow{\text{polyfill (system B)}} \text{cells}_B$

Extract each source cell's true boundary polygon in the source system (cellToBoundary or the equivalent for S2/Geohash).
Union the boundary polygons into a single region (or multipolygon, with antimeridian handling per antimeridian-handling if applicable).
Re-fill that region into the destination system using the destination system's own polyfill operation and containment mode (center, full, intersect, or the destination system's equivalent).

This path necessarily introduces the same containment-mode approximation error documented throughout the source-to-H3 conversion pages, applied a second time if round-tripping — a cell set converted H3 to S2 and back is not guaranteed to reproduce the original exactly, and the discrepancy should be measured with coverage_ratio and jaccard, not assumed zero.

Resolution behavior across systems

Because the three numbering systems are independent, "matching resolution" across systems requires an explicit area-based correspondence (choosing the H3 resolution, S2 level, and Geohash length whose typical cell areas are closest) rather than assuming numeric equivalence — an H3 resolution 7 cell and an S2 level 13 cell are not defined to correspond by their numbering; any correspondence used here is an approximate area-match stated explicitly, not a system property.

Quality metrics

coverage_ratio, overreach_ratio, underreach_ratio, and jaccard computed on the re-filled destination cell set against the union polygon produced in step 2 above — the standard metrics apply unchanged across systems since they are defined on areas, not on index arithmetic.

Edge cases

pentagons affects H3 (12 per resolution) and requires per-cell shape handling rather than a hexagon-derived constant. mixed-resolutions applies within any single system's own hierarchy (see mixed-h3-resolutions) and is a distinct concern from cross-system resolution correspondence discussed above — do not conflate mixing resolutions within H3 with matching resolutions across systems.

References

H3 — Uber, h3geo.org
S2 Geometry — Google, s2geometry.io

Assumptions and limitations

The matrix above reflects the generic system models registered in data/cell-systems.yaml as of this page's review date; exact resolution ranges, compaction support, and containment guarantees should be re-verified against each system's current documentation before relying on them for a production decision.

Illustration — hexagon vs pentagon shape

The inner (green) and outer (amber) circles show each cell is only approximately regular; the pentagon's boundary carries extra vertices where it crosses an icosahedron edge.

Illustration — the same area, three systems

Rendered from the tested conversion code · One ~1.2 km area tiled by H3 (hexagons), S2 (quads), and Geohash (rectangles) — real cells from each library. H3 is the AdCP-accepted default used throughout this knowledge base.