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