Purpose
Every conversion in this knowledge base assumes its input is valid EPSG:4326 geometry with a correct, current boundary vintage. That assumption fails routinely, in specific and detectable ways. This page is the checklist run before normalization: nine failure modes, each with a detection test cheap enough to run on every incoming record and a mitigation that does not silently guess at the correct value.
Wrong or missing CRS
A geometry supplied without an explicit CRS is frequently assumed to be EPSG:4326 by convention, but shapefiles and some GIS exports default to a state-plane or UTM projected CRS instead. Detection: coordinate magnitudes outside [−180, 180] for longitude or [−90, 90] for latitude immediately rule out unprojected geodetic degrees — a value of 487213.6 is a projected easting, not a longitude. Mitigation: require an explicit CRS tag on ingest and reject records without one rather than defaulting to EPSG:4326; if a CRS is declared but suspect, range-check before trusting it, and reproject explicitly rather than relying on downstream code to "figure it out."
Axis-order reversal (lat/lng swap)
GeoJSON specifies [longitude, latitude]; many non-GeoJSON sources (some
CSV exports, legacy APIs) use [latitude, longitude]. A swapped point in
the continental US (actual [-97.5, 35.2] stored as [35.2, -97.5])
produces a coordinate that is still in valid range but lands in the wrong
hemisphere. Detection: a coordinate out of range in its declared order
but valid when swapped is diagnostic; more generally, cross-check a sample
against a known reference (does the [lat, lng] reading place the
record's stated city inside the right country's bounding box?).
Mitigation: range-check both interpretations and swap when only one is
valid; when both orders produce a plausible point (common near the equator
and prime meridian, where the ranges overlap), reject rather than guess —
a silent swap in the ambiguous zone is worse than a flagged gap.
Stale boundaries
Administrative, postal, and DMA boundaries are revised periodically (annual
DMA realignments, postal code splits, county adjustments after annexation).
Using an old vintage assigns points and cells to a boundary that no longer
matches the authority's current definition. Detection: compare the
boundary dataset's effective date against the activity period being
analyzed; any boundary older than the most recent known revision is
suspect. Mitigation: version every boundary explicitly with
validFrom/validTo, and record which vintage was used in the
ConversionRecord for every crosswalk — never treat "the boundary file we
have" as "the boundary in effect on the date in question."
Duplicated region IDs
A data-quality error where the same administrative or postal ID is attached to two or more disjoint polygon features — most often from a bad join or an un-deduplicated append of two vintages. This breaks every partition assumption downstream: a max-overlap or weighted crosswalk keyed on that ID silently sums or selects across features that are not the same region. Detection: group features by ID and flag any ID mapping to more than one geometry that is not a legitimate multipolygon. Mitigation: dedupe or union by ID at ingest, and fail loudly — reject the batch — rather than silently picking one of the duplicates.
Rounded or truncated coordinates
Bidstream and some third-party feeds round coordinates to 2–3 decimal places to reduce payload size or as a privacy measure, snapping a point to a grid far coarser than it implies (2 decimals is roughly 1.1 km at the equator; 3 decimals is roughly 111 m). Detection: check the number of significant decimal digits present; fewer than 4 (roughly 11 m or coarser) is suspect for any point-level conversion. Mitigation: cap the effective H3 resolution to one consistent with the coordinate's actual precision — assigning a 2-decimal point to an R9 cell (roughly 0.1 km²) implies false precision; treat it as "somewhere within this larger cell," not an exact location.
Incomplete geometry
A polygon record with an open ring, a missing final closing vertex, or a truncated coordinate array (a common symptom of a failed export or a size-limited API response). Detection: check ring closure (first vertex equals last vertex) and a minimum vertex count (a ring needs at least 4 positions: 3 distinct vertices plus the closing repeat). Mitigation: close open rings only when the gap is a single missing repeat of the first vertex; reject rings with fewer than the minimum or with a gap large enough that closing it would materially change the shape, rather than auto-closing across an arbitrary gap.
Geocoding uncertainty
An address geocoded to a point carries an accuracy tier (rooftop, parcel centroid, street interpolation, city centroid) that is frequently dropped by the time the point reaches a conversion pipeline, leaving a point that looks rooftop-precise but is actually a city centroid. Detection: require the geocoder's accuracy tier to travel with the point as metadata; its absence on a geocoded, non-GPS point is itself the signal. Mitigation: cap the effective resolution used for downstream cell assignment to match the disclosed accuracy tier, as with rounded coordinates above.
Zero-island coordinates
A point at exactly (0, 0) — the equator/prime-meridian intersection, in
open ocean off West Africa — is the default, unset value for many numeric
coordinate fields (an uninitialized float pair, a failed geocode with nulls
coerced to zero, a parsing error). It is a valid coordinate but is
disproportionately never a real observation. Detection: flag any
record at (0, 0) to within floating-point tolerance for review rather
than accepting it as a legitimate ping. Mitigation: treat as a
missing-value sentinel by default; accept as real only with explicit
corroborating evidence.
Assumptions and limitations
All range checks in this page use the standard geodetic bounds: longitude in [−180, 180], latitude in [−90, 90]. These checks catch out-of-range and swap-detectable errors; they do not catch a coordinate that is in-range, correctly ordered, and still simply wrong (a correct-looking point placed at the wrong address) — that class of error requires corroboration against an independent source, which is outside the scope of coordinate-level validation.