Ellipsoid, Geoid, and Datum: Why “Same Coordinates” Still Miss by Meters

Why this exists

A lot of spatial bugs look mysterious but are actually datum bugs:

• Two teams both say “WGS84,” but points are offset.
• Horizontal positions match, elevations do not.
• A map overlay looks fine in one city and drifts in another.

This note is a practical guide to the three-layer model behind those failures: ellipsoid, geoid, and datum/reference frame.

The three-layer mental model

1) Ellipsoid (geometry)

An ellipsoid is a smooth mathematical Earth shape used for coordinate math.

For WGS 84, key parameters include:

• semi-major axis (a = 6,378,137.0) m
• inverse flattening (1/f = 298.257223563)

These constants define the geometric surface used to compute latitude/longitude/ellipsoidal height.

2) Geoid (physics)

The geoid is an equipotential gravity surface that best approximates global mean sea level.

It is not a simple shape. It undulates relative to an ellipsoid due to gravity field variation.

Operationally, this is why GNSS “height” and “height above sea level” are different quantities.

3) Datum / reference frame (realization)

A datum/reference frame says how coordinates are anchored and oriented in the real world (origin, axes, epoch, realization).

Two systems can share nearly identical ellipsoid parameters yet still differ because frame realization and epoch handling differ.

Height relationship you should memorize

A standard geodetic relationship is:

[ h = H + N ]

Where:

• (h): ellipsoidal height (from GNSS/ellipsoid)
• (H): orthometric height (physical “height above geoid/sea-level-like surface”)
• (N): geoid undulation (ellipsoid-to-geoid separation)

Rearranged for practical conversion:

[ H = h - N ]

If you mix (h) and (H) without tracking (N), “mysterious” vertical errors are expected.

Common failure modes in real systems

1) “EPSG:4326 everywhere” assumption

People treat all WGS84-labeled data as identical forever. In practice, realizations and epochs matter (especially in high-accuracy workflows).

2) Horizontal datum metadata present, vertical datum missing

Very common in GIS pipelines. Teams align XY but silently mismatch Z references.

3) Regional datum + global frame conflation

NAD83-family products and WGS84 products may be close for some use cases but are not universally interchangeable at higher precision.

4) Ignoring time dependence

Modern reference frames and products are increasingly epoch-aware. Static assumptions age badly.

5) Applying generic 7-parameter shifts where grid/geoid models are required

Helmert transforms are powerful, but they are not a universal substitute for region-specific models and full transformation pipelines.

A fast diagnostic workflow (ops-friendly)

When coordinates disagree, check in this order:

1. CRS identifier (exact EPSG/proj string, not just “WGS84”).
2. Frame realization + epoch (if available).
3. Vertical datum (NAVD88 / local tidal / geoid model / ellipsoidal).
4. Transformation path used by software (Helmert? grid shift? geoid model?).
5. Expected accuracy budget (meter-level app vs cm-level survey/engineering).

If any of 2–4 are unknown, your transformation is not fully defined.

Practical transformation notes

• PROJ’s Helmert operation supports 3/7 and kinematic 14-parameter style transforms, with explicit convention and epoch handling.
• NOAA tooling and datum modernization workflows emphasize that historic and modern frame conversions are not one-size-fits-all.
• For vertical work, geoid models (e.g., EGM-family globally, national models regionally) are first-class components, not optional cleanup steps.

Quick rules of thumb

• Never store just “WGS84” as free text when precision matters.
• Persist: CRS + realization + epoch + vertical datum + transformation version.
• Treat vertical metadata as required, not optional.
• Validate transformations with control points before bulk conversion.
• Document unit conventions (meters/US survey feet, etc.) with the dataset.

Bottom line

Most coordinate mismatch incidents are not random math errors.

They are usually reference-definition errors: wrong frame, missing epoch, or missing vertical model.

If you keep ellipsoid/geoid/datum explicitly separated in your data contracts and pipelines, you eliminate a large class of geospatial production bugs before they happen.

References

• NOAA VDatum datum tutorial — https://vdatum.noaa.gov/docs/datums.html
• NOAA NGS, The Geopotential Surface — https://geodesy.noaa.gov/research/geopotential-datums/geopotential-surface.shtml
• NGA Geomatics, WGS 84 reference system and parameters — https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84
• NOAA NGS New Datums FAQ (modernized NSRS rollout, NAPGD2022 context) — https://geodesy.noaa.gov/datums/newdatums/FAQNewDatums.shtml
• PROJ documentation, Helmert transformation — https://proj.org/en/stable/operations/transformations/helmert.html