Skip to main content

The Vertical Datum: The Missing Label

Central Idea

An elevation is not complete until its vertical reference is identified. Before deciding that a GNSS elevation disagrees with a benchmark, determine what each number represents, which vertical datum it uses, and where any geoid conversion occurred. Only then can the values be compared apples to apples.

A Precise Number Can Still Be Incomplete​

Suppose a benchmark datasheet lists an elevation of 123.456 feet. The number looks authoritative. It has three decimal places, it appears on an official record, and it may have been used for decades. Yet the value is incomplete unless the datasheet also identifies the vertical datum. The missing label tells us what the elevation is referenced to and, in practical terms, what zero elevation means.

For this companion, we will assume the published benchmark elevation is 123.456 feet NAVD88. NAVD88 is not simply an optional note placed after the number. It is part of the coordinate. Remove the datum label and the reader no longer knows which vertical reference produced the elevation or whether another measured value can be compared with it.

Engineer Insight

An elevation should be treated as a number plus a reference system. Writing only 123.456 feet is like reporting a temperature of 25 without identifying the scale. Precision does not replace definition.

What the Datum Means​

A vertical datum is the agreed reference system used to assign elevations. It allows surveyors, engineers, agencies, and software to describe different points using the same definition of height. In the United States, many published benchmark elevations are identified as NAVD88 orthometric heights. That label tells us that the elevation belongs to a particular gravity-based vertical reference rather than to the GNSS ellipsoid.

The datum does not move the benchmark or change the ground. It changes the framework used to describe the point. The same monument can therefore have an ellipsoid height, a NAVD88 orthometric elevation, and other valid vertical coordinates. Those values are not competing measurements until they are placed in the same reference system.

The Benchmark and the GNSS Measurement​

Now occupy the benchmark with a GNSS rover. The receiver first solves a three-dimensional position and obtains an ellipsoid height, h. Assume that height is 141.832 feet. The published benchmark elevation is 123.456 feet NAVD88. Comparing those two numbers directly would be an apples-to-oranges comparison because one is measured from the ellipsoid and the other belongs to a gravity-based vertical datum.

To make the GNSS result comparable, the workflow must convert the ellipsoid height into an orthometric height using a geoid model that is compatible with the intended vertical datum. After that conversion, the receiver or software might report 123.471 feet. Only now are the two values answering the same kind of question: both are orthometric elevations intended to represent the point in NAVD88.

Where the Base Station Fits​

The base station does not create NAVD88 by itself. RTK transfers the relationship between the base and rover through a common geodetic reference frame. The rover's absolute result therefore depends on the coordinates assigned to the base. If the base height is biased, every rover height derived from that base will carry essentially the same bias.

This leads to an important distinction. The base is normally assigned an ellipsoid height as part of its GNSS coordinate, while the benchmark is published with an orthometric elevation such as NAVD88. The base does not need a menu setting labeled NAVD88 in order for fieldwork to succeed. It does need accurate coordinates in the correct horizontal reference frame and epoch, including a reliable ellipsoid height. The selected geoid model can then convert rover ellipsoid heights into NAVD88-compatible orthometric elevations.

If a local base is positioned by a rough autonomous average, its ellipsoid height may be wrong by several feet even though the rover later obtains an excellent fixed solution. RTK will reproduce the base-to-rover geometry very precisely, but it will reproduce it from the wrong starting coordinate. A fixed solution is precise relative to the base; it does not prove that the base has been tied correctly to the project datum.

Common Misconception

A rover can show RTK FIX and still disagree with a NAVD88 benchmark. FIX describes the quality of the relative carrier-phase solution. It does not certify that the base coordinate, geoid model, or vertical datum is correct.

Two Valid Ways to Tie the Field Survey​

One approach is to use a correction network whose reference frame and published workflow are known, then apply the designated geoid model to obtain NAVD88 orthometric elevations. Another is to establish a local base from surveyed coordinates that are already tied to the required reference system. In either case, the important requirement is not a particular brand or menu selection. It is a documented path from the base coordinate to the rover height and from the rover height to the project datum.

A benchmark can also be used as a field check or as part of a local vertical adjustment, but assigning the benchmark's orthometric elevation directly to a GNSS ellipsoid-height field is not a valid shortcut. The published NAVD88 elevation and the base ellipsoid height are different quantities. The geoid relationship between them must remain explicit.

The Comparison Test​

Before calling either value wrong, identify the comparison elevation. Is it a published NAVD88 orthometric elevation? Was it transferred by conventional leveling? Does it refer to the top of the monument, a ground point, or another mark? Then identify the GNSS value. Is it h or H? Which base coordinate produced it? Which geoid model was applied, by which device, and how many times?

Only after those questions are answered should the numerical difference be evaluated. If both values are orthometric elevations in the same vertical datum, use compatible geoid treatment, refer to the same physical point, and use the same units, the comparison is meaningful. Until then, the difference may reveal nothing more than mismatched labels.

Stop and Think

A benchmark says 123.456 feet NAVD88. Your rover says 141.832 feet. Before touching the equipment, ask one question: is the rover displaying ellipsoid height? If so, the eighteen-foot difference may be the expected separation between reference surfaces rather than a positioning failure.

Key Takeaway

For a valid benchmark check, the comparison value and the GNSS result must be brought into the same height type and vertical datum. The base must be accurately tied to the geodetic reference used by the workflow, and the geoid conversion must be documented and applied exactly once. Compare definitions before comparing numbers.

Looking Ahead

The benchmark and GNSS values may now be labeled correctly, yet the field elevation can still be wrong. A rover does not occupy the ground point with its antenna phase center. A pole, adapter, and antenna stand between the point and the position solved by GNSS. In the next section, we will follow that physical measurement from the pole tip to the antenna and see how rod height, the antenna reference point, and the antenna phase-center correction can shift an otherwise correct RTK elevation.