Accuracy, Datums, and Geospatial Data and other Updates
Plus GLONASS Update
If you were able to attend the webinar “Nightmare on GIS Street: GNSS Accuracy, Datums and Geospatial Data” held on June 20, thanks for attending. If not, you can view the webinar here. We had a world-class panel of experts discussing the nightmare of accurately combining different sources of geospatial data as well as on-the-fly datum transformations in the field when using high-precision GPS/GNSS receivers.
Let me apologize in advance if it seems like I’m “beating a dead horse” in writing about this issue. I intended to address the questions raised during the webinar. After addressing one of the first issues below (WGS-84), I expended my allocated space and energy. Rest assured I will publish answers to the other questions that were raised before and during the webinar.
Very few of the geospatial software vendors (GIS or surveying) are handling horizontal datum transformations correctly or in a manner that is easy for the average GIS operator to understand. The good news is that hopefully we’re raising awareness and some are responding, such as Carlson Software. Carlson recently released version 3.0 of their SurvCE surveying software for GNSS data collection. It includes a 14-parameter transformation from ITRF08/WGS-84 G1674 to NAD83/2011. You might want to watch the four minute video below demonstrating the transformation process in SurvCE 3.0. You’ll see the difference after the transformation is about two tenths of a foot (~6cm). If I were to guess, I would say majority of the difference after the transformation is the tectonic plate movement that is unaccounted for. Reconciling the tectonic plate movement is difficult because you need to have an accurate velocity (movement) model for the software to reference. In some geographic areas, the movement is minor (1mm per year) while other geographic regions move 6cm per year or more. Lastly, what if there’s a major earthquake such as the 2011 earthquake off the coast of Japan or the 2010 earthquake off the coast of Chile. During those events, the ground shifted many meters in some cases.
Just a reminder from my last article on this issue in Geospatial Solutions, here’s a rough tectonic plate velocity model from the University of Kentucky:
I’d like to spend a little time on the subject of the WGS-84 reference frame. It’s a term that’s used and abused a lot, including by myself on occasion.
Taking a Look at the WGS-84 Reference Frame
First, let me begin with the statement that WGS-84 should not be in your geospatial vocabulary. In fact, I’ve been corrected in the past that it is actually a reference frame rather than a datum, but you’ll likely see it listed as a datum in your geospatial software.
WGS-84 is not something you’ll find physical marks on the ground that you can use to verify GNSS equipment performance. WGS-84 is defined by the U.S. National Geospatial-Intelligence Agency (NGA), which serves the U.S. Department of Defense and the U.S. Intelligence Community. In other words, one of its roles doesn’t include serving the civilian community. Originally, the accuracy of data referenced to WGS-84 could not be defined more accurately than a couple of meters. In fact, the definition of WGS-84 has changed several times over the years, usually without your knowledge, and usually not accounted for in the geospatial software you are using.
Originally (1987), the Department of Defense transformation values between WGS-84 and NAD83 (dX, dY, dZ) were set to 0, which led people to believe they were considered the same. A footnote that was largely ignored is that the standard deviation of the WGS-84 to NAD83 transformation values was ~2 meters (Doyle, D., 2013 email). The bottom line is that if someone hands you a GIS dataset and says it’s referenced to WGS-84, an alarm should immediately sound in your brain prompting you to query the presenter of the data. When and how was the data referenced to WGS-84? Likely, they won’t know the answers to the questions you ask. In that case, you have no choice but to tag the data as only accurate to two meters, at the very best. Of course, if it was data collected by a consumer-grade GPS unit, the accuracy is likely much worse.
The history of WGS-84 is as follows:
——————————————————–
WGS-84 (Original) – 1987
Aligned with NAD83/86 (original) but standard deviation of the transformation was +/- 2 meters.
——————————————————–
WGS-84 (G730) – 1994
Aligned with ITRF91 (epoch date 1994.0). A significant shift took place with this adjustment.
——————————————————-
WGS-84 (G873) – 1996
Aligned with ITRF97 (epoch date 1997.0)
——————————————————-
WGS-84 (G1150) – 2002
Aligned with ITRF00 (epoch date 2001.0)
——————————————————-
WGS-84 (G1674) – 2012
Aligned with ITRF08 (epoch date 2005.0)
——————————————————-
As you can see from above, if someone hands you a dataset and states it’s in WGS-84 format, it begs the question of “which one?”, not unlike the same question you should ask if someone states a dataset is “NAD83”
As I mentioned above, while the 14-parameter transformation to move from one datum to another is not commonplace in geospatial software yet, but it’s gaining traction and it’s not difficult to implement. The trickier, and more difficult variable to reconcile is the tectonic plate movement. It may not seem like the earth you stand on is moving very much, but years of movement can add up when you’re using GNSS equipment capable of 1-2cm accuracy.
Example: Let’s say you’re using OmniSTAR’s HP real-time correction service. The accuracy of that service is rated at 10cm horizontal 2DRMS. OmniSTAR informed me that their system is referenced to ITRF08 using the current epoch date (eg. the date you collect the data). Let’s say your GIS basemap is referenced to NAD83/2011 (epoch 2010.0), which is the most current version of NAD83 (I apologize to non-US readers for this example, but you likely have a similar situation). The 14-parameter transformation will transform your data from ITRF08 (current date epoch) to NAD83/2011 (current date epoch), but then you have to account for the tectonic plate movement from current epoch date (assume 2013.5) to 2010.0. That’s 3.5 years of crustal movement. The tectonic plate movement in some parts of the US are only 2mm/year so 3.5 years x 2mm/year = 7mm. Since OmniSTAR’s HP service is 10cm, you could say that 7mm of plate movement is below the noise floor. However, let’s say you’re in California where the tectonic plate movement is 5cm/year in some places. Reconciling the tectonic plate movement in that environment becomes important when you think about 3.5 years x 5cm/year = 17.5cm!
So, when populating your GIS database, especially with “high-accuracy” data, it’s important to understand not only the datum the incoming data is referenced to, but also the epoch date the data is referenced to. An answer of “WGS-84” is not good enough and probably not accurately represented in the geospatial software you’re using. More than likely, ITRFxx is more accurately defined in your software, if it is present.
Regardless, WGS-84 should not be in our geospatial vocabulary, or at least be quickly fading.
By way of background, the ITRF (International Terrestrial Reference Frame) Center are funded by the Institut National de l’Information Géographique et Forestière (IGN), hosting the IERS ITRS Product Center, and partly by the Space Geodesy Research Group (GRGS).
————————————————————————————————————-
To illustrate the effect of tectonic plate velocities, please view the following two images:
The first image shows the the difference between the latest definitions of WGS-84 (G1674)/ITRF08 epoch 2005.0 and NAD83/2011 epoch 2005.0. Notice the smooth contour lines. This is using the 14-parameter transformation.
However, the correct US definition of NAD83/2011 is referenced to epoch 2010.0, a full five years later than the first image where it was referenced to 2005.0. Notice the dramatic effect of the tectonic plate movement in the western part of the US. In this case, the 14-parameter transformation was used as well as the velocity model to estimate the tectonic plate movement.
This illustrates that increasingly, geospatial data consumers will need to consider that “time is of the essence” when combining geospatial datasets.
GLONASS Rocket Crash
On July 2, 2013, a rocket carrying three GLONASS satellites crashed shortly after lifting off from its launch pad in Kazakhstan’s Baikonur cosmodrome. It’s the second launch crash for GLONASS, costing Russia six GLONASS satellites in the past three years. According to several sources, the cause of the July 2 crash was blamed on incorrectly installed angular velocity sensors. Despite the loss, GLONASS still has a full constellation of 24 satellites and, since GLONASS is largely used as an augmentation to GPS, people using GPS/GLONASS receivers should experience no change in performance.
Rumors are circulating that this crash signals the beginning of the end of the GLONASS program, but I don’t believe it. Although this crash is a serious blow to Russia’s space program and will certainly set back the GLONASS program due to the nature of the crash (at the launch pad), I believe that GLONASS is here to stay.
GPS suffered a major setback when, in 1986, the Space Shuttle Challenger exploded 73 seconds after lift-off because the space shuttle was the planned launch vehicle for GPS satellites. Subsequent launches were shifted to the Delta II rocket, causing a two-year delay in GPS satellite deployment. However, GPS never subsequently strayed from its course and for nearly three decades has been the so-called gold standard of satellite-based positioning, navigation, and timing.
с надеждой (here’s hoping) GLONASS can similarly recover its momentum and progress as planned.
Update: On July 9th, Ria Novosti reports that Russia will launch two GLONASS navigation satellites later this year to make up for the loss of three satellites in the recent Proton rocket explosion after launch from the Baikonur space center in Kazakhstan, according to a senior space industry official.
“We are planning to launch two satellites from the Plesetsk space center [in northern Russia] to replenish the GLONASS orbital grouping following the recent Proton-M accident,” said Nikolai Testoyedov, the head of the Information Satellite Systems (ISS) company, which manufactures satellites for the GLONASS project.
The first GLONASS is scheduled for launch in the beginning of September, and the second at the end of October, according to Testoyedov. The official added that both satellites will be launched on board the Soyuz carrier rockets, which has proven to be more reliable than ill-fated Protons.
A group of 29 GLONASS satellites is currently in orbit, with 24 spacecraft in operation, three spares, one in maintenance, and one in test flight phase, according to Russia’s space agency, Roscosmos.
Join me on the NSPS Radio Hour – Monday, July 22, 11:00am US Eastern Time/8:00am Pacific Time
I, along with Michael Dennis of the US National Geodetic Survey, will be guests on the National Society of Professional Surveyors (NSPS) radio hour talking about interesting geospatial data and GNSS subjects. You can tune in live or download the mp3 audio recording onto your smartphone or mp3 player. Feel free to send me an email ahead of time if there’s a particular subject you’d like to hear us discuss.
See you next time.
Follow me on Twitter at https://twitter.com/GPSGIS_Eric
WGS84 should not be in our vocabulary except for this tiny detail: All GPS receivers work in WGS84, and therefore any Latitude Longitude and Height delivered by a GPS receiver is in WGS84…
Saying WGS84 doesn’t tell anyone anything from a data standpoint. Which version of WGS84 is your data in? On the other hand, now that the latest iteration of WGS84 is aligned with ITRF08, it make a lot more sense to use ITRFxx. That is the point I was trying to make.