Skip to content

Part 2: Nightmare on GIS Street – Accuracy, Datums, and Geospatial Data

No audio available for this content.

This is Part 2 of the discussion I started in March with this article.  It frames this discussion.

I ended Part 1 of this discussion with a statement from Michael Dennis of the U.S. National Geodetic Survey. He said while people understand that the 14-parameter transformation algorithm is important in transformations between horizontal datums, the step people are leaving out is reconciling epoch dates of the data.

What is an epoch date?

The epoch date is simply the date in which geospatial data is referenced. It can be the date the data was collected or a standardized date. For example, the current NAD83 (North American Datum of 1983) datum has a standardized epoch date of 2010.0 (January 1, 2010).

Why do we care about the epoch date of geospatial data?

It can be overwhelming  to think about trying to populate and manage a centimeter-level GIS, and even more unfathomable when one considers the fact is that the land we occupy is moving. Some refer to it as continental drift. Scientists refer to it as tectonic plate movement. Geodesists refer to it as velocity. No matter which term you use to describe the phenomenon, it’s something that we, as geospatial practioners, need to reconcile. For example, the islands of Hawaii “move” horizontally about 6 cm/year. If you collected GPS data in 2005 using WAAS as a source of GPS corrections, WAAS base stations were referenced to ITRF00 epoch 1997.0. In 2013, WAAS is now referenced to ITRF08 with an epoch of 2013.5. If you collected data today and compared the two coordinates, you would introduce 99 cm of horizontal error (16.5 years x 6 cm/yr) if you did not take into account the movement and epoch date. Other geographic regions don’t move as much, but even the most stable plates still move. Following is a map of the tectonic plates of the world.

The Earth & Environmental Sciences Department at the University of Kentucky has got a really neat interactive tectonic plate map.

TectonicUKY1
Worldwide Map of Tectonic Plates.
Source: University of Kentucky

Each tectonic plate moves, and with the large number of stationary GPS/GNSS receivers (CORS) located around the world, scientists can closely monitor (and model) the movement. Following is a general map of worldwide velocities. Higher resolution velocity maps for many geographic regions are available from local agencies:

TectonicUKY
Rough, Worldwide Velocity Model.
Source: University of Kentucky

Finally, if you’re looking for further reading on tectonic plate theory, take a look at these websites:

Tulane University Physical Geology (Dr. Stephen A. Nelson)

Georgia Perimeter College (Dr. Pamela Gore)

The Epoch Date, Applied

In order to properly capture a location of a point on the Earth and be able to accurately (within centimeters) return to that location in the future, it’s critical that the “epoch date” of the location be recorded along with the x, y and z. In the future, when you’re preparing to relocate or return to the location, you’ll need to bring the coordinates to the same epoch date prior to comparing them. Perhaps it’s best to use an example to explain.

A few weeks ago, I was in Colorado and wanted to test the accuracy of a free CORS Streaming service (RTK) using a dual-frequency GNSS receiver. I was just outside of the city of Boulder. I located a nearby survey mark that had recently been surveyed using a high-precision GNSS receiver and adjusted to the National Spatial Reference System (NSRS). Following is a photograph of the survey mark I found:

20130418_152513
National Geodetic Survey Mark KK2060.

I downloaded the survey mark datasheet from here on the National Geodetic Survey website. What pieces of information do I need in order to accurately compared the NSRS coordinates of the survey mark with the coordinates being determined by the GNSS receiver? Certainly, I needed the coordinate and the datum the coordinate is referenced to. In this case, the following datasheet tells me the datum is NAD83/2011 (North American Datum of 1983 Ver. 2011). The other critical piece of information is the epoch date, which is clearly noted on the datasheet as highlighted below, epoch 2010.0 (January 1, 2010).

KK2060
National Geodetic Survey (NGS) Datasheet for KK2060.

Since I have all the information about the survey mark that I need, I turn my attention to the GNSS receiver. Actually, the GNSS receiver doesn’t determine which datum/epoch date the GNSS receiver provides. In reality, it depends on the datum the GNSS base station data is referenced to. For example, if you’re using a state-government-operated RTK Network, the datum is likely NAD83/2011. If you’re using OmniSTAR real-time corrections, the datum is ITRF08/epoch 2010.0. If you’re using Starfire real-time corrections, the datum is ITRF05, and the epoch date is updated nightly. WAAS (SBAS) uses ITRF08 and updates the epoch approximately annually, so the current epoch is 2013.5. These are just a few examples. There are many possible datum that the GNSS base station can be referenced to.

In my case, I was using a streaming RTK data (over the Internet) from a public RTK base station 18 km away. I was able to connect to the RTK base station over the Internet and obtain a real-time, centimeter-level coordinate in ArcPad:

20130418_151508
ArcPad GPS Data Quality Tab. In the ArcPad screenshot, the EPE, HPE, VPE values show 0.0, but that’s only because there aren’t enough digits of precision to show the 1-cm estimated accuracy.

In speaking to the administrator of the public RTK base station, I learned the RTK base station was referenced to ITRF00, epoch 1997.0. That means the coordinate my GNSS receiver was displaying in ArcPad was referenced to ITRF00, epoch 1997.0. If I’m going to accurately compare the coordinate of the NGS survey mark and the GNSS data I’m collecting, I going to need to adjust the ITRF00, epoch 1997.0 coordinate data to NAD83/2011. If I only adjusted the ITRF00 datum to NAD83/2011 and ignored the epoch date of the data, I would be ignoring 14 years of tectonic plate movement. If the tectonic plate movement is 2 cm/year, not reconciling the epoch date could introduce 28 cm of error, which is a lot considering I’m using RTK GNSS equipment capable of 1-2 cm precision.

Which software tool should you use to reconcile the datums and epoch dates? That’s the biggest challenge our industry faces today.

Very few GIS software and data collection software handle datums and epoch dates correctly. That’s a subject for the next article in this series.

If you’ve been interested in my two articles on this subject, you might want to attend a webinar I’m conducting to be held June 20, 10:00am Pacific time. I’ve lined up world-class panel members to join me in an in-depth discussion on this subject.

Webinar: Nightmare on GIS Street: GNSS Accuracy, Datums and Geospatial Data

Date: Thursday, June 20, 2013
Time: 10 a.m. PDT / 1 p.m. EDT / 6 p.m. GMT

An introduction to the challenge of dealing with disparate horizontal datums in your GIS. We are moving into a new era in dealing with datum transformations. Geodata 2.0 is coming, and it creates big headaches when imported into existing geospatial databases. Sensors such as GPS receivers and satellite imagery provide much more accurate (centimeter-level) data, setting up a collision with outdated and mismatched legacy horizontal datums.

Moderator: Eric Gakstatter

Speakers:

Kevin Kelly, Geodesist, Esri
Michael Dennis, National Geodetic Survey
Craig Greenwald, Mobile GIS Consultant, GeoMobile Innovations Inc.

Registration is free.

Following me on Twitter@ https://twitter.com/GPSGIS_Eric

 

If you enjoyed this article, subscribe to GPS World to receive more articles just like it.