Geometry Catalogue

This page indexes every geometry type this knowledge base converts to or from H3, grouped by category. Each entry links to the dedicated conversion pages covering it in full; this page's job is to say, per group, what the geometry fundamentally is, what metadata it needs before conversion, and what goes wrong most often.

Administrative and statistical boundaries

Countries, states/provinces, counties, census geographies, DMAs, and postal areas. These are consumed as partitions: downstream reporting, budgeting, and compliance logic typically assumes every location belongs to exactly one region. Required metadata: boundary source, vintage, CRS, and a namespace for the id (FIPS, GEOID, ISO code, DMA id, ZIP/ZCTA). Common risks: boundary vintage drift (DMA and postal boundaries are redrawn periodically), leading zeros dropped from FIPS/GEOID strings by an integer cast, and postal codes specifically — a ZIP code is a USPS delivery-route abstraction with no authoritative polygon; any "ZIP polygon" in circulation is a third party's ZCTA approximation and must be labeled as such. See administrative polygon to H3.

Arbitrary polygons

Trade areas, geofences, and parcels: operator-drawn or model-generated shapes with no external authority governing their boundary. Required metadata is the generation method (drive-time model, gravity-model catchment, manual digitization), a vintage timestamp, and CRS. Common risks: self-intersection (bowtie rings from manual digitization or model artifacts), narrow slivers and tiny polygons that can legitimately yield zero center-contained cells, and holes that must be respected rather than filled through. See arbitrary polygon to H3.

Points

POI/store points, addresses, and device pings: a single coordinate that references a place rather than describing an extent. Required metadata is CRS, source, and a timestamp; device pings additionally need an accuracy radius and consent state, and addresses need the geocoder used and its match confidence. Common risks: geocoding uncertainty (rooftop vs. centroid placement), axis-order reversal, and — for device pings — IP-derived locations that are coarse and centroid-biased and must be labeled with the correct matching semantic rather than treated as physical presence. See point to H3.

Point + radius

A center coordinate with a geodesic radius — the native execution unit for many DSPs and the inverse of an H3 circle approximation. Required metadata is the radius units and whether the radius is geodesic or planar, since a planar radius diverges from a geodesic one as it grows or as latitude increases. Common risks: platform minimum-radius floors that reject small radii outright, and radius increments that round a requested radius up or down, silently changing coverage. See point-radius to H3.

Lines and trajectories

Road/transit lines and device trajectories: an unordered polyline versus an ordered, timestamped sequence of positions. Lines need CRS and direction; trajectories additionally need timestamps, sampling rate, and consent state, since an ordered high-resolution trajectory can be re-identifying even when individual points are not. Common risks: GPS noise causing boundary oscillation (a path skimming a cell edge flips back and forth between cells), and, for trajectories, exposure risk distinct from a single point's. See line and corridor to H3.

Multipoints

Bid requests, visits, conversions, sensor events: a collection of independent point observations rather than one coherent shape. Required metadata is CRS, per-observation timestamp, and a deduplication key. The central risk is duplicate observations — the same impression or visit counted more than once inflates audience or volume per cell — compounded by sparse-audience suppression requirements once the set is aggregated to cells.

Rasters

Gridded fields: population, elevation, weather, pollution, or signal-strength surfaces. Required metadata is CRS, native pixel resolution, the declared no-data sentinel, and band semantics. Common risks: unmasked no-data pixels corrupting an aggregate, a resolution mismatch between pixel size and target cell size producing false precision, and coastal or other mixed pixels straddling two categories without a clean per-cell label. See raster to H3.

Bounding boxes

A [west, south, east, north] envelope — a map viewport or query bound, not a shape describing any real-world extent. Required metadata is CRS and whether the box is a screen/viewport rectangle or a geographic envelope, since the two are easy to conflate. Common risks: a box crossing the antimeridian where west is numerically greater than east (a naive box-to-polygon conversion produces an inverted or world-spanning result), and rotated boxes that are not axis-aligned. See bounding box to H3.

Platform identifiers

Opaque or standardized identifiers — a postal id, a FIPS code, an ISO code, a DMA id, a publisher's own market label. This is the category the warning at the top of this page is about most directly: a platform identifier is never a geometry in its own right. Required metadata is the id namespace, the boundary vintage it was minted against, and the crosswalk source used to resolve it. Common risks: namespace ambiguity (two vendors' "market 12" mean different things), vintage mismatches between assignment and resolution time, and unmatched ids that silently drop out of a join instead of raising an error. See H3 to platform-native geography.

Cell sets

A set of H3 indices, possibly mixed-resolution and possibly compacted — the canonical interchange form this knowledge base converts everything else into and out of. Required metadata is the resolution (or confirmation that the set is mixed-resolution), whether it has been compacted, and the containment mode used to produce it. Common risks: parent-and-child cells in the same set double-counting shared area, and combining sets at different resolutions without normalizing first. See H3 compaction and uncompaction and mixed H3 resolutions.

Using this catalogue

Every conversion page here names its source and destination geometry types using the ids implicit in the groups above. When a new geometry type does not obviously fit one of these nine groups, ask which group's required-metadata list it actually satisfies — not which group its name resembles. A "trade area" delivered as a fixed-radius circle around a store point is a point+radius geometry, not an arbitrary polygon, regardless of what the source system calls it, and converting it as a polygon would silently drop the radius-units question the point+radius group forces.