# Standardizing on EPSG:4326 Across Domains

Declaring a single canonical CRS is easy; making every domain actually store, reproject, and deliver in it without silent axis-order bugs is the real work. This operation sits under CRS Governance and Reprojection Standards within Geospatial Data Mesh Fundamentals, and it walks the concrete rollout: name EPSG:4326 as the canonical storage CRS, reproject legacy EPSG:32633 and EPSG:3857 sources to it at ingest, enforce the choice with a contract check at the boundary, and get lon/lat axis order right so the authority’s lat/lon convention never leaks into storage. The end state is that every interior geometry is directly comparable, and a producer that ships a non-EPSG:4326 payload is rejected before it can pollute a cross-domain join — the same gate discipline that Data Contracts for Spatial Products applies to schema and semantics.

Figure — The four-step rollout: declare EPSG:4326 canonical, reproject legacy sources at ingest, enforce with a contract check, and verify with ogrinfo, with axis order asserted throughout.

# Prerequisites

# Step-by-Step Implementation

Roll out in order: declare the CRS, migrate legacy data into it, enforce it at the gate, then prove axis order is correct. Each step has a verification command before the next.

# 1. Declare EPSG:4326 as the canonical storage CRS

Codify the choice as configuration the whole mesh reads, not tribal knowledge. The declaration names the canonical CRS, fixes axis order, and lists the source projections allowed to be reprojected in.

# crs-standard.yaml — mesh-wide CRS declaration
canonical_crs: "EPSG:4326"
canonical_axis_order: "lon_lat"          # traditional GIS order, not authority lat/lon
source_crs_allowlist: [4326, 3857, 4269, 32610, 32611, 32633]
reproject_boundaries: [ingest, delivery] # interior reprojection prohibited
min_precision_decimals: 6                # ~0.11 m; guards round-trip loss

Verify the declaration parses and pins exactly one canonical CRS:

python3 -c 'import yaml,sys; d=yaml.safe_load(open("crs-standard.yaml")); \
  assert d["canonical_crs"]=="EPSG:4326" and d["canonical_axis_order"]=="lon_lat"; \
  print("canonical CRS declared: EPSG:4326 lon/lat")'

# 2. Reproject legacy EPSG:32633 / EPSG:3857 data at ingest

Sweep each legacy source into EPSG:4326, setting the source CRS explicitly rather than trusting the file, and forcing lon/lat order. The loop is idempotent — a source already at EPSG:4326 is copied unchanged, and re-running never double-reprojects.

#!/usr/bin/env bash
set -euo pipefail
export OGR_CT_FORCE_TRADITIONAL_GIS_ORDER=YES

for f in "${SRC_DIR}"/*.gpkg; do
  SRC_EPSG=$(gdalsrsinfo -o epsg "$f" 2>/dev/null | grep -oE '[0-9]{4,5}' | head -1)
  case "$SRC_EPSG" in
    4326|3857|4269|32610|32611|32633) ;;                # allowlisted
    *) echo "SKIP: $f has non-allowlisted EPSG:${SRC_EPSG}"; continue ;;
  esac
  out="canonical_$(basename "$f")"
  # Explicit -s_srs; -t_srs is always the canonical EPSG:4326.
  ogr2ogr -f GPKG "$out" "$f" \
    -s_srs "EPSG:${SRC_EPSG}" -t_srs EPSG:4326 -lco GEOMETRY_NAME=geom
  echo "reprojected $f (EPSG:${SRC_EPSG}) -> EPSG:4326"
done

Verify every output is now EPSG:4326 with ogrinfo:

for out in canonical_*.gpkg; do
  ogrinfo -so -al "$out" | grep -E 'ID\["EPSG",4326\]' >/dev/null \
    && echo "OK  $out -> EPSG:4326" || echo "FAIL $out"
done

# 3. Enforce the standard with a contract check at the boundary

A one-time migration is worthless without a gate that keeps new data conformant. Run a policy that admits a payload only when its declared CRS is the canonical one, so a producer that regresses to EPSG:32633 is rejected at ingress.

package crs.standard

import rego.v1

default allow = false

allow if {
    input.payload.crs_epsg == 4326
    input.payload.axis_order == "lon_lat"
}

Verify the gate rejects a non-canonical payload and admits a canonical one:

echo '{"payload":{"crs_epsg":32633,"axis_order":"lon_lat"}}' \
  | opa eval -I -d crs-standard.rego -f raw "data.crs.standard.allow"   # -> false
echo '{"payload":{"crs_epsg":4326,"axis_order":"lon_lat"}}' \
  | opa eval -I -d crs-standard.rego -f raw "data.crs.standard.allow"   # -> true

# 4. Handle axis order and load into canonical storage

EPSG:4326’s authority order is latitude-then-longitude, but GeoJSON, OGC API Features, and most tooling use longitude-then-latitude. Keep OGR_CT_FORCE_TRADITIONAL_GIS_ORDER=YES set on load so storage is unambiguously lon/lat, then load into PostGIS.

export OGR_CT_FORCE_TRADITIONAL_GIS_ORDER=YES
ogr2ogr -f PostgreSQL "PG:${PGURI}" canonical_parcels.gpkg \
  -nln parcels_4326 -lco GEOMETRY_NAME=geom -nlt PROMOTE_TO_MULTI

Verify the stored SRID is 4326 and coordinates are lon/lat (longitude in the ±180 range, latitude in ±90) with a spot check:

psql "$PGURI" -tAc \
  "SELECT ST_SRID(geom),
          ST_X(ST_PointOnSurface(geom)) BETWEEN -180 AND 180,
          ST_Y(ST_PointOnSurface(geom)) BETWEEN -90 AND 90
   FROM parcels_4326 LIMIT 1;"
# expect: 4326|t|t

# Configuration Reference

# Common Failure Modes & Fixes

Features land in the wrong hemisphere after migration. Symptom: points plot near (lat, lon) instead of (lon, lat). Root cause: OGR_CT_FORCE_TRADITIONAL_GIS_ORDER was unset, so GDAL honored EPSG:4326’s authority lat/lon order. Fix: export OGR_CT_FORCE_TRADITIONAL_GIS_ORDER=YES, re-run Step 2, and confirm with the Step 4 range check.

A legacy source is skipped silently. Symptom: some datasets never appear in canonical storage. Root cause: the source CRS was outside source_crs_allowlist, so the loop’s continue skipped it. Fix: reproject the source upstream to an allowlisted CRS, or add the projection through a governed allowlist change and re-run.

ogr2ogr reprojects but distances are still wrong. Symptom: a buffer query returns unexpected sizes. Root cause: metric operations were run against EPSG:4326 degrees. Fix: reproject to a metric CRS for the calculation only (ST_Transform(geom, 32633)), keeping storage in EPSG:4326; never store the metric copy.

Producer regresses to EPSG:32633 after go-live. Symptom: new payloads carry a non-canonical CRS. Root cause: the boundary gate was not wired into the producer’s path. Fix: attach the Step 3 policy as an admission check; a false decision returns 409 and blocks the write.

# FAQ

# Related

• CRS Governance and Reprojection Standards — the governance model this rollout implements
• Data Contracts for Spatial Products — the contract surface the CRS gate enforces
• Versioning Spatial Data Contracts with SemVer — why a stored-CRS change is a major version bump
• Metadata Cataloging for Raster/Vector — records the declared CRS after migration