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

March 5, 2013  - By

This subject scares me. I’m not a trained geodesist. I’m not a mathematician. Yet, I’d be derelict in my duty if I didn’t write about this subject. I know enough to be dangerous, and enough to know this subject is going to be a nightmare for people managing geospatial databases.

Headache today, nightmare tomorrow

The only reason it’s not a nightmare today is because most of you don’t know it’s even a problem. Or, you know it’s a problem, but let it slide because dealing with it is not easy. It’s going to get worse in the future, much worse. It’s going to get worse because sensors (GPS, GNSS, imagery, etc.) are getting much more accurate. The cost of acquiring high-precision (centimeter-level) data, whether it’s via GNSS, scanning or ?? is falling hard and fast. As I’ve written before, high-precision GNSS receivers are getting much cheaper. Geodata 2.0 is coming, and it is making existing geospatial databases look like my kids’ coloring books.

It reminds me of an experience I had nearly 20 years ago.

I was traveling through the southeastern U.S. demonstrating a new GPS mapping handheld that I helped develop. Mind you, this was in the early days of GPS mapping. WAAS/SBAS didn’t exist, sub-meter receivers didn’t exist, CORS didn’t exist, and real-time corrections were only a dream so almost everyone post-processed using a local base station, if they could find one — and achieving 1-3 meter accuracy was pretty dang good.

I was showing this new GPS mapping receiver to a forestry company that owned a lot of land in the southeast. We traversed a ~40 acre parcel of land, brought it back to the office and post-processed the data against a nearby GPS base station. After post-processing, the data looked very clean and I was eager to see it inserted into the company’s GIS, hoping it would slide into the right spot in the GIS and they would purchase a bunch of GPS units. No dice. When it was inserted into their GIS, the perfectly shaped polygon fit imperfectly into the GIS. It didn’t match up with the orthophotos and it didn’t match up with their existing vector data (point/line/polygon). It was offset enough to make you raise your eyebrows and think to yourself — hmmm, that’s a problem.

Of course, I did my due diligence by checking the integrity of the GPS base station data I used and verified its surveyed antenna location. Everything checked out. I was confident that my data was accurate. I started questioning the GIS manager about the horizontal datum used in their GIS database. It quickly became clear to me that the enterprise GIS database was referenced to something different than the modern horizontal datum of that era. It was also clear that there were varying types of accurate and less accurate data in the GIS. A mish-mash of geographic data with some of it based on the legacy NAD27 horizontal datum that was transformed to NAD83/86 using NADCON or something similar.

After discussing this a bit with the GIS manager, he admitted that my GPS data was likely more accurate than his GIS database, but he was clear that “I’m not going to readjust my entire GIS database for your GPS unit.” My counter-argument that “you’re going to have to do it eventually anyway” was met with “I honestly don’t see this happening anytime soon.”

I may have won the battle, but lost the war.

Later that same year, I had a similar experience in California. A major environmental consulting company wanted to delve into using GPS for mapping. I sent them one of my GPS units to try. After a few days of the company collecting GPS data and post-processing, I got the call.

“Your GPS unit isn’t accurate enough for our work.”

Whaaaat? From the outset, I was clear to them that the GPS unit would deliver accuracy within 1-3 meters, and they stated this was acceptable accuracy to them. I looked at the data. It was clean and point averages were tight. It looked very good. I verified the GPS base station they were using. No problems there.

“What are you comparing the GPS data to?” I asked.

USGS 7.5’, 1:24,000 scale topo maps,” he replied.

Ruh roh.

Me: Wellllll, you know that USGS 7.5’ topos are referenced to NAD27 and have gross errors up to hundreds of feet in some places, especially rural areas, don’t you?

Him: We’ve used 7.5’ topo maps for many years and feel good about the accuracy they provide. Your GPS data is on the wrong side of the creek.

Me: Hmmm, how about you go occupy a survey mark with known coordinate and compare the GPS data to the survey mark coordinates? That will tell you how accurate the GPS is performing.

Him: We need it to work where we work, and it’s giving us data on the wrong side of the creek. Thanks for your time. Click.

Sigh, lost the battle, and lost the war.

After nearly 25 years in the GPS/GNSS and GIS industries, data mismatch (“my data doesn’t line up”) is still the #1 question I get from people.

The problem is two-fold.

  1. People, even educated geospatial professionals, have a general lack of understanding of the different horizontal datums being used (not to mention vertical datums).
  2. Software vendors (even the major ones), have generally done a poor job of keeping up with modern datum transformations. While most software makes it easy to transform data from one horizontal datum to another, they mostly do it wrong.

The errors can vary from a few centimeters to a few meters to tens of meters. In the world of GPS data collection, the most common datum transformation error is when software considers WGS-84 equivalent to NAD 83 and applies no transformation when, in reality, the difference between the latest version of NAD83 differs from the latest version of WGS-84 by more than a meter in most parts of the USA.

In this day of ever-increasing availability of public GIS data, it’s soooo easy to download an orthphoto (ortho-rectified aerial photograph), or GIS vector data from a public website and import it into your GIS. When importing, you’ll likely be asked to select the horizontal datum and the measurement units of the new data. More than likely, information about the new GIS data (metadata) isn’t readily obvious or available so you make your best guess from the list of choices presented. Is the data referenced to NAD83/86? Is it referenced to NAD83/HARN? Is it referenced to WGS-84? If so, which version of WGS-84? Your selection might significantly affect the accuracy of imported features of your GIS. What if you make the wrong selection with an aerial photo, then months or years later you have someone digitize (heads-up with a mouse) road centerlines, fire hydrants, manhole covers, etc., based on that aerial photo? Any transformation error you introduced when importing the original aerial photo will carry through to the digitized features.

The good news is that GIS software makes it very easy to import raster (images) and vector (points/polylines/polygons) data. That’s also the bad news. With a few clicks of a mouse, your GIS database can be infected with data you think is accurate to a certain level, but it’s really not, maybe due to the way you imported the data. I’m not saying that every piece of data imported into a GIS needs to be a certain (or the same) accuracy level. The problem is if you don’t keep track of the metadata for items that you import into your database, you will quickly lose a grip on the accuracy integrity of your GIS. As GIS data becomes more accurate, as I discussed above, the accuracy disparity among different layers in your GIS will increase. In other words, the problem will become bigger than it is today.

I’ll give you a scenario I’m involved with now that highlights this challenge. I used a pseudo-name for the company and have embellished a bit to emphasize some points, but the basic facts are correct.

ABC Company has tens of thousands of small infrastructure assets in the field across the U.S. It already has the desired location accuracy on some (within 30 cm, or 1 foot) on some of them. For the remaining assets, the company wants to improve the accuracy of the features. To do this, the company plans to use GPS/GNSS receivers to collect position and attribute information on the assets. A second requirement is to deploy GPS/GNSS receivers capable of sub-meter accuracy to navigate back to assets when necessary.

They are now in initial phase of testing various GPS/GNSS receivers.

Their first try was using a handheld GNSS receiver capable of “sub-foot” accuracy and post-processing against GPS CORS. It didn’t take long for them to figure out the workflow was a headache. I agree, the whole GPS post-processing workflow is so last decade (and mind you, I helped design one of the first Windows-based GPS post-processing software programs back in the 1990s).

For the second iteration, the workflow was much smoother. They used a GNSS receiver that utilized real-time WAAS corrections for sub-meter accuracy. The workflow was smooth due to real-time GNSS data being brought directly into ArcGIS Mobile in the field. The problem was accuracy. All of the coordinates collected during the testing were offset to the northwest by about 3 feet. Precision was great, but accuracy was unacceptable. Was it a problem with the GNSS receiver? No. When GPS/GNSS data is shifted consistently in one direction when compared to other data, it is almost always due to a difference in horizontal datums. In this case, it didn’t take long to determine that the difference was data referenced to ITRF (WAAS) vs. NAD83 (basemap). However, we had to do a little more investigation to understand which version of NAD83 was being used in order to find the best horizontal datum transformation choice in ArcGIS Mobile. It wasn’t obvious, not by a long shot. In fact, it was downright cryptic. There wasn’t a datum transformation labeled “WAAS” or anything close to it. As an example, one of the transformation names was cryptically named NAD_1983_To_WGS_1984_5. What does that mean? Which version of NAD83? Which version of WGS-1984? What does _5 mean?

With some investigation and experimenting with different transformation choices, we finally got it dialed in to a reasonable level. Remember, we were only looking for sub-meter accuracy so ~10 cm of datum transformation error here or there wasn’t significant. Even if we didn’t make the perfect transformation choice, we were close enough. However the investigation and experimenting drill was painfully time-consuming (locate a high-integrity survey mark nearby and occupy it), more than it should have been.

The next step, setting up the workflow for the “sub-foot” mapping GPS/GNSS receivers, wasn’t as easy. First of all, instead of using WAAS as a correction source (not accurate enough), they used an RTK network. The network base stations were tied to the latest version of NAD83, which is NAD83/2011. They really wanted to dial in the correct horizontal datum transformation. The challenges were a bit different than testing the datum transformation for the sub-meter equipment. They wanted to dial in the datum transformation as close as possible. Again, the datum transformation selection choices in ArcGIS Mobile were cryptic. But, this wasn’t the only challenge. Since they were using RTK GPS/GNSS receiver capable of 1-2 cm accuracy, errors within the different GIS layers emerged. Some layers were referenced to NAD83/2011, which was perfect, while other layers were referenced to much older versions of NAD83. To the software’s credit, an alarm popped up noting the difference in datums of the older layers, but didn’t give them any guidance as to how they should proceed. In that case, Cancel is the normal response and is what they selected.

After experimenting and testing the different datum transformations in ArcGIS Mobile, they found the one that seemed to produce the best results (confirmed by testing against a high-integrity survey mark). All in all, a very time-consuming process spread out over a few weeks.

A challenge that still remains is “hot-swapping” between using the RTK Network (NAD83/2011) or WAAS (ITRF08) as a source of GPS/GNSS corrections. ArcGIS Mobile doesn’t seem to deal with switching GPS/GNSS incoming datum changes very well on the fly (in the field).

If, after reading the above, you’re confused or feel the need to read it again to understand it, welcome to the club. Plenty of brainpower was spent sorting out this problem and verifying the solution. When your GIS has plenty of slop in it, no worries. When you start dissecting it at the centimeter level, you’ll really be forced to take a microscope to each data layer and all of the sudden metadata becomes very important.

This article is just an introduction to the challenge of dealing with disparate horizontal datums in your GIS. As the programmer for datum transformation at a major GIS software manufacturer said, “We are moving into a new era” in dealing with datum transformations. Although I mention Esri software in this article, other leading software vendors aren’t doing any better. I discussed the issue of supporting the 14-parameter transformation between NAD83/2011 and ITRF08 with another major software vendor late last year. Their CEO’s response? “Yeah, we just had an internal meeting on that and need to support it.” Whaaaat? I wonder how his thousands of users utilizing WAAS as a source of GPS corrections have been  handling this in the past 10 years. Not surprisingly, they aren’t the only major geospatial software that is falling down in this area. More than likely the software you use isn’t handling this correctly.

Lastly, in speaking with Michael Dennis at the U.S. National Geodetic Survey, he said that while the 14-parameter transformation algorithm is important, the step that people are leaving out is reconciling epoch dates of the data. Why is a date stamp of the data important? That’s the focus of my next article on this subject.

Follow me on Twitter by clicking here.

Thanks, and see you next time.

This article is tagged with and posted in GSS Monthly, Mapping
Eric Gakstatter

About the Author:

Eric Gakstatter has been involved in the GPS/GNSS industry for more than 20 years. For 10 years, he held several product management positions in the GPS/GNSS industry, managing the development of several medium- and high-precision GNSS products along with associated data-collection and post-processing software. Since 2000, he's been a power user of GPS/GNSS technology as well as a consultant with capital management companies; federal, state and local government agencies; and private companies on the application and/or development of GPS technology. Since 2006, he's been a contributing editor to GPS World magazine and the Geospatial Solutions website. He is the editor of Geospatial Solutions Monthly, a weekly newsletter focused on geospatial technologies. Follow Eric on Twitter at @GPSGIS_Eric.

4 Comments on "Nightmare on GIS Street: Accuracy, Datums, and Geospatial Data"

Trackback | Comments RSS Feed

  1. Eric, Well done, I really enjoy your columns, keep up the good work.

    Welcome to the world of Survey!

    As you say, the reason this ugly head is rearing now is because of increasing accuracy. Surveyors around the world have been working to cm precision with Survey Grade DGPS/GNSS receivers for over 20 years. Traditionally GIS has been regarded as low accuracy and diagrammatic as compared to CAD.But thats all changing. Most survey software such as Trimble’s Geomatic Office or Business Center is very good at handling datums and transformations, all be it the default selections available (these come from the EPSG database) are often out of date and inaccurate or of not published unknown accuracy. In my opinion the ESRI functionality is a disaster. Especially when you get in to user defined transformations.

    I think the situation is slightly worse than you have detailed so far because even when you have all the correct information regarding the datums and transformations to use and even if you work out how your particular software deals with those transformations i.e. are they reversible, do they expect angles signed as per the Coordinate Frame convention or angles signed oppositely for Position Vector; (as you say, expect lots of trial and error) even after all that, you have to deal with the fact that the transformation is an approximation and may not be that accurate anyway.

    This is because any country with an existing terrestrial based survey control monument system (such as the old OS trig pillars in the UK) upon which their mapping is based has the dilemma you describe where the GPS\GNSS measurements possible now, reveal the inaccuracies in the current mapping. The “known” size of the UK or even a small place like Grand Cayman is shown to be “wrong”, when easily measured with GNSS; the vector mapping is shown to be inaccurate by unknown amounts in unknown locations. Actually considering the technology available at the time the original mapping was done, GPS shows how amazingly good that original surveying was. Nevertheless the OS had to develop a “rubber sheet” transformation using a 1km grid of x, y corrections but even using that you can still position your self accurately using GPS and yet appear on the wrong side of the road because the line that marks the road is from historic measurements and is less accurate than the GPS. Do you resurvey the whole dataset or take more measurements to densify and improve the corrections i.e work out better values with which to distort the accurate GPS to fit the less accurate map.

    In Survey land the way we get around a lot of these problems is to use what Trimble call a Local Site Calibration. Basically you have to visit positions (survey control stations) with known east, north values, that surround your survey area,record your GPS positions at each location and calculate a correction, (a transformation specifically for that site) in real time on the logger. x, y shifts, a rotation about a centroid position and an optional scaling. The residuals at each control after the adjustment give an indication that you have, or have not, achieved the required fit.

    Here in the Cayman Islands where we have a legal duty to maintain an island wide cadastre of property land parcels we choose to use GNSS as an accurate survey tool. However there are still some boundaries which have only ever been surveyed with compass and tape. Two extremes of accuracy to deal with! Our long term solution is to change the entire National Grid and projection and migrate the existing inaccurate mapping to the new accurate GNSS friendly grid. Because we are a Government and Grand Cayman is only 80miles square this is potentially achievable. However, for large countries or companies with large datasets which are used for a myriad of purposes by a myriad of users this migration would be almost unthinkable.

    OOps I seem to have written an essay. Sorry. This stuff really gets me excited (some sort of genetic defect I expect!) I wrestle with it every day :0)

    Look forward to your forthcoming columns


  2. Jack Chen says:

    Many GIS folks do not know the difference among NAD 83, ITRF, WGS84. They usually do not care the difference because their GIS mapping applications need data of for example 1-meter accuracy at most; their GIS mapping applications do not need data of high accuracy. For survey, construction, hydrographic measurement, many GIS folks will have big troubles, as Eric encountered. I was using ArcPad for 3 years. GPS signals (in WGS84), WAAS signals (in ITRF), and GIS data (in NAD83_UTM_Zone_17N). How datum transformation and re-projection are performed is totally your guess; there seems no ESRI arctiles.

    I frustrated very much when I tried to create a new geodatabase. That was because those GIS folks do not the importance of coordinate system.

  3. Souvik Bandopadhayay says:

    Thank you Eric for such a nice topic and inner view. I also want to share my view as a GIS consultant. After going through the GPS system for many years I think the co-ordinate system used in the GPS is also a matter to consider. If I use only Geographical Coordinate System (only Lat/Long in DMS format) in the GPS receiver I think much more accuracy will be achieved. I come to this decision after an incedent happened in my canal measurement project. I use UTM coordinate and WGS 84 datum in both GPS and also in my drawing. After one year when I went to check the same place I didn’t reach the exact position provided by the GPS one year before. So where is the error. Then I start the study on it. But still I don’t find any proper reason behind it. Then I start to use GCS in GPS. I get much good result. I think in real world we have to use GCS system as Projection system and datum put 2D map or data in 3D world shape. So when we are measuring a 3D feature (real world) why we use Projection system within the GPS hardware? Please give some light on this matter, I will wait for reply.

    Thank you again……..

  4. Jeremy Stocks says:

    Hi there – I had exactly this problem 20 years ago whilst a relative newbie to GIS mapping the Arabian Gulf and Red Sea coastlines, all datasets captured within different datums. And worse, noone understood what I was babbling about!

    Within Aramco the largest oil company in the world, there were it was estimated only two people who had their head around why the datum was of vital importance to mapping and surveying.