Understanding Heights

RTKdata delivers ellipsoidal heights (height above the mathematical WGS84 ellipsoid). If your elevation readings are off by 10–50+ meters compared to known benchmarks, this page explains why — and how to fix it.

---

The Short Version

RTKdata gives you height above the ellipsoid. Your benchmark, topographic map, or "sea level" reference uses height above the geoid. The difference between these two surfaces can be 10–50+ meters depending on your location.

This is NOT an error. It's two different measurement systems. You need to apply a geoid model to convert.

---

What Are Ellipsoidal and Orthometric Heights?

Ellipsoidal Height (what RTKdata delivers)

Height measured from the WGS84 ellipsoid — a smooth mathematical surface that approximates Earth's shape. This is what GPS/GNSS receivers calculate directly.

Orthometric Height (what most people expect)

Height measured from the geoid — an irregular surface that follows mean sea level. This is what topographic maps, benchmarks, construction plans, and most real-world applications use.

The Geoid Separation

The difference between the ellipsoid and the geoid is called geoid separation (or geoid undulation). It varies by location:

Region	Typical Geoid Separation	Direction
United States (CONUS)	15–35 m	Ellipsoid is ABOVE geoid
Europe	35–55 m	Ellipsoid is ABOVE geoid
Australia	15–30 m	Ellipsoid is ABOVE geoid
South America	-10 to +30 m	Varies
Southeast Asia	-20 to +10 m	Often ellipsoid is BELOW geoid

Example: In Denver, Colorado, the geoid separation is approximately -18 meters. If your RTK receiver shows an ellipsoidal height of 1,625 m, the orthometric (MSL) height is approximately 1,625 - (-18) = 1,643 m. If you compare the raw ellipsoidal height to a benchmark that uses MSL, you'll see a ~18 m offset.

---

"My Elevation Is Off by X Meters" — Quick Diagnostic

Offset Size	Likely Cause	Solution
10–55 m (or 30–180 ft)	Geoid separation not applied	Apply a geoid model (see below)
0.5–2 m	Datum mismatch (e.g., WGS84 vs local vertical datum)	Check datum settings
0.1–0.5 m	Different geoid model version or epoch	Use the correct regional geoid model
< 0.1 m	Normal RTK vertical accuracy	This is expected performance

If your elevation is off by roughly 30–180 feet (10–55 meters), it's almost certainly a geoid issue — NOT a problem with RTKdata.

---

Regional Geoid Separation Examples

These are approximate values to help you recognize a geoid issue:

Location	Approximate Geoid Separation
New York City, USA	-32 m
Denver, Colorado, USA	-18 m
Los Angeles, USA	-33 m
London, UK	+47 m
Berlin, Germany	+40 m
Sydney, Australia	+22 m
Perth, Australia	-28 m
Sao Paulo, Brazil	-7 m
Dubai, UAE	-27 m

---

How to Apply a Geoid Model

In Emlid Flow

1. Open your project settings

2. Go to Coordinate system

3. Select your local vertical datum (which includes a geoid model)

4. Heights will automatically be converted to orthometric

In DJI Terra

1. DJI Terra outputs ellipsoidal heights by default

2. In Output Coordinate System, select a system that includes a vertical datum

3. Or apply the geoid correction in post-processing (QGIS, Global Mapper, etc.)

In Trimble Access

1. Go to Jobs > Properties > Coord sys

2. Select your local coordinate system (which includes a geoid file)

3. If needed, download the geoid file from Trimble's data manager

4. Heights will display as orthometric once the geoid is active

In Pix4D

1. Go to Processing Options > Output Coordinate System

2. Select a coordinate system with a vertical component (e.g., "NAD83 + NAVD88 height")

3. Or set a specific geoid model under vertical datum settings

In QGIS (Post-Processing)

1. Load your data

2. Go to Layer > Export > Save Features As

3. Set the CRS to include a vertical datum (e.g., EPSG:6360 for NAD83(2011) + NAVD88)

4. QGIS will apply the geoid transformation during export

In SingularPad

1. Go to Project Settings > Coordinate System

2. Select your local vertical datum

3. Ensure the geoid file for your region is loaded

---

Common Geoid Models by Region

Region	Geoid Model	Covers
United States	GEOID18 (or GEOID12B)	NAVD88 vertical datum
Europe	EGM2008	Global, widely supported
United Kingdom	OSGM15	Ordnance Survey datum (ODN)
Australia	AUSGeoid2020	AHD (Australian Height Datum)
Canada	CGG2013a (or HTv2.0)	CGVD2013 vertical datum
New Zealand	NZGeoid2016	NZVD2016 vertical datum
Global (fallback)	EGM96 or EGM2008	Works everywhere, less precise than regional models

---

Real-World Examples from Support

These cases were all resolved by applying the correct geoid model:

• Emlid RS3 user (Ojai, California): RTKdata showed 122 ft, expected 240 ft. Difference of 118 ft = geoid separation in Southern California. Applying GEOID18 resolved the offset.

• SingularXYZ user (Denver, CO): ~65 ft (20 m) offset — exactly the geoid separation for Denver.

• SingularPad user (Vancouver, Canada): 20–40 cm elevation offset in CAD stakeout — no geoid model applied in SingularPad.

---

Key Takeaway

What you want	What to do
Elevation matching sea level / benchmarks	Apply a geoid model in your software
Raw ellipsoidal height for processing	Use RTKdata output directly (no conversion needed)
Compare to survey control points	Ensure both use the same vertical datum and geoid model

RTKdata delivers correct ellipsoidal heights. If your elevation seems wrong, apply a geoid model before concluding there's an accuracy issue.