What’s the Difference between a Used Car Salesman and a GPS Salesman?

Years ago, I heard a funny joke/maxim. I repeat it often and so do several others I know of so maybe you’ve heard it.

“What’s the difference between a used car salesman and a GPS salesman?”

Answer: The used car salesman knows when he’s lying to you.

I didn’t attend the Minnesota GIS/LIS Annual Conference last week, but I received a report from someone who attended a session in which the presenter seemed to fit the maxim quite well. One of the presenter’s messages was that people should stop using WAAS immediately as a GPS correction source due to the inability of data collection software to handle the ITRF00 > NAD83/CORS96 datum shift. Following is a statement from one of his slides…

“WAAS Real-time accuracy degraded because of datum shift”

He claimed that users are “in a panic over it.” In all fairness, the presenter could have very well understood that the datum shift can be handled by a number of data collection software packages…just not the one he represents. After all, he works for a local distributor of GPS equipment. Or, even a scarier scenario would be that he really believed what he spoke.

I’m not interested in naming names or company names of the offending party, but rather painting the true picture. Of course, the attendee I mentioned above knew better than to believe what the presenter was pitching. His group has been using WAAS as a primary correction source for a number of years and reconciling the datum shift between ITRF00 and NAD83/CORS96. It’s not that hard folks.

Let’s review.

ITRF00 is essentially the same as WGS-84(G1150) for sub-meter mapping purposes. WAAS (as well as EGNOS and MSAS) are referenced to ITRF00. You need to be aware that the definition of ITRF/WGS-84 has changed over time. Here is a link to a NIMA WGS-84 document that describes earlier versions of WGS-84 and here’s a link to the current version of WGS84 (G1150) that was adopted in 2002.

In North America (my apologies to readers from other countries), the generally accepted mapping datum is NAD83. NAD83 has also changed substantially over time. Whereas the original WGS-84 was consistent with the original NAD83 (NAD83/86), today there is a substantial difference between the current WGS-84(G1150) and NAD83/CORS96 and also NAD83/NSRS2007. Here is a graphic from Joel Cusick of the U.S. National Park Service that gives you an idea of the difference over North America:

Here is a link to a technical report from the National Geodetic Survey (NGS) describing the 14-parameter transformation from ITRF00/WGS-84(G1150) to NAD83/CORS96.

Sadly and surprisingly, some data collection software today and even some PC-based “GIS” software still treat WGS-84 and NAD83 as the same. This instantly introduces a few feet of error. The irony is that people spend thousands of dollars purchasing high-performance GPS/GIS receivers capable of sub-meter accuracy only to introduce several feet of error by using software that improperly handles the datum transformation.

What’s the solution if your software doesn’t handle the datum transformation properly?

As mentioned above, WAAS is based on the ITRF00 datum and not NAD83/CORS96. As most base maps in North America aren’t referenced to ITRF, most likely you’ll need to transform your WAAS-corrected coordinates to NAD83/CORS96. This can be done one of two ways:

1. As mentioned above, use GPS/GIS data collection software that handles the transformation correctly. This makes the transformation transparent, painless to the user and accurate in real-time.
2. Apply a datum shift after you’ve collected your data. You can compute the shift by accessing an NGS datasheet near your project area (within 25 miles is close enough). Make sure it was occupied using GPS. Better yet, use coordinates from a CORS. The datasheet will report coordinates in both ITRF00 and NAD83/CORS96. Here is an example of coordinates from the CORS at Wisconsin Point, WI (near Duluth where the MN GIS/LIS Annual Conference was held):

ITRF00 Position (Epoch 1997.0) – N 46 42 18.20201, W 092 00 54.760208

NAD83/CORS96 Position (Epoch 2002.0) – N 46 42 18.17201, W 092 00 54.73394

Simply enter the two coordinates into your favorite mapping software and you’ll be able to compute the distance and direction of the difference.

Once you know this, you can apply the same offset to all of the data for your project. Quick and dirty? Yes. We’re not splitting hairs. WAAS isn’t delivering cm-level accuracy so this sort of transformation is more than adequate…and very efficient.

The fact of the matter is that many, many organizations have adopted WAAS as a primary source of GPS corrections and are dealing with this datum transformation issue on a daily basis.

GPS Constellation Management: Playing Not to Lose

The WAAS/SBAS subject segues perfectly into the second subject of this column which is a follow-up of last week’s column on GPS Constellation Management.

Last week, I failed to mention that SBAS (WAAS, EGNOS, MSAS) is a valuable contributor to RTK users. Although not designed specifically to aid RTK ground users, some GPS receiver designers have exploited the value of SBAS satellites to enhance RTK operations. In North America, there are two SBAS satellites. In Europe, there are two and there are two in the Japan region. Following is a graphic depicting the regional coverage of the SBAS satellites and their approximate location.

In many regions of the world, users have at least one SBAS satellite available in view. The beauty of SBAS satellites for RTK is that, unlike GPS satellites, SBAS satellites are geostationary. The are available 24/7 as long as their signal path isn’t blocked by trees, terrain or buildings.

Since using SBAS satellites for RTK is a relatively new innovation within the past couple of years, not all manufacturers have jumped on the bandwagon yet. The slow adoption of GLONASS was similar. This causes a problem when users want to mix and match RTK receivers from different manufacturers. For example, a user purchases an SBAS-capable L1/L2 RTK rover to be used with their existing L1/L2 RTK reference station. If their existing L1/L2 RTK reference station doesn’t support SBAS for RTK, then the feature on their new RTK rover is worthless.

Even more important is the lack of support from RTN software designers. “No one’s asking for it” is the answer I get from RTN operators when asked if they are interested in supporting SBAS correctors in their RTN. I believe that users aren’t asking for it because users don’t have a clue how it would help them, and frankly, 99% don’t know the technology even exists. Now, if you would ask users if they’d be interested in one or two extra observables for RTK that would be
available 24/7 in a geostationary orbit every day, I bet you’d hear some really positive answers.

RTK users need to be able to utilize every observable that could help them. As Rob Lorimer and I reported last year in our market research report, machine control (based on RTK) will be the fastest growing GNSS segment over the period 2008-2012.