# EPSG:3857 vs EPSG:4326 for Tile Delivery

The two CRS are not competitors: one is how a spatial estate stores data and the other is how it delivers tiles, and a domain that confuses the roles ends up either reprojecting on every request or shipping a tile grid its consumers’ clients cannot use. This guide sets out which belongs where, what each costs at the delivery boundary, and how to serve both without keeping two copies of the data. It applies the CRS conventions from CRS Governance and Reprojection Standards within Geospatial Data Mesh Fundamentals to the tile path described in Edge Caching and Tile Delivery Topology.

# Prerequisites

# Step-by-Step Implementation

# 1. Decide from the consumer, not from the data

The high-latitude row is a genuine constraint rather than a preference: EPSG:3857 is mathematically undefined outside roughly ±85.05° latitude, so a domain publishing Arctic or Antarctic coverage cannot serve it through a Web Mercator pyramid at all.

# 2. Serve Web Mercator tiles from geographic storage

ST_AsMVT projects at query time, so a single EPSG:4326 store serves a EPSG:3857 pyramid without a second copy.

-- mvt_tile.sql — a WebMercatorQuad tile, from EPSG:4326 storage.
-- Parameters: :z, :x, :y (integers)
WITH bounds AS (
    -- The tile's envelope in EPSG:3857, then back to 4326 for the indexed lookup.
    SELECT ST_TileEnvelope(:z, :x, :y)                       AS env_3857,
           ST_Transform(ST_TileEnvelope(:z, :x, :y), 4326)   AS env_4326
),
src AS (
    SELECT f.feature_id, f.attrs,
           -- Project only the features that survive the indexed 4326 filter.
           ST_AsMVTGeom(
               ST_Transform(f.geom, 3857),
               b.env_3857,
               4096,      -- tile extent in integer units
               64,        -- buffer, so features crossing the edge render cleanly
               true       -- clip to the tile
           ) AS geom
    FROM product_features f, bounds b
    -- && against the 4326 envelope uses the GiST index; transforming the COLUMN
    -- instead would make the index unreachable and scan the table.
    WHERE f.product = :'product' AND f.geom && b.env_4326
)
SELECT ST_AsMVT(src, 'features', 4096, 'geom') FROM src WHERE geom IS NOT NULL;

Verify the index is reachable — the difference between a tile served in milliseconds and one that scans the layer:

psql "$PG_DSN" -c "EXPLAIN (ANALYZE) $(cat mvt_tile.sql)" | grep -E 'Index Scan|Seq Scan'
# "Index Scan using ..._geom_idx" is correct. "Seq Scan" means the filter transformed
# the column rather than the envelope.

# 3. Publish both matrix sets where consumers need both

# product.yaml — two tile ports from one materialization.
spec:
  storage:
    crs: "EPSG:4326"                 # one canonical store
  ports:
    - type: tiles
      matrixSet: WebMercatorQuad     # EPSG:3857 — web clients
      zoom: { min: 6, max: 16 }
    - type: tiles
      matrixSet: WorldCRS84Quad      # EPSG:4326 — desktop GIS, polar-safe
      zoom: { min: 4, max: 14 }

Verify that the matrix set is part of the cache key, or the two pyramids will overwrite each other — they share z/x/y coordinates and are entirely different tiles:

a=$(curl -sS "https://$TILE_HOST/$PRODUCT/WebMercatorQuad/8/128/85.mvt" | sha256sum)
b=$(curl -sS "https://$TILE_HOST/$PRODUCT/WorldCRS84Quad/8/128/85.mvt" | sha256sum)
[ "$a" != "$b" ] && echo "matrix sets are distinguished" || echo "CONTAMINATION"

# 4. Measure what the projection actually costs

# Projection at query time is cheap relative to the spatial filter, but measure it
# rather than assuming — it scales with feature count, not with tile count.
psql "$PG_DSN" -c "\timing on" -c "$(cat mvt_tile.sql)" > /dev/null

# Configuration Reference

# Common Failure Modes & Fixes

Tiles are correct and the query scans the whole table. Root cause: the filter transforms the geometry column rather than the tile envelope, so the index cannot be used. Fix: transform the envelope into the column’s CRS, as above.

Features are clipped visibly at tile boundaries. Root cause: ST_AsMVTGeom buffer of zero, so a feature crossing the edge is cut exactly at it and the two halves do not join. Fix: a buffer of 64 units; the renderer discards the overlap.

Nothing renders above about 85° latitude. Root cause: EPSG:3857 is undefined there — this is not a bug. Fix: publish a polar matrix set for high-latitude coverage, and state the Web Mercator port’s latitude limit in the contract.

Distances or areas computed from delivered tiles are wrong. Root cause: measuring in EPSG:3857, where scale distortion grows with latitude and area is badly wrong away from the equator. Fix: measurement belongs against the EPSG:4326 store using geography, never against a delivery pyramid.

The two matrix sets return each other’s tiles. Root cause: matrix set absent from the cache key. Fix: add it; the symptom is misaligned geometry at some zoom levels and not others, which makes it easy to misdiagnose as a tiler bug.

# FAQ

# Related

• CRS Governance and Reprojection Standards — the parent topic and the CRS conventions
• Edge Caching and Tile Delivery Topology — why the matrix set must be in the cache key
• Standardizing on EPSG:4326 Across Domains — the canonical storage decision