**Note** from Bead: Crs Strategy · [canonical source](https://redfish.acequia.io/guerin/.agents/c6a0e375-a699-45cc-8c8c-f2bf4558e930/2026-07-02/notes/00-crs-strategy-matrix.md) · session 2026-07-02 · discussion: Talk: Crs Strategy
A CRS is a choice of tradeoffs, never free. You cannot flatten a curved Earth without giving something up; every projection preserves some properties and distorts others (Tissot's indicatrix makes this literal). So the question is never "what is the right CRS" but "what does this *use* need preserved, and what can it afford to distort."
## The properties that drive the choice - **Distortion class** (what is preserved): *conformal* (local angles/shape; Mercator, Transverse Mercator, LCC), *equal-area* (area; Albers, Mollweide, Equal Earth, EASE-Grid), *equidistant* (distance along certain lines), *compromise* (none exactly; Robinson, Winkel Tripel, plate carree). You get at most one of conformal/equal-area globally. - **Units:** degrees (geographic) vs meters/feet (projected). Degrees are not a length; 1deg lon shrinks with cos(lat). Never compute area/distance in degrees. - **Global vs zoned:** a global CRS covers everything at low accuracy; a zoned CRS (UTM 6deg zones, State Plane) is accurate only inside its zone. - **Datum / realization / epoch:** WGS84 vs NAD83(2011) vs ITRF2014; plate motion means a point's coordinates drift ~cm/yr, so high accuracy needs an epoch. Horizontal datum != vertical datum (ellipsoidal height vs geoid/orthometric). - **Ecosystem support:** what clients/tilers/catalogs expect (XYZ tiles assume 3857; STAC/GeoJSON assume 4326).
## The CRS families | CRS | What it is | Preserves | Best for | Weak for | |-----|-----------|-----------|----------|----------| | **EPSG:4326** WGS84 lon/lat | Geographic, degrees | nothing metric (it's not a projection, it's the datum on a lat/lon grid) | **interchange, catalog metadata, GPS-native storage** (STAC bbox, GeoJSON, most APIs) | display (plate-carree stretch), any measurement, tiling on a mercator basemap | | **EPSG:3857** Web Mercator | Conformal, meters (spherical) | local shape/angle | **web display + XYZ/slippy tiles** (Google/OSM/Leaflet/MapLibre/deck.gl) | area (huge inflation toward poles), anything above ~85.06deg lat, precise measurement | | **UTM** (EPSG:326xx N / 327xx S) | Transverse Mercator, 6deg zones, meters | conformal, low distortion in-zone | **regional measurement, analysis, engineering** within one zone | crossing zone boundaries; global mosaics | | **State Plane** (e.g. **EPSG:6529** NM Central ftUS) | LCC/TM, survey-tuned zones, ft/m | conformal, very low distortion in-zone | **survey/cadastre/site engineering, US local high accuracy** | outside its state zone; ftUS vs int-ft foot-guns | | **Equal-area** (Albers **5070** CONUS, **6933** EASE-Grid, Mollweide, Equal Earth **8857**) | Equal-area | area | **area statistics, density/choropleth, land-cover accounting, global rasters** | shape (visibly sheared); navigation | | **ECEF geocentric** (**EPSG:4978**) | 3D Cartesian XYZ from Earth center | true 3D geometry | **3D globe rendering (Cesium/USD), ray/line-of-sight, GNSS** | 2D maps; human-readable coords | | **Local tangent ENU / site frame** | East-North-Up plane at a local origin | local metric geometry | **photogrammetry/SfM, robotics, per-site AR, tight local accuracy** | anything beyond the local patch; needs tie to a global frame | | **Pixel / CRS:Simple** | Image row/col, no georeference | image topology only | **quick raster view, un-georeferenced data** | any real-world location or overlay |
## Use-case -> recommended CRS - **Interchange / catalog metadata (STAC, GeoJSON, "what is the bbox"):** **EPSG:4326.** STAC mandates the item `bbox`/`geometry` in 4326; GeoJSON is 4326 by spec. This is why the COG converter defaults to 4326 (interchange-first) with 3857 available. See project_stac-management-is-emergent. - **Web display / slippy tiles:** **EPSG:3857.** The whole XYZ tile ecosystem is built on it. A 4326 raster must be reprojected to sit on a mercator basemap (the Leaflet viewer in bead `3d011d4e` does this per tile). - **Storing the authoritative pixels:** **keep the source's native/projected CRS** (here 6529). Reprojecting-and-resampling for storage bakes in error and a display bias; keep the capture CRS as truth and reproject on read. See [01-reproject-on-read-vs-store.md](01-reproject-on-read-vs-store.md). - **Measuring distance/area, raster analysis, stats:** **a local projected CRS** (UTM or State Plane) for distance, or an **equal-area** CRS for area/density. Never in 4326 or 3857. - **3D globe / line-of-sight / camera pose on a globe:** **ECEF (4978)** or 4326 + ellipsoidal height. Ties to the geo.camera/panosphere work (project_hubler-is-the-bead-network-name and the astronomical-pano bead). - **Photogrammetry / high-accuracy local / AR:** a **local ENU tangent frame** anchored at a site origin, soft-constrained back to a global CRS by tie-points/GCPs. Ties to feedback_every-constraint-is-soft and the pose/tie-point vocabulary.
## The acequia stance: CRS is a soft, per-interaction facet of a place-URI In the place-as-origin frame (project_livetiles-user-host-layer notes 02/03), a location is a URI and its CRS is a *facet negotiated at interaction time*, not a single reified truth. The same asset can be delivered in 4326 for a catalog, 3857 for a tiler, or native for a surveyor. This is CRS content-negotiation, the same duck-typing as project_agent-as-file-ducktyping: "keep original" in the converter is the honest default (don't destroy the source), and any target CRS is a derivation. And per feedback_every-constraint-is-soft: a pixel's ground position is the current minimum of an error surface (datum, epoch, tie-points), so a CRS label is a soft prior, reweightable by later calibration, not an absolute.
## Foot-guns worth stating - Bare `3857` is not a valid SRS token; GDAL/proj want `EPSG:3857`. (This bit the COG converter.) - Axis order: 4326 is lat,lon in the EPSG authority but lon,lat in GeoJSON/most software. Mismatches flip the map. - ftUS vs international foot: State Plane in survey feet differs from int-ft by 2ppm, meters of error over a state. - Web Mercator uses a *sphere*, not the WGS84 ellipsoid, so 3857<->4326 is not a plain datum passthrough; treating them as identical introduces ~km-scale northing error. - 4326 stored as a raster is plate carree: fine for storage/interchange, visibly stretched if displayed raw.