3D GNSS data and the GEOID

As high-precision GNSS horizontal and vertical data becomes less expensive to collect, greater attention must be paid when reconciling vertical datasets. In 2013, I wrote two articles entitled “Nightmare on GIS Street: Accuracy, Datums, and Geospatial Data” and “Part 2: Nightmare on GIS Street – Accuracy, Datums, and Geospatial Data” as well as conducted some webinars on horizontal datums.

Reconciling data with disparate horizontal datums is a headache, sometimes a big headache, and sometimes a brutal migraine, especially with large enterprise databases. NAD83? WGS-84? ITRF08? The acronyms seem endless. Then there’s different variations of NAD83, WGS-84, ITRF08. Combine that with the myriad of datum conversion options in GIS software, and you’ve got a perfect opportunity to really mess up your 2D data.

The idea behind a horizontal reference frame (datum) is that anyone whose data is tied to that reference frame should be spatially “compatible.” Some pretty solid horizontal reference frames exist. In the United States, it’s NAD83/2011.

For vertical reference, it’s not so easy.

A common term used when referencing elevations is Mean Sea Level (MSL). If you’re interested in high-precision elevations, MSL is a dangerous term because it’s a regional reference and tends to be referred to as a global reference. The fact is that MSL is different depending on where you are located. MSL in Boston is different than in Miami, different than in Galveston, and different in Seattle so it’s not a suitable reference in a generic sense.

So, what does one use for a vertical reference in order to combine various datasets?

In the United States, the current vertical datum of the National Spatial Reference System is NAVD88. We can get into an entire discussion about how NAVD88 was created, but in an attempt to keep it simple, let’s talk about how to check if your elevation data is referenced to NAVD88. In the United States and other countries, there are survey marks on the ground that serve as points that you can reference.

In the United States, a database of survey marks can be accessed via the NGS Data Explorer website. To use it, simply type in the name of the city and click on Find Marks.

To choose an area within a city, you can use your mouse to pan to where you want, then click Find Marks again to refresh the survey marks. A legend on the right side gives you a definition of each symbol. Focus on the GPS-specific symbols because GPS is the easiest way for you to check the accuracy of your vertical data. For this example, I clicked on a symbol for a “GPS and Approx Height” survey mark. Following is what is displayed:

Above is the standard NGS Data Sheet format for all survey marks in the database. The PID (Permanent Identifier) code is a unique number for the survey mark. In this case, it is AI2002.

The Current Survey Control section on the data sheet provides the key information, including the latitude, longitude and height (elevation) information for the survey mark. Notice the NAVD88 height under the latitude/longitude.

The easiest way to check the accuracy of your vertical data is to use a high-precision GNSS receiver and collect a point on the survey mark. By high-precision, I’m referring to a standard RTK GNSS receiver capable of centimeter accuracy such as pictured below:

You could use a sub-foot or sub-meter GNSS receiver as long as you understand that your elevation accuracy error will be about twice that of your horizontal accuracy. For example, a sub-meter GNSS receiver elevation accuracy will be about 2 meters. For this discussion, let’s assume you’re using an RTK GNSS receiver.

Even though the vertical datum in the United States is NAVD88 and the NGS Data Sheet clearly shows that value, GNSS receivers don’t typically output NAVD88 elevation values. GNSS has its own vertical reference, a reference ellipsoid that approximates the shape of the Earth (GEOID). So, when your GNSS receiver reports elevations, it generally reports them as the Height Above Ellipsoid. This value, as you can see below, is quite different than the NAVD88 elevation….about 23 meters different.

The following graphic depicts the relationship between the ellipsoid, geoid and NAVD88 (surface height).

Remember, GNSS reports in Ellipsoidal Height (HAE). In order to convert this to NAVD88 height, you need to add the GEOID height. It starts to get a little complicated here because the model that defines the GEOID height is updated every few years.

Notice in the above graphic that the GEOID height refers to GEOID03. GEOID03 is the United States GEOID model released in 2003. The current GEOID model was released in 2012 (GEOID12B). The GEOID model changes because better data is being collected to further refine the GEOID model. The changes in the GEOID value from one GEOID model to the next (such as GEOID09 to GEOID12B) can be significant (many decimeters). Note that the ellipsoidal height will not change when the GEOID model is updated, only the GEOID height and the resulting NAVD88 height.

Since the GEOID models change somewhat frequently (every few years), most GIS data-collection software doesn’t incorporate the latest GEOID model, or any GEOID model at all. GPS receivers have a rough GEOID model built in so they can output a “surface elevation” that gets it close (within a few meters) to NAVD88 elevations as opposed to outputting ellipsoidal height, which is many meters in error.

Lastly, all GPS receivers output NMEA data strings, which are consumed by GIS data collection software. GPS receivers typically display this data (or output via Bluetooth or serial port) once per second. One of the key data strings, the GGA message, contains elevation data and looks like this:

$GPGGA,181908.00,3404.7041778,N,07044.3966270,W,4,13,1.00,495.144,M,29.200,M,0.10,0000*40

If you would like to see a complete description of this NMEA data string, I wrote an article describing it here. Otherwise, I’d like to focus your attention on the elevation part of the above data string.

The ninth field of the string (495.144) is the elevation is this case. It is the surface elevation value, but not an accurate representation of NAVD88 elevation. The reason is due to the 11th field of the string (29.200), which is the GEOID value used in this example.

The GEOID value in this example is derived from a rough GEOID model built-into the GNSS receiver. It’s not accurate. Each receiver is different, but this value can be off by a few meters.

Interestingly enough, the GNSS receiver doesn’t output ellipsoidal height (HAE), which is the native elevation reference for GNSS receivers. To compute the ellipsoidal height, you need to subtract the inaccurate GEOID value (29.200) from the surface elevation the GNSS receiver is reporting (495.144), which in this case would be 495.144 – 29.200 = 465.944 meters. Clear as mud?

Now, let’s say you wanted to use an accurate GEOID value from the latest GEOID model and apply it to your data. You would have to perform the following calculation:

495.144 – 29.200 = 465.944 Ellipsoidal height. ###this is to remove the incorrect GEOID value.

Now, you would need to add the accurate GEOID value to the Ellipsoid height (let’s assume the accurate GEOID value is 31.45 meters).

465.944 + 31.45 = 497.394 meters (NAVD88).

Now, when 497.394 refers to NAVD88, this is assuming your GNSS receiver is accurate to a few centimeters in elevation. Of course, applying an accurate GEOID value to an elevation being output by a Garmin handheld doesn’t make much sense because the inaccuracy of the Garmin elevation is much greater than the rough GEOID model used by the Garmin.

Well, this concludes my stepping-off point for a discussion about elevations in what is sure to become a series of articles about the accuracy of GIS elevation data and how to check the elevation accuracy of your GIS data, as well as how to collect it.

Follow me on Twitter at https://twitter.com/GPSGIS_Eric

Sources: NGS Data Explorer