How do I check the vertical datum of a DEM?

Read the metadata and the CRS WKT with gdalinfo. A compound CRS names the vertical datum (e.g. EGM2008 height). If only a horizontal CRS is present, the vertical datum is undocumented and you must determine it from the product specification.

What is the difference between ellipsoidal and orthometric height?

Ellipsoidal height is measured from the WGS84 reference ellipsoid (what raw GNSS gives). Orthometric height is measured from the geoid, which approximates mean sea level. They differ by the geoid separation, which ranges from about -100 m to +85 m worldwide.

Why does my DEM disagree with GPS elevation by tens of metres?

Almost always a datum mismatch: your GNSS reports ellipsoidal height and the DEM reports geoid-based (orthometric) height. The difference is the geoid undulation at that location, not an error in either dataset.

How do I convert a DEM between vertical datums?

Use a grid-based transformation. gdalwarp with a compound source and target CRS applies the geoid grid, for example warping from EGM96 to ellipsoidal WGS84. Linear unit changes (feet to metres) can be done with gdal_calc multiplication.

DEM Units and Vertical Datum Checks Explained

Short answer

Before you derive anything from a DEM, confirm two things about the third dimension: the vertical unit (metres or feet) and the vertical datum (what zero means). The unit affects slope directly, because horizontal and vertical units must agree. The datum, ellipsoidal (WGS84) versus orthometric (an EGM96/EGM2008 geoid surface near mean sea level), does not change slope or hillshade but absolutely controls absolute heights and any comparison against GNSS, survey marks, or another DEM. A "30 m error" against field GPS is, nine times out of ten, an uncorrected geoid separation, not a measurement fault.

Why vertical metadata is treated casually and shouldn't be

Slope and hillshade are insensitive to a constant vertical offset, so a datum mistake stays invisible through the whole derivative stage. The map renders, the relief looks right, the slope classes look plausible. The error only surfaces when someone overlays a borehole collar, ties the DEM to a GNSS survey, or differences two DEMs and gets a uniform tens-of-metres bias. By then the product is in a report. The fix is cheap up front and expensive after delivery, which is why units and datum belong in the first ten minutes of handling any elevation data.

Units: metres, feet, and the slope trap

Horn's slope algorithm computes rise over run from the elevation grid and the cell size. If elevation is in US survey feet but the horizontal grid is in metres, every slope is overstated by the ratio 1 ft = 0.3048 m, i.e. about 3.28x. The map still draws; the numbers are just wrong. Detect it by sanity-checking the elevation range against known relief: a coastal site reading 0-3000 in a "metres" DEM that is really feet is a giveaway (3000 ft is ~914 m). To fix a feet-to-metres DEM:

gdal_calc.py -A dem_ft.tif --calc="A*0.3048" --outfile=dem_m.tif --NoDataValue=-9999

Be careful to distinguish international feet (0.3048 exactly) from US survey feet (1200/3937 m). For high-precision work the tiny difference matters; for screening it does not.

Datum: ellipsoidal vs orthometric

There are two reference surfaces for "height":

Ellipsoidal height (h) is measured from the WGS84 reference ellipsoid, a smooth mathematical figure. Raw GNSS/GPS outputs this.
Orthometric height (H) is measured from the geoid, an equipotential surface that approximates global mean sea level. Topographic maps, levelling, and most published DEMs use this.

They relate by the geoid undulation N: h = H + N. N is modelled by global geoids like EGM96 and EGM2008 and varies from roughly -100 m (south of India) to +85 m (New Guinea). So an ellipsoidal DEM and an orthometric DEM of the same ground differ by N at every point, smoothly varying across a large area.

Which datum do common DEMs use? Most global free DEMs are orthometric: SRTM, NASADEM, ASTER, and ALOS AW3D30 use EGM96; Copernicus GLO-30 uses EGM2008. National LiDAR products often use a regional vertical datum (NAVD88 in the US, often in feet). Raw GNSS surveys are ellipsoidal. Mixing any orthometric source with a raw GNSS dataset without correction produces the classic tens-of-metres offset.

How to check the datum

gdalinfo dem.tif

Look at the CRS block. A properly tagged file is a compound CRS that names both horizontal and vertical components, e.g. a COMPOUNDCRS with VERTCRS["EGM2008 height", ...]. If you only see a horizontal CRS (EPSG:4326 or a UTM zone) with no vertical component, the vertical datum is undeclared and you must determine it from the product documentation, not guess. Record what you find: many GeoTIFFs carry no vertical CRS tag at all, and the datum lives only in the dataset's specification sheet.

Worked example: reconciling a DEM with a GNSS survey

You have Copernicus GLO-30 (EGM2008 orthometric) and a set of RTK GNSS points (WGS84 ellipsoidal). They disagree by ~45 m, suspiciously uniform. That is the geoid undulation N for the area. To compare like with like, transform one to the other's datum. With PROJ/GDAL grids installed you can warp the DEM from EGM2008 to ellipsoidal WGS84:

gdalwarp -s_srs "EPSG:4326+3855" -t_srs "EPSG:4979" dem_egm2008.tif dem_ellipsoidal.tif

Here EPSG:3855 is EGM2008 height and EPSG:4979 is 3D WGS84 (ellipsoidal). GDAL applies the geoid grid so the output is directly comparable to the GNSS ellipsoidal heights. Alternatively, transform the GNSS points to orthometric and compare in that frame. Either way, do it explicitly with grids; never apply a single average offset across a large or mountainous AOI, because N is not constant.

Common pitfalls and why they happen

Assuming the DEM is in metres. US and some legacy products use feet; slope inflates by 3.28x silently. Sanity-check the elevation range against known relief.
Comparing a DEM to GNSS without correcting datum. GNSS is ellipsoidal, the DEM is usually orthometric; the offset is the geoid undulation, not an error. Transform first.
Applying a single constant geoid offset over a wide area. N varies spatially; a constant shift is only acceptable over very small extents. Use the geoid grid.
Trusting an absent vertical CRS tag. A missing VERTCRS does not mean ellipsoidal; it means undocumented. Find the datum in the product spec.
Mixing NAVD88 (feet) national data with EGM2008 (metres) global data. Both the datum and the unit differ. Normalise both before any join or difference.

QA validation

Confirm the vertical unit and convert to metres if needed; read the CRS for a vertical component and, if absent, record the datum from documentation; identify whether the data is ellipsoidal or orthometric and which geoid; before any GNSS or cross-DEM comparison, transform to a common vertical frame with a geoid grid, not a flat offset; and document unit, datum, and geoid model in the metadata.

Bathyl perspective

Vertical datum is the quietest source of expensive errors in elevation work, because it never shows up in slope or hillshade and only bites at integration time. We log the unit, the datum, and the geoid model the moment a DEM lands, and we transform with grids rather than fudge a constant offset. That single discipline removes almost every "the DEM is 40 m off the survey" conversation before it starts.

DEM Units and Vertical Datum Checks