The No. 1 Question I Was Asked 20 Years Ago Is Still No. 1

On the tail of the Esri International User Conference (UC) and the first-ever live event webinar we’ve ever conducted, I’d like to revisit a subject I’ve pounded hard for the past couple of years. It’s a subject that still, after my 25 years in the geospatial industry, is still the most common problem that geospatial users ask me about.

First, however, the live event webinar at the Esri UC. What a blast it was to broadcast live from San Diego with people walking by and the buzz of 14,000+ conference attendees in the air! I’ll definitely be looking for more opportunities to broadcast live from events like this. The webinar was great. It touched primarily on high-precision GNSS on mobile devices. If you weren’t able to attend and would like to listen to it, register here and you’ll be sent a web link. Then, just last week I conducted a follow-up webinar that dug further into the details of how to use RTK (real-time 1-2 cm accuracy) on almost any mobile device. If you missed it and would like to listen to it, register here and you’ll be sent a web link.

So, what is the #1 question I was asked 20 years ago and is still the #1 question I’m asked about today?

“Why doesn’t my GPS data line up?”

Part of the reason that the question has been a consistent perennial favorite is that low- to medium-cost GPS (now more commonly referred to as GNSS) receivers have become more accurate, so our expectations for better accuracy have increased. It used to be that 2-5 meters (after post-process differential correction) was about what you could expect from a $10,000 GPS receiver. Today, you can buy a real-time, submeter receiver for under $2,000 and an RTK receiver capable of 1-2 cm accuracy for two to three times that.

So, “why doesn’t my GPS data line up?”

I wrote two articles that attempted to summarize the problem. The two-part series was entitled “Nightmare on GIS Street.”

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

Part2 Nightmare on GIS Street: Accuracy, Datums, and Geospatial Data

Horizontal datums, and changing horizontal datums, are the root of the problem. Lack of user knowledge and GIS software vendors’ improper implementation of horizontal datum transformations exacerbate the problem.

There are a few common horizontal datums used, at least in the U.S.. Outside of the U.S., there a myriad of datums with associated transformation algorithms. A few common ones are:

ITRF08 – International Terrestrial Reference Frame of 2008. ITRF08 is world-wide datum with no epoch (time stamp) associated with it.

WGS-84 (G1674) – World Geodetic System of 1984. WGS-84 has changed substantially over the years. G1674 is the latest revision (actually, I think G1762 is out but I’ll leave that for now). At epoch 2005.0 (January 1, 2005), WGS-84 (G1674) and ITRF08 are within a centimeter of each other.

NAD83/2011 – North American Datum of 1983. As with WGS-84 and ITRF, NAD83 has undergone significant changes over time. The current version is NAD83/2011 with an epoch date of 2010.0 (January 1, 2010).

Now, it would be great if all of our geospatial data was referenced to the same datum. In that case, all of our geospatial data would line up perfectly. But, it’s not that easy. In fact, not only is data published in all three of the above datums (and more), but also a lot of legacy geospatial data is published in earlier versions of the datums above, which can significantly differ from the current revision of the same datum.

For example, if you received geospatial data that is reported to be referenced to NAD83? What does that mean? Is it the original version of NAD83 or is it the latest revision of NAD83 (2011) or somewhere in between?

Let’s take a practical and very common example.

Assume you’ve got a high-precision handheld GNSS receiver. Unless you’re connected to a RTK network or post-processing, you’re likely using WAAS as a source of GPS corrections, which is a very common setup.

Let’s say that your GIS database is referenced to NAD83/2011, another very common setup.

WAAS is referenced to ITRF08 current year epoch.

ITRF08 differs from NAD83/2011 from 2 to 4.5 feet in the U.S. depending on the geographic region you work in. So, if you don’t adjust your incoming data to match NAD83/2011, the data you add to your GIS database will be offset by 2 to 4.5 feet. Following is a graphic from Michael Dennis of the National Geodetic Survey that illustrates the difference between NAD83/2011 and WGS-84/G1672.

Source: National Geodetic Survey

What’s really important to note about the slide above is the epoch date. I write about the time variable of datums in Part2 Nightmare on GIS Street: Accuracy, Datums, and Geospatial Data. The bottom line is that the ground we walk on moves. It’s only very slightly, unless there’s an event like an earthquake, but it’s constantly moving, and generally in the same direction and rate. In the midwestern U.S., for example, the ground may only be moving a few millimeters per year. In some places in California, the ground moves 4 cm per year. If you’re using RTK to achieve 1-2 cm precision, 4 cm is a big number and can’t be ignored. If you located a point five years ago with RTK to the 1-2 cm level and revisited it today, the difference would be 20 cm, well over a half foot.

What methods are available to adjust for the difference between the two datums?

There are at least three ways I can think of. Of course, the easiest one is if the data-collection software you use is smart enough to deal with this. Unfortunately, this is not likely. Surprisingly, even mainstream GIS data collection software sold today doesn’t address this problem.

1. Some data collection software (ArcPad, SurvCE, FieldCE) have the functionality to define the GPS datum and apply a datum transformation in real time (in the field) so it’s transformed to NAD83/2011 before it’s stored in the GIS database. Note, however, that even fewer are able to deal with crustal movement. For example, take a coordinate time-stamped 2008 and “move” it to 2014.
2. Apply the datum transformation after the data is collected.
3. If your GIS software doesn’t have the correct datum transformation functionality built in, use a tool such as HTDP (Horizontal Time Dependent Positioning) to determine a precise offset distance and direction in and apply the offset to all of the data collected in that geographic region. Since WAAS precision is 50 cm at best, this type of offset correction is perfectly suitable.

As I mentioned in  no. 1 above, several software packages can transform between datums, but very few can take into account the time component of datum transformations. In other words, they don’t take into account the fact that the ground we stand on is moving.

Some people are beginning to take note that addressing the time component of datum transformations is just a matter of time, which it is. For example, Geomobile Innovations just introduced a plug-in for ArcPad that adds extensive datum transformation functionality to ArcPad, including accounting for the ground movement. It turns ArcPad into a true high-precision data-collection tool.

More good news is that the big dog is starting to wake up. At the Esri UC last month, I heard from a reliable source that Esri has made dealing with this issue an active project, and is working on the logic and user interface to implement a time-dependent datum transformation model (commonly known as a 14-parameter transformation). As someone who used to design GIS data-collection logic and user interfaces, I can appreciate the challenge of implementing this model. What happens when a road/pipeline/transmission line crosses from one tectonic plate to another when the two plates are not moving the same direction and velocity? How does one make accounting for that easy to use yet technically correct?

Thanks, and see you next month.

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