RTK Ellipsoidal vs Orthometric Heights Explained
RTKdata delivers ellipsoidal heights: learn why your elevation may be off by 10-50 m and how to apply a geoid model in Emlid, DJI, Trimble, and QGIS
RTKdata delivers ellipsoidal heights (height above the mathematical WGS84 ellipsoid). If your elevation readings are off by 10 to 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 to 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:
United States (CONUS)
15 to 35 m
Ellipsoid is ABOVE geoid
Europe
35 to 55 m
Ellipsoid is ABOVE geoid
Australia
15 to 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
10 to 55 m (or 30 to 180 ft)
Geoid separation not applied
Apply a geoid model (see below)
0.5 to 2 m
Datum mismatch (e.g., WGS84 vs local vertical datum)
Check datum settings
0.05 to 0.5 m
Different geoid model version or epoch
Use the correct regional geoid model
< 0.05 m
Normal RTK vertical accuracy
This is expected performance
If your elevation is off by roughly 30 to 180 feet (10 to 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:
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
Open your project settings
Go to Coordinate system
Select your local vertical datum (which includes a geoid model)
Heights will automatically be converted to orthometric
In DJI Terra
DJI Terra outputs ellipsoidal heights by default
In Output Coordinate System, select a system that includes a vertical datum
Or apply the geoid correction in post-processing (QGIS, Global Mapper, etc.)
In Trimble Access
Go to Jobs > Properties > Coord sys
Select your local coordinate system (which includes a geoid file)
If needed, download the geoid file from Trimble's data manager
Heights will display as orthometric once the geoid is active
In Pix4D
Go to Processing Options > Output Coordinate System
Select a coordinate system with a vertical component (e.g., "NAD83 + NAVD88 height")
Or set a specific geoid model under vertical datum settings
In QGIS (Post-Processing)
Load your data
Go to Layer > Export > Save Features As
Set the CRS to include a vertical datum (e.g., EPSG:6360 for NAD83(2011) + NAVD88)
QGIS will apply the geoid transformation during export
In SingularPad
Go to Project Settings > Coordinate System
Select your local vertical datum
Ensure the geoid file for your region is loaded
Common Geoid Models by Region
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 to 40 cm elevation offset in CAD stakeout: no geoid model applied in SingularPad.
Key Takeaway
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.
Where the Geoid Model Has to Be Set
A geoid file that sits on the device but is not assigned changes nothing. Field software typically offers three places that all look like the right one:
1
NTRIP / correction input profile
How incoming corrections are treated. Stays on the global option.
No
2
Workspace or app default
Preselects a vertical datum for projects created after the change.
No, and not retroactively
3
Project settings, vertical datum or geoid row
The conversion actually applied to recorded and exported heights.
Yes
One customer set OSGB 1936 / British National Grid with ODN height in Workspace settings and confirmed the grid and geoid files had downloaded, but an existing project still produced the wrong heights. Setting the same system inside that project resolved it.
Downloading a geoid file is not the same as applying it. Confirm the file is selected in the active project, not just present on the device.
The Row That Is Usually Left on "None"
In one thread the horizontal projection was configured correctly and the elevation was still roughly 68 m too high. The cause was a single row in the coordinate system screen, labelled Vertical Adjustment Parameter, still set to None.
The report was: "I am getting a fixed position but I don't think coordinates are correct. Elevation should be around 35." The receiver was reading about 103.8 m with 7 mm horizontal precision, so the RTK solution itself was fine. In Ireland the ellipsoid sits roughly 55 to 65 m above the geoid, which accounts for the gap almost exactly. Loading the national geoid model into that row resolved it.
Depending on the app the row is called Vertical Adjustment Parameter, Geoid File, Vertical datum or Geoid model. Whatever the label, None in that row means you are reading raw ellipsoidal height.
Two Height Values in the Same Screen
Some apps display more than one height at once, measured against different references. In DJI Pilot 2 a customer saw an aircraft column reading 99.27 ft and a Custom Network RTK column reading 159.18 ft on the same screen and asked whether that difference was a fault.
Aircraft
The drone's own onboard barometric and GNSS estimate
Situational awareness only
Custom Network RTK
Ellipsoidal height from the RTK solution
This is the value tagged to your images
Neither value is wrong and the two will almost never match. Do not try to reconcile them. If your deliverable needs orthometric heights, apply the geoid model in processing (GEOID18 in the USA) to the RTK ellipsoidal height, not to the aircraft figure.
Further Separations Documented in Support Cases
Additional regions where the offset was traced back to geoid separation, stated as how far the ellipsoid sits above the geoid:
Ireland
Roughly 55 to 65 m
IGeoid15 (Malin Head datum)
Barbados and eastern Caribbean
Roughly 26 to 30 m
EGM2008
New Mexico, USA
Roughly 25 to 30 m
GEOID18 (NAVD88)
Heights and Site Calibration
If you calibrate on a known control point and the vertical residual will not close, check these three before adjusting anything else:
Antenna or pole height. Enter the true value in the field software before running the calibration. A height treated as zero feeds straight into the residual.
The vertical datum of the published control point. Values issued by a national mapping or lands department are usually orthometric, referenced to a local tide gauge datum. Comparing one of those against a raw ellipsoidal reading produces a residual the size of the geoid separation.
The geoid model. Confirm it is loaded and assigned in the project. Without it the vertical loop will never close regardless of the transformation parameters you enter.
These three were the recurring blockers in a long calibration thread where the calibration screen showed a vertical offset of roughly 146 m.
Common configuration mistakes
"I am getting a fixed position but I don't think coordinates are correct. Elevation should be around 35" (receiver reads ~104 m)
No geoid model applied. Reading is raw ellipsoidal height.
Load the national geoid model into the vertical datum row of the project's coordinate system.
Geoid file downloaded onto the device, heights unchanged
The file is present but not selected as the active vertical adjustment.
Open the coordinate system screen and assign the file. None in that row means no conversion happens.
Vertical datum set correctly, an existing project still exports wrong heights
Set at workspace or app default level after the project had been created.
Set the same vertical datum inside the active project.
Two different heights shown on the same screen
Onboard barometric estimate vs. RTK ellipsoidal height.
Use the RTK value. The two references are not comparable and the gap is not an error.
Vertical residual will not close during site calibration
Antenna height not entered, or the published control point elevation is orthometric while the receiver outputs ellipsoidal.
Enter the antenna height, apply the geoid model, and confirm which vertical datum the control point uses.
Computed elevation comes out negative after a calibration
Geoid model not being applied to the project, or a vertical datum in the projection conflicting with a separately applied geoid model.
Verify the project is on the intended national grid and that only one vertical conversion is active.
Contours are internally consistent but absolute elevations are wrong
Ellipsoidal heights carried through processing with no geoid model.
Select an output coordinate system with a vertical component in the processing software.
Heights differ between a rover point and a drone deliverable on the same site
One workflow applied a geoid model, the other did not.
Apply the same geoid model to GCPs, rover points and the processing project.
Related Guides
Coordinate Systems & Datums: the horizontal half of the same problem, including grid file vs. seven parameter transformations
Accuracy Expectations: normal RTK vertical performance, so you can separate a geoid offset from an accuracy issue
Emlid Flow: setting the vertical datum in the project rather than the NTRIP profile
DJI Pilot / Pilot 2: the RTK height column and what gets tagged to your images
Troubleshooting & FAQ: connection level problems that are not height problems
Last updated
Was this helpful?