# Presentation: 136468

## WELCOME

- Handouts Available

- Joel Cusick
- National Park Service
- Alaska Regional Office
- Joel_cusick@nps.gov

- Paper Presented to:
- ESRI Survey and GIS Summit, August 2006
- Sunday, August 6, 2006
- San Diego, CA

## Are You Really Mapping Submeter? 

**Are You Really Mapping Submeter?**** **

- Revenge of the *Shift*

**Notes:**
		           Paper #:           1580
		           Session Title:   GPS Technology I
		           Date:                Sunday, August 6, 2006
		           Time:               10:30 am – 12:00 pm
		           Room:              Room 7B (SDCC)

Submitted Title:  Submeter Mapping...Really?  The Revenge of the Shift

Submitted Abstract: 

Using a Global Positioning System (GPS) receiver has never been easier.  Accuracies claimed by various receiver manufacturers can be verified, and under good GPS conditions, mapping grade GPS can easily map at the submeter range, while recreational autonomous GPS can exceed the accuracy of the typical USGS topographic quad.  Where most of the mistakes are made is when basic fundamental field practices are disregarded and when the importance of geodetic datums are ignored.   Have you ever run aground on a datum mismatch either in the field or in the GIS?  This talk re-emphasizes the importance of some basic field techniques, regardless of the receiver make or model and controlling the dark side of GPS – datums and reference frames.  Using a quote from Yoda, fictional character from Star Wars - “Happens to every guy sometimes this does”.

## Fire Hydrant Survey

- Survey GPS

**Notes:**
Attention Grabber:  The Wrong Place for a Hydrant – This is told as a story.

You are a GIS specialist in Maine and just received that set of coordinates from the local surveyor you have been pestering him for months now.  The data includes the fire hydrants he collected 15 years ago with state of the art GPS (at that time).   Your real excited about transferring these data into your Mobile Realtime DGPS handheld system and verify hydrant locations and update attributes.   There is no metadata associated with the table, but the email says “NAD27” and the values are in decimal degree geodetic coordinates.  You convert the data to WGS84 (It’s the same as NAD83 Right?) You use a GIS package and use the datum transformation that applies to all of the US.  You load the data into your mobile device and hit the road.

## The Wrong Place

- 50 feet

**Notes:**
The field trip is a disaster. PAUSE

Even with sub-meter GPS, open sky and great real-time signal, you consistently 50 feet off from all of your intended hydrants.  You decide to trash the surveyors dataset, promise never to talk to him again and spend the next two weeks re-visiting all the hydrants to “Get it Right”.

## Revenge of the Shift

**Revenge of the Shift**

**Notes:**
The revenge of the Shift....   PAUSE

This scenario is sadly being played out with the latest technology and the best and brightest personnel in both GIS and Survey industries.  The GIS person used proper GPS techniques including range pole mounted antennas, and quality GPS filters.  The survey data was of the highest quality, yet some subtle shift has happened somewhere between the GIS and GPS. 

- NAD27-NAD83

- N 61o 33’ 50.0”
- W 149o 44’ 21.0”

- NAD27

- N 61o 33’ 50.0”
- W 149o 44’ 21.0”

- NAD83

- 200’ – 800’
- horizontal

**Notes:**
Most of you are aware of the large horizontal positioning error source when a NAD 27 datum is used when a NAD83 datum is required.  The same location on the ground is expressed in an error magnitude nearing 800 feet in some parts of Alaska.  This error is so large, most of us can readily recover from this shift even before the field.

## The Insidious Shifts

- 3’ – 50’
- horizontal

- NAD83 – WGS84/ITRF00

**Notes:**
What I want to talk to you today about is the more insidious shifts that we are encountering at an alarming rate mostly due to the increasingly accurate GPS systems that can “see” differences at the meter level or better and the more robust augmentation systems including WAAS.  Lets not forget how easy it is to verify in near-real time corporate datasets using mobile GIS systems.  

Datum shift errors at the 10 to submeter range are the kind I will address today.  These must be reconciled when GPS data is stored in a GIS or when GIS data is taken out in the field.

## Objective

- Verify Datum Used in GIS
- Confirm Reference Frame of GPS
- Apply the Correct Transformation

**Notes:**
Today, I want to address the three steps to take to avoid datum shifts:

Verify the Datum Used in the GIS, Confirm the Differential GPS reference frame and apply the correct datum transformation.

## Step 1. Verify Datum in GIS

- GIS as a blender
- Datum Transformations
- Standardize on NAD83
- Scale

**Notes:**
There are several good white papers on datums and observing differences.   Most dedicate one paragraph to “check with your GIS to ensure compatibility”.  This does not go far enough.  As a GIS guy, I am going to expound on some key points when you need to verify and use coordinates in a GIS. 

## GIS as a Blender

- It’s the GIS Way

- NAD27

- GPS

- NAD83

- WGS84

**Notes:**
If I may simplify a GIS is a blender.  It takes data from one or more coordinate systems, and thereby underlying map projections, each of which can be referenced to a datum... and allows these data to be presented together.

## Datums and Shifts

- Most all coordinate systems are referenced to a specific datum
- Mix two different datums for the same point

- Shift

**Notes:**
Most all coordinate systems are referenced to a specific datum.

Mix two different datums for the same point and you get a shift

The action to take when confronted with a difference is up to the user.

## Datum Shift Errors

- Datum shift *errors* are realized when different datums are mixed and wrong assumptions are made

**Notes:**
Datum shift errors are realized when different datums are mixed and wrong assumptions are made.

## Datum Transformations

-  Formula to convert between two datums
- Legacy GIS
- Thousands
- Move GPS data data to/from GIS
- WGS84_To_??

**Notes:**
Datum transformations are formulas to convert between datums.  
In Legacy GIS, like from ESRI, there are hundreds, thousands of transformations. 

Data came into a GIS in various forms and its up to the GIS staff to document the way the data got into a datum.  

For those using GPS and inserting GPS data into a GIS, these transformations begin with the text “WGS84_To_ XX?  There are dozens of these.

## Datum Transformations

- In a *GIS* They Work Both Ways

**Notes:**
In a GIS, datum transformations work both ways.  Software syntax sometimes clouds this issue by using one transformation name for the process of taking a dataset both forwards and backwards.  This example shows how to take a NAD27 dataset into NAD83 datum using the NADCON  transformation.  

You would also use this same transformation to move a dataset from NAD83 to NAD27 using NADCON.  Confusing eh?

There really isn’t anything a GIS library could do.  They either produce an engine that knows what datum the layer is stored in (that’s not possible), or double the entire transformation library with the text switched around – not good either.

## Datum Transformations

- You *Can’t* Go Back!
- Human Error is the Cause
- Lack of documentation
- Fundamental principle behind Mobile GIS

- Myth

**Notes:**
Let me emphasize one point I hear a lot.  Once you transform a dataset from one datum to another you can’t get back to the original data – or if you do get the data back, its moved.
This is a Myth 

A certified transform is an equation that are used by a modern computer to shift data.  The Transform may be inappropriately used, but you can always get back to where you started if you know how you got there!

The human error budget greatly exceeds the rounding error of even the most complicated transformation.  Lack of documentation is often the root cause.

This is fundamental to how Mobile GIS and the Check in / Check out routines work. Taking GIS out in the field with GPS would be impossible if these transformations were not exact!!!!!!!!!!!!!!!!

## Standardize on NAD83

- If you are using GPS data you should be in NAD83

- Alaska - Part of the Continental United States since 1867!
- ...But Still using the                                                  1866 Spheroid

**Notes:**
Standardize on NAD83.
Ask for a show of hands – those that are based in NAD27 GIS?
As an Alaskan, I can consider myself an expert on just how ugly transformations can get if you are using GPS with NAD27 based GIS.  
Quote:  Alaska – part of the continental US since 1867, but mapping using the 1866 spheroid.

## What’s Wrong with NAD27

**What’s Wrong with NAD27**

**Best fitting to just North America**
**Non Geocentric**
**Significant scale and azimuth distortion**
**Poorly determined relationship to the geoid**

**Notes:**
What is Wrong with NAD27?

If your mobile GIS system looks like this, then NAD27 is just fine.

NAD 27 is not Global in nature, non-geocentric, has significant scale and azimuth distortion and poorly determined relationship to the geoid.  But don’t listen to me....

## Standardize on NAD83

**Standardize on NAD83**

- Dave Doyle in Alaska February 2005
- Cousin Vinny

- * Dave Doyle, Senior Geodesist – NGS, 2005.  Alaska Survey and Mapping Conference, Anchorage Alaska.

**Notes:**
18
Listen to someone like Dave Doyle, Senior Geodesist for NGS.  Dave came to Alaska in Feb 2005.  I called him Cousin Vinny – you know the guy who breaks knee caps when you don’t show respect

## Standardize on NAD83

- Convert NAD27 to NAD83 using NADCON
- Cases where NADCON is not a good idea
- USFS reliance on PLGR’s from mid 1996 to 2000

**Notes:**
The most accurate transformation is the NADCON method.  This would be the default transformation to move mass amounts of data that came from NAD27 (like those digitized from USGS quads).
There is a loss of accuracy 10-15 cm RMS ) in the conversion process, but NADCON is sufficiently accurate for most mapping purposes. 	 

In some cases, NADCON is not the method you want to employ.  The US Forest Service went thru a painful exercise last year converting mountains of PLGR collected data from the Mid 90’s. 

## Unusual NAD27 Conversion Cases

- * Andrew Lister, Research Forester, USDA Forest Service, 2005.  email

- NAD27 to WGS84_4
-  vs
- NADCON

**Notes:**
The PLGR had 4 NAD27 choices, and persons either recording the NAD27 position off the screen, or storing NAD27 data on PC’s were using a Molendensky transform.  Assuming this data was NADCON quality is mis-representing the data.

This is a graphic representation of the horizontal error (in meters) between a low-end 3 parameter WGS84-NAD83_4 transform, relative to a NADCON conversion of the same data.  These errors approach 18 meters – 50 feet.  This is the fifty feet error I referenced at the beginning of this presentation – the fire hydrant survey in Maine.  

Illustrates how a GIS corporate dataset can be corrupted.    This should give GIS specialists serious pause when transforming GPS data. 

- – www.fs.fed.us/database/gps                                Mark Roper

**Notes:**
This graphic lays out a pretty confusing topic.  This pathway demonstrated here is what led to original error.
Properly informed GIS specialists can recover from these damaging effects. 
I am not going to belabor this point anymore and go into details.  Just realize there are pathways that lead to shifts, some of which are un-intentional and can lead to horrible confusion in GIS shops.

## Scale – Worry or Not?

- GIS Data Scales
- Data digitized at 1:24,000
- NMAS states - +/- 40 feet
- Mapping GPS Errors
- Large - Autonomous GPS (pre SA)
- Mid - PLGR / Autonomous GPS Today
- Small - Mapping Grade

**Notes:**
A case can be made however to ignore certain transform errors due to the scale of the data involved and the GPS receiver accuracies that were used to collect the data in the first place.
GIS Data Scales
The inherent accuracy of a USGS map product at 1:24,000 scale translates to an –on-ground accuracy of ~40 feet or so.  

GPS Accuracies.  Deciding what transformation to use to convert data from GPS, I put the GPS receivers into 3 buckets by the accuracy estimates.  
Large - Autonomous GPS (pre SA)
Mid - PLGR / Autonomous GPS Today 
Small - Mapping Grade

Considering the scale of both your maps and GPS are an important consideration when worrying about Datum shifts.

## Step 1.  Verify Datum in GIS

- Standardize on NAD83!
- Convert NAD27 to NAD83 using NADCON
- Special Cases Require Care
- Consider Scale of Data

**Notes:**
You cannot see a shift unless you are comparing data from two or more independent surveys.  Since GIS can do all this fancy transformations, both on the fly and internal, you have to Verify the Datum in the GIS.  This is the most difficult step

If you have a mix of datums, Don’t proceed until you have standardized on one Datum.  NAD83 is the standard and the Law.  Consistent Datums is the ky to proceeding through transforming.
Convert old NAD27 data to NAD83.  ANCON is the preferred approach to maximize the accuracy of the transform.
Unusual cases abound where ANCON is not the preferred case to take nad27 data back to nad83, because this was not the transform initially used.   Go backwards and make the decision if the extra effort is worth it due to the 
Scale of the Dataset, the GPS quality to begin with.

## Step 2.  Confirm the GPS Reference Frame

**I’m in NAD83**

**WGS84**
**/ITRF00**

**Step 2.  Confirm the GPS Reference Frame**

- Which Reference Frame are you In?

**Notes:**
This slide illustrates the next step – Confirming the GPS reference Frame.  Knowing which reference frame can be the difference between a meter plus and mean life or death to your otherwise complacent GIS manager.

## Datum Adjustments

- WGS84 (G1150) – most current version
- “Original” NAD83 = NAD83 (1986)
- NAD83 (1992)
- NAD83 (2002).............
- NAD83 (CORS96) (Epoch 1997.00)

**Notes:**
GPS datum coming from the satellites is on WGS84 (G1150).    This means a WGS84 and a realization of GPS date G1150). 
NAD83 as a datum has gone through plenty many revisions.  A few are shown here.  The original in 1986, now the current version is NAD83 (CORS96).  I am not the person to explain these dates, or why they are being altered, I just know its not fair to say anymore that your GIS is in NAD83.  You need to add the date of the realization to the datum.

## Over Time Datums Have Grown Apart

- NAD83 (1986) = WGS84

- WGS84 = ITRF00 (2cm)

- NAD83

- ~ 1 meter

**Notes:**
This slide is an attempt to show the change graphically.  The original WGS84 datum definition was essentially the same as the original NAD83 (called NAD83 (CORS96)).
Over time both datums have been redefined several times and they now differ up to a meter.
The WGs84 definition has been aligned with the Global ITRF definition to the point where ITRF 2000 and the current WGS84 differ by a cm or two.
As a mapping grade guy, I will assume these two are the same and will say whenever I see an ITRF00 coordinate, I call it WGS84.

## Which Reference Frame are You In?

**Which Reference Frame are You In?**

- CORS users are in ITRF00

**Notes:**
The best choice for a GIS is to ground yourself into the National Spatial Reference System provided by NGS.  You do this by utilizing CORS data.  The Alaska map is seen here.    Those who postprocess against CORS stations are in ITRF00. 

## Which Reference Frame are You In?

- Since you corrected against a CORS station...

**Notes:**
Observe any CORS stations Antenna Reference Point and you can see this first hand.  Since you corrected against a CORS station this graphic from the NGS site confirms the Antenna reference position is ITRF00. 

## Which Reference Frame Are You In?

**NAD83 (CORS96)**

**NDGPS (Beacon)**
**OMNISTAR (Satellite)**

**CORS Post Processed **
**Autonomous GPS**
**WAAS **

**WGS84 (G1150)**

**ITRF00**

**=**

**Notes:**
So... So Which reference frame Are you In?

If you post-process against CORS, use autonomous gps or use WAAS you are in ITRF00 or WGS84.
If you use realtime NDGPS or Omnistar you are in NAD83(CORS96).

## GPS Base Station Providers

- The Trick is knowing what reference frame

**Notes:**
If you use Community base stations, as those provided by surveyors, GPS vendors, the reference frame you are in are those of the CBS base station.  This station – Compass Tools Base station is an excellent example of how to provide information to the end user.  These guys actually have a paragraph dedicated to coordinate discussions.

## Step 2.  Confirm the GPS Reference Frame

- Which Reference Frame Are You In?

## Step 3.  Apply the Correct Transformation

- Use Zero Transformations when Appropriate
- If NDGPS differential
- NAD83 Reference Frame
- If post-process CORS, WAAS – ITRF00 Reference Frame
- Transform using NAD83 (CORS96)

- Do Nothing!

- See Handout for Trimble and ArcPad Users

**Notes:**
Refer you now to the handout, but this step is realtively easy. 

Apply the Correct Transformation:  Now that your GIS is set to NAD83, then use the correct transformation to ensure that no datum shift error is introduced when GPS data is built into GIS feature geometry.
Use Zero Transformations Where Appropriate
Software has treated NAD83 = WGS84
Be Aware
Transform correctly the sub-meter GPS
Resolving the NAD83 Datum Transformation – Trimble Handout
ArcPAD  - ArcPad Handout

## Avoid the Shift

- GIS Community
- Surveyors
- Software Developers

**Notes:**
Avoiding the Shift is really up to us.  
As we populate GIS datasets with GPS it is up to us to maintain the highest level of integrity for our GPS data.  I would like to talk about these three communities – The GIS community, Surveyors and best of all, Software developers.

## Avoid the Shift

- GIS Community

**Notes:**
To the GIS community.

## Avoid the Shift

- GIS Community
- Test Against Control

**Notes:**
Test the new GPS systems designed to provide submeter and sub-foot positions.

NGS provides easy-to-use tools so occupation of survey control in your area is possible.

Consider it a high accuracy version of geo caching, but test and observe the shifts yourself.

I guarantee a rewarding experience by observing shifts first hand.

You may seriously reconsider throwing away that surveyors dataset.

## Avoid the Shift

- Surveyors
- Communicate better in map products, digital data and reference stations

**Notes:**
To the Surveyors among us...
Communicate better in your map products and digital data files the origin and processes that you applied to your data.  When you run those Community base stations, please advise the user community how you are storing the gps data for users.

Providing more info to the GIS community may prevent costly re-surveys and confusion.

## Avoid the Shift

- Software Developers
- Standardize Syntax
- Enhance Datum Interfaces

**Notes:**
Ahh... I saved the best for last.

Standardize syntax.  I don’t know how many times I turn from one datum definition in the GPS software and its called something else in the GIS software.  I don’t have a solution here, but couldn’t these companies eliminate confusing syntax in dialog boxes and use the same terms.

Enhance datum interface.  Allow better access to the coordinate system engines and documentation.  ArcPad 7.1 is soon to release a refreshingly simple interface to allow users to control datum transformations.  This will practically eliminate a need for the second ArcPad handout provided to you (The Carl B. ArcPad doc, version 2).

## Avoid the Shift

- Software Companies
- Standardize Syntax
- Enhance Datum Interfaces
- Embed Transformation Used inside Data Layers

- MXGPS
- www.mxgeo.com/

**Notes:**
Finally embed transformations used inside the data layers.  Store these as an attribute.  I only know of one software – MxGPS that does this.  MXGPS, written for Garmins, no less, provides the ultimate way to back out aof a datum without the burden of documentation outside of the process.  How many of you do officially recognized FGDC metadata?  I thought so.  Why not embed the transformation that is used so we can take the data back if we have to.  I think Alaska could have moved to NAD83 much sooner if we knew how some NAD27 data was transformed in the first place. 

## Conclusion

- Verify Datum in GIS
- Confirm Reference Frame
- Apply the Correct Transform

**Notes:**
Today... I hope you found this topic interesting and relavent to this conference.
Datum shift errors are probably the most confusing aspect of utilizing high accuracy GPS systems and using those data in a GIS.

To avoid shifts its important to not rush out and change settings on the GPS without first investigating which datum is used in the existing gis layers.  Eliminate inconsistent datums in the GIS is a key... and make sure its NAD83.

Second, confirm the reference frames of the GPS differential source and 

Third, apply the correct transformation that matches the reference frame of the GPS to the datum used in the GIS.  

If we all pull together – GISers, Surveyors, and Software developers, we as a user community can reconcile Datum shift errors BEFORE they take revenge out on us.

## Acknowledgements

- Carl Beyerhelm, USFS
- Ron Bisio – Trimble
- Shane Clarke - ESRI
- Michael Dennis, Geodetic Analysis
- David Doyle, NGS
- Melita Kennedy, ESRI
- Andrew Lister, USFS
- Mark Roper, USFS
- Mel Philbrook, Trimble
- Myles Sutherland, ESRI

**Notes:**
I want to acknowledge the following persons who have helped make this presentation a reality

Carl Beyerhelm, USFS
Ron Bisio – Trimble
Shane Clarke - ESRI
Michael Dennis, Geodetic Analysis
David Doyle, NGS
Andrew Lister, USFS
Melita Kennedy, ESRI
Mark Roper, USFS
Mel Philbrook, Trimble
Myles Sutherland, ESRI