A Foot Here, Three Feet There
November 15, 2011 By: Eric GakstatterLast week I posted an article titled "What Every GIS Manager Should Know, But Likely Doesn't" that probably ruffled the feathers of a few GIS managers.
One reader opined:
Just read your article "What Every GIS Manager Should Know, But Likely Doesn't". I think it was a very good article, and a very important topic, but I take exception to the title. As a GIS manager, I think that title is misleading — to imply that a GIS manager is not aware of this issue. I will agree, the other people mentioned in the text, the general public, mom, emergency crews, folks, boaters, etc. do not have a good idea of the accuracy and precision issues. But a GIS manager should, and I would argue does. At least I do. Maybe it's the surveying background I had 30 years ago, but I think it's just in the job description to make it your business to know, and in the nature of the type of people who have these kinds of jobs to be curious about it and to make themselves well informed and/or trained. I would also think an architect would, but I'm not going to take up their cause.
So again, good article. I think it's an important issue. I try to get others to be informed on the topic whenever I can. Keep up the good work. I'm a charter subscriber to Geospatial Solutions, back when it came out originally as GeoInfo Systems.
I wrote back that I think his surveying experience contributed significantly to his understanding of accuracy.
I'm not convinced that most GIS managers understand accuracy of their data and what it's referenced to. Many I've spoken to in the U.S. say their GIS is referenced to "NAD83, State Plane." OK, which flavor of NAD83? Which epoch date is it referenced to? How often is it adjusted, if ever? Answers to these questions affect the accuracy of spatial data in a GIS. You could say I'm splitting hairs. What's one foot here and three feet there? Well, as I've stated before, the accuracy of data you're plugging into your GIS is only going to get more accurate. Satellite data is becoming more accurate and more available, terrestrial 3D scanners are becoming more prolific, and GPS data continues to become more accurate.
Geodesy is going to play a more important role in the future of GIS. As sensors (3D scanners, GPS, etc) deliver more accurate data, it's going to flush out the inaccuracies of every GIS. The warts will start to surface.
Yet another reader chimes in on the same subject:
I still get the accuracy questions occasionally and I tell them to find something that doesn’t move like the mailbox in their front yard and locate it many times, at different times and on different days, noting the coordinate pair. If you use UTM, you can quickly see at least the range in meters. Along this line, when doing the survey marker locating you suggest, I am curious, with all the datums at play, is the datum/coordinate system transformation process itself introducing some error or better described as an offset?
The reader raises a good point. GIS software users assume that the software vendors have implemented the correct transformations. This isn't always the case.
Hi Joel,
I've been differentially correcting the mountain of files we have from this summer, and have run into a few things.
First, when I went through the exercise of checking that the CORS coordinates from the website matched what was in the Pathfinder list, I discovered that the CORS pages have changed, and many of them no longer list the coordinates in the old datum (the one that's listed in the Pathfinder list). I decided to assume they were all okay.
But now, today, I tried to update my list of base stations in Pathfinder, and now the whole list comes up with "?" in the integrity column. I've re-downloaded it several times, always with the same result. In addition, I'm missing a bunch of the CORS stations that I ususally use (i.e., the CORS AC76 station in Tok). It looks like many of these stations may still exist, but are now listed as UNAVCO (there's a UNAVCO site in Tok that lists AC76 in brackets).
Are these all things that are known issues, and should I just not worry?
How do I know now which stations are the best to use?
Thanks,
Heidi
Hello Trimble Support, cc: Heidi,
I suspect I am not the first one to ask this question in regard to the way NGS is posting the newly calculated antenna base-station coordinates. Your Pathfinder Office CBS list appears to remain seeded with ITRF00 1997 EPOCH 2003.0 (Alaska) values which have not changed for several years. Prior to the new coordinates and NGS change, one could instantly verify via CORS station the values of XY and Z from the Base Station Provider, BASE Tab and the NGS Coordinates page. Today, this is not the case, and conflicting values are observed. For the purpose of this discussion, i will use the CORS GUS6 station in Alaska. Simply compare the GUS6 coordinates from your CBS list to http://www.ngs.noaa.gov/cgi-cors/corsage_2.prl and you will observe this issue.
To highlight this issue (again, i am not a Geodesist), i took the same SSF file, and diff. corrected twice. Once using existing ITRF00 values, and then once more with the seeded IGS08 values. Measurements occurring in PFO map view with Coordinate system set to LAT/LONG "WGS84." My results reveal a half of foot difference. This exceeds the horizontal accuracy of a 6000 by 100 percent.
My apologies if my wording is unclear. In the language of PFO Differential Correction Wizard, here is what is now showing up with differences:
1) Use reference position from base provider. Your CBS list shows older ITRF00 1997 EPOCH 2003 values. While NGS has new IGS08 EPOCH 2005 values.
2) Use reference position from base files. Revealed thru differential correction, your seeded values show older NAD83 (CORS96) Epoch 2003. While NGS displays NAD83 CORS96) EPOCH 2002.0 values.
In light of these changes and your salesmen and women selling the dramatically more accurate 6000 series, a user can now place very accurately coordinates in the wrong place with no real way to validate against a CORS reference frame. Your company needs to do the following as soon as possible:
1) Guidance as soon as possible on recommendations. This may include (I AM NOT A GEODESIST. I AM A BIOLOGIST).
a - updating CBS values if this is the appropriate route. Regardless, your CBS list is the Trimble portal into what ref. frame we are using. You need to set the record straight with new values to reflect CORS change. The base provider (CORS) is not using ITRF00 1997 coordinates anymore....
b - altering CBS values to NAD83 only, hence eradicating the duality of using either ITRF or NAD83 from the differential correction workflow. this would line your software up with CORS c - The ultimate issue of EPOCHS and how best to resolve comparing old and new values. Does this reference frame switch make a difference? If anything, you must not perpetuate that NAD83 remains the same. It is now different.
2) White Paper revealing what to do in light of new reference frames. Your May 2005 white paper, which remains on your website is now not a representation of the reference frames that NGS are reporting.
3) WEBINAR on what to do!
In short, NGS no longer is posting the ITRF00 1997 (EPOCH 2003.0) coordinates for CORS. Hence, your CBS list cannot be directly compared, nor can it be used to postprocess the true value of the CORS base station today. Things have moved, and in Alaska, they move big time. If this is not causing panic now, it will, when persons realize a 1/2 foot difference between what you are reporting as base-station coordinates and CORS. Users who practice due diligence and prudent checking (all of our students do this in our classes) are seeing differences.
Joel,
I just spoke with Curt Smith, our NGS advisor for ID and MT. He explained to me that about January 1st, all published monuments will be assigned new coordinates. Once those are published, users will expect CORS to provide a consistent coordinate system - so at that time I will be updating the coordinates in our base files for the MTSU CORS station, and I'm guessing other CORS station operators will do the same.
The difference at MTSU between NAD 83 (CORS 96) and NAD 83 (2011) is a couple cm. That means the actual (most updated based on new, more accurate measurements) location of the base station is roughly 2 cm different from the NAD 83 (CORS 96) location.
The difference on the MSU campus between coordinates referenced to NAD 83 (CORS 96) and coordinates referenced to ITRF 2000/WGS 84 is 1.22 meters.
If/when Trimble decides to make a change in the base provider coordinates (ITRF 00 --> IGS 08 or ITRF 00 --> NAD 83 (2011)), users will have to realize that their old data won't fit exactly with new data (on the order of a couple cm). And, people will still have to realize that there is a datum shift between IGS 08 and NAD 83 (2011) - and be careful not to introduce it when exporting from PFO.
I personally would like to see them use the NAD 83 (2011) coordinates. These are the coordinates we will be putting into our base files. That way there will be no difference between the base provider coordinates and the base file coordinates. This might eliminate some of the confusion. However, I don't think they will do this because they are serving people all over the world, not just in North America. I'm guessing they'll go with IGS 08.
I would hope that Trimble would make the change at the time when NGS assigns new coordinates to the published monuments. And yes, I agree that a white paper is an absolute necessity, plus a webinar and whatever else they can do to explain the change clearly and avoid confusion.
Here is a good link for more information:
http://geodesy.noaa.gov/CORS/coord_info/myear_FAQ.shtml
I hope this adds some light to the discussion.
Diana
Diana:
There is really nothing new in this whole issue. As you have correctly noted the difference between the datum values will be a couple of cm or less in most locations. The differences between the NAD83 realizations and WGS84/ITRF realizations have always existed.
Regardless of the name be it WGS84 (XXXX)/ ITRF xxx or NAD 83(xxxx) there has always been a difference between these two datums. Horizontally it is around 1 to 1.25 m radial and around 1.5 m vertically relative to the ellipsoid. It all goes back to the different ways that the NGS and the DMA defined the datum. The original realization of NAD 83 and WGS84 were intended to be identical but due to a very slightly different computational approach they ended up being different. The (0,0,0) transform between the two datums has always been a fiction but it allowed some smoke and mirrors to simplifying computations.
In PFO you have the choice of whether to use the coordinate values in the base file or the User supplied coordinates (generally ITRF values) when setting up a differential correction. The problem I have found over the years is that one is never quite certain of how the base files are referenced. I think that one is better off using the user supplied (ITRF) coordinates because they are correct and referenced to a known datum. I think Trimble using NAD 83(2011) coordinates will be a step backwards and lead to more issues with data quality.
In reality the difference in the CORS station coordinates will generally be in the noise budget of the receiver and differential processing procedure unless you are using a cm capable receiver. Short of using an survey receiver 2 cm will not be seen by any mapping receiver.
Mike
Mike,
I read with great interest your response to the differences. I will have to disagree with you that these "can't be seen by a mapping receiver".
Here are my 2 points.
1) Any difference we swallow during postprocessing is additive, since its the GIS way to transform data, back and forth for meeting a clients needs. The luxury of staying in one reference frame we do not have in our profession. Hence, 2 cm here is another 2 cm there and a 4 cm there when you think your using the right shifter when you are not. I have demonstrated this several times which shows how "GIS quality data" can drift over time when eventually you can't get back to where you started. Ignorance on the part of Software companies can't be tolerated especially when published transformation are freely available to those who want them. If the math to do the shift right is available, why use the wrong math?
2) I would beg that with a well handled 6000 receiver in Alaska or Hawaii, the differences are significant. Were on fast moving plates. Giovanni
Sella calculated 16.9 cm in the vertical for SouthEast CORS station (GUS6).
Gulp.
Kindly, Joel
Clear as mud?
I think the following statement by Joel succinctly summarizes the situation:
"Ignorance on the part of software companies can't be tolerated, especially when published transformation are freely available to those who want them. If the math to do the shift right is available, why use the wrong math?"
It's difficult enough for GIS managers to keep current, but it certainly complicates the issue when GIS software vendors aren't current either.
About the Author: Eric Gakstatter
RSS
Become a Fan
Join our Network
Follow Us
Please send any technical comments or questions to our webmaster.