Datum vs Projection: What's the Difference and Why It Matters

Almost every coordinate-system error in GIS comes from confusing two concepts that sound similar but answer different questions. Get this straight once and most "why is my data 3 metres off?" headaches disappear.

The two questions

A coordinate reference system (CRS) answers two separate questions:

1. Where is the Earth? — that's the *datum*. It defines a mathematical model of the Earth (an ellipsoid) and pins it to physical reality at a specific moment in time. WGS 84, NAD83, ETRS89 and OSGB36 are datums.
2. How do I lay it flat? — that's the *projection*. It's a recipe for taking points off the curved ellipsoid and onto a flat plane. Mercator, Transverse Mercator, Lambert Conformal Conic and Albers Equal Area are projections.

A CRS bundles a datum *and* a projection together. EPSG:3857 is "WGS 84 (datum) + spherical Mercator (projection)". EPSG:27700 is "OSGB36 (datum) + Transverse Mercator (projection)".

Why datum matters

Two datums can describe almost the same place but produce coordinates that differ by tens or hundreds of metres. That's because each datum was built by surveying a region — Britain for OSGB36, North America for NAD83, the world for WGS 84 — and each one fits the geoid best for the area it was tuned for.

Take a single GPS reading on the Eiffel Tower:

• WGS 84 (EPSG:4326): 48.8584°N, 2.2945°E
• NTF Paris (EPSG:4807): the same physical point comes out as a slightly different lat/lon — by maybe 30-50 m if you ignore the datum shift

You can't go from one to the other by changing the projection. You need a *datum transformation* — usually a Helmert seven-parameter formula or, for sub-metre work, a grid-shift file like NTv2 or NADCON.

Why projection matters

A projection only changes coordinates *within* a single datum. WGS 84 lat/lon (EPSG:4326) and Web Mercator metres (EPSG:3857) describe exactly the same physical points — but one is in degrees, the other in metres on a flattened plane.

Different projections distort the world differently:

• Conformal (Mercator, Transverse Mercator, Lambert Conformal Conic) — preserves local angles and shapes. Good for navigation, web maps, surveying within a region.
• Equal-area (Albers, Lambert Azimuthal Equal-Area) — preserves area. Required for thematic maps showing density, proportion, or anything per-square-kilometre.
• Equidistant — preserves distance from a chosen point or along a chosen line. Niche but useful (e.g. range rings).

No projection preserves all three of angle, area and distance. That's a mathematical fact about flattening a curved surface.

The classic mistake

A user converts WGS 84 lat/lon to OSGB36 eastings/northings using only a projection formula, ignoring the OSGB36 datum shift. Result: every coordinate is ~5 m off. The map looks right at country scale but every road, building and parcel is wrong.

The fix: always use a tool that knows about *both* the datum and the projection. proj4js, PROJ, GDAL and ArcGIS all do; Python distance formulas typically don't.

How to read a CRS string

A proj4 string like +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +datum=OSGB36 +units=m tells you both:

• Datum: +datum=OSGB36 (or sometimes +ellps=... plus +towgs84=...)
• Projection: +proj=tmerc (Transverse Mercator) and its parameters

In an EPSG code, the registry resolves the same information for you. EPSG:27700 means "OSGB36 + Transverse Mercator with these specific parameters".

In practice

For GIS workflows, if you remember three things you'll avoid 90% of coordinate errors:

1. Always specify the EPSG code of your data, never just "lat/lon" or "metres".
2. Reproject through a tool that handles datum shifts — never compute "WGS 84 to UTM" by hand without a library.
3. Treat WGS 84 and NAD83 (and ETRS89) as different. They were close in the 1980s and have diverged by 1-2 metres since due to plate motion.