> For the complete documentation index, see [llms.txt](https://docs.rtkdata.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rtkdata.com/get-started/understanding-heights.md).

# 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–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.05–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–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.**

***

## 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:

| # | Level                                         | What it controls                                                       | Applies to recorded heights? |
| - | --------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------- |
| 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.

| Column             | What it is                                           | What to do with it                      |
| ------------------ | ---------------------------------------------------- | --------------------------------------- |
| 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:

| Region                         | Ellipsoid above geoid | Model to apply              |
| ------------------------------ | --------------------- | --------------------------- |
| 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:

1. **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.
2. **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.
3. **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

| Symptom                                                                                                                           | Cause                                                                                                                                  | Fix                                                                                                       |
| --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| "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](/get-started/coordinate-systems-and-datums.md): the horizontal half of the same problem, including grid file vs. seven parameter transformations
* [Accuracy Expectations](/get-started/accuracy-expectations.md): normal RTK vertical performance, so you can separate a geoid offset from an accuracy issue
* [Emlid Flow](/integration-hub/ntrip-clients-and-field-software/emlid-flow.md): setting the vertical datum in the project rather than the NTRIP profile
* [DJI Pilot / Pilot 2](/integration-hub/ntrip-clients-and-field-software/dji-pilot-pilot-2.md): the RTK height column and what gets tagged to your images
* [Troubleshooting & FAQ](/support/troubleshooting-and-faq.md): connection level problems that are not height problems


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rtkdata.com/get-started/understanding-heights.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.