Set the vertical datum
State what your heights are measured from, download GEOID18 so the app computes NAVD88 elevations itself, and recompute heights collected before.
On this page
A GNSS receiver measures height above the ellipsoid. An elevation on a plan is height above the geoid, and the receiver converts one to the other using whichever geoid model it's set to. Different models give elevations that can differ by half a metre to a metre and a half across the continental US. Nothing in the data stream says which model was used.
The Vertical datum setting is where you state which one your project is on. For most options it declares; it doesn't convert: it records what your receiver is set to, that statement travels into every export, and the QA report can tell you when the data doesn't look consistent.
GEOID18 can do more. Download its grid in the same sheet and the app computes new RTK elevations through it itself, checks every height against it in the QA report, and can bring heights you've already collected onto it.
Before you start
- An open project. The Vertical datum row is greyed out without one.
- Check your receiver's own geoid setting, in the receiver's app or configuration tool. That's the value you're declaring here.
Set the vertical datum
- Go to Tools → Vertical datum. The row shows the current setting. New projects start at Not stated.
- Under Heights in this project are, tap the option that matches your receiver.
- Tap Save. Tap Cancel to leave it unchanged.
| Option | What it means |
|---|---|
| GEOID18 | NAVD88, ±0.02 m in the continental US. The current US model. |
| GEOID12B | NAVD88, ±0.02 m in the continental US, superseded by GEOID18. |
| EGM2008 | EGM2008 global mean sea level, ±0.15 m in well-surveyed regions. |
| EGM96 | EGM96 global mean sea level, ±0.5–1 m in the continental US. Often a receiver's factory default. |
| Local benchmark | Heights reduced to a benchmark on site. Internally consistent, but not tied to a published datum. |
| Ellipsoidal (WGS84) | Heights above the WGS 84 ellipsoid. These aren't elevations: they're tens of metres from any sea level. |
| Not stated | Heights are stored as the receiver reported them, with no record of which geoid it used. This is the default. |
Download a GEOID18 grid
The sheet's Geoid grids section offers NGS's own GEOID18 files, downloaded when you need them:
- The top row is the grid suggested for your site: the smallest one that covers your current position, or the centre of the points you've collected. For example GEOID18 — South and Ohio Valley, with its extent and size.
- All GEOID18 grids lists the rest: eight regional CONUS tiles of about 4.9 MB each, GEOID18 — all of CONUS (about 34 MB), and GEOID18 — Puerto Rico and US Virgin Islands.
Tap Download. A bar and percentage show progress, and a green check mark shows when the grid is installed. Each file is checked against its published size and checksum before it's installed. If the check fails, nothing is installed and the row says why, for example "The file doesn't match the published GEOID18 grid."
Grids stay on the phone for offline work. To remove one, tap its check mark and choose Delete grid.
GEOID18 covers CONUS, Puerto Rico and the US Virgin Islands. Outside them the section says so, and there's no grid to download. Alaska, Hawaii and Guam aren't covered by GEOID18.
How new elevations are computed
With the project set to GEOID18 and a grid installed that covers the fix, each new RTK fix gets its elevation from the grid: H = h − N, the ellipsoidal height minus the geoid separation. The elevation is on NAVD88 whatever geoid the receiver is set to. The receiver's own separation is kept on the record.
This only happens for fixes known to be in NAD83(2011), because GEOID18 is fitted to NAD83(2011) heights:
- corrections stated as NAD83(2011), or
- corrections stated as ITRF / WGS 84 and shifted into NAD83(2011) on a NAD83 zone.
A fix whose correction frame is Not stated, phone GPS, and a fix without an ellipsoidal height all keep the receiver's elevation. See The frame your corrections are in.
For any other option, or without a grid, every elevation is the height the receiver reports after applying its own geoid model. With phone GPS alone, it's the height iOS reports. So the vertical datum is only as right as the receiver's setting. If you work in NAVD88 without the grid, confirm the receiver is loaded with GEOID18 before you trust an elevation.
Recompute heights already collected
Heights collected before the grid was in use can be brought through it. With GEOID18 selected, the sheet has a Heights already collected section:
- It says how many heights were collected before GEOID18 was in use, and how far recomputing would move them, for example Recomputing moves them by up to 0.142 m.
- Tap Recompute n heights.
- Confirm with Recompute.
Each elevation is replaced by one computed from its ellipsoidal height through the grid. Positions don't move. The project is set to GEOID18 from then on, even if you then tap Cancel. The section confirms, for example Recomputed 12 heights through GEOID18.
The same rule as for new fixes decides which heights qualify. The footer counts the ones that don't, and why:
- points without a stated NAD83 frame (phone GPS, or corrections whose frame wasn't set) keep the receiver's elevation;
- points with no ellipsoidal height have nothing to recompute from;
- points outside every installed grid need the tile for that area.
A fix whose frame was never stated can't be recomputed later: there's no way to learn its frame after the fact.
What the QA report checks
The QA report can catch the failure that happens most in the field, even without a grid: the geoid model changing partway through a job, for example when a second receiver joins or a setting is reset.
- Mixed geoids. The geoid is smooth. Across a site it changes by centimetres, not metres. If the geoid separations recorded with your points disagree by more than about 0.25 m plus 0.2 m per kilometre of distance, the report flags "N heights use a different geoid from the rest". Elevations from the two groups aren't on the same datum.
- No stated datum. While the setting is Not stated, the report lists "N heights have no stated vertical datum" and points you to this setting.
With GEOID18 declared and a grid installed, the report also checks every height against the grid:
- Doesn't match the grid. If a point's recorded separation differs from GEOID18 by more than 0.10 m, the report flags "N heights do not match GEOID18". The receiver was most likely reducing to a different geoid, often an EGM96 factory default. This check works from the first point. It uses every installed tile the job's points fall in, so a job across two tiles is checked end to end. A point no installed tile covers isn't judged.
- Recomputed heights. "N heights were recomputed through the geoid grid" lists the heights brought through it after they were collected.
The report's vertical datum line repeats what you declared, and its geoid note says which heights the app reduced through the grid and which are as the receiver reported them.
Where it appears in exports
The same statement is written into every format that has a place for it:
| Export | Where the vertical datum goes |
|---|---|
| CSV | A vertical_reference column on every row, next to horizontal_datum. |
| GeoJSON | A vertical_datum entry in the file's metadata, plus geoid_model when a geoid is declared. A feature whose elevation the app computed through the grid carries geoid_reduced_by and receiver_geoid_separation_m. |
| LandXML | The verticalDatum attribute of the coordinate-system element, with the geoid model named. |
| DXF | A header note, for example Heights: NAVD88 (GEOID18) — orthometric where measured. Entities without a measured height sit at 0. |
| QA report | The vertical datum line. |
The wording depends on the option. For GEOID18 it reads NAVD88 (GEOID18) — orthometric where measured. For Not stated it reads orthometric (MSL) where measured — geoid not stated rather than claiming a datum.