Recently there have been a few posts that have exposed the “quality” of Google Earth, Bing Aerials, Esri Background Imagery, and others. One post by Brian Murphy on December 6th does an excellent job describing the nature of these imagery sources. He describes not only the pain points of having a hodgepodge of image qualities and sources, but he shows the dramatic effects on quality and accuracy when mosaicing or stitching these images together. The results can lead to dramatic offsets and misalignment. I encourage geospatial professionals to read through his informative post here.
Brian’s post got me thinking. Who do you trust? I am Roger Schulz, a Trimble Certified Trainer, working for Frontier Precision. I work with mapping grade Trimble GNSS solutions (submeter to cm). Accuracy is always at the forefront of my mind, but this may not be the case for many other GIS/geospatial professionals. It is natural to question the quality of the data you or your field team captured. Even when you check your workflow time and time again, it is easy to let doubt creep in. I cannot count the number of tech support calls that have come in with customers scratching their heads, frustrated and confused saying “no matter what I do, I can’t get my data to line up with “BLANK” (insert imagery source). The dialog generally continues to include that something is wrong with the data collector. The trouble is their data is correct, the source they are comparing to is flawed. However, proving this can be challenging.
I have also been a victim of doubt in my data at times, and I must prove to myself that what I am doing is correct. Let me take a minute to share one such case.
Just last week with Brian’s article fresh in my mind, I led a Training class in Bismarck, North Dakota (Frontier Precision Headquarters). The training class had one major objective, learning how to properly capture high accuracy field data and produce a deliverable from the data. For this class we captured data using Trimble Geo 7X units. We had a mixture of both decimeter units and centimeter units. The data used as an example, was captured using a decimeter unit. The data was captured autonomously and was later postprocessed against the local Bismarck CORS base station using an ITRF00 or WGS 84 equivalent reference position. Some of my students were using Google Earth as a reference for their data so we ran a test export to a KMZ file.
Please note the dataset is limited; it was captured to learn data collection techniques and processing practices and was not intended to be an accurate representation of what the true earth shows. However, it does work to illustrate a critical point. Who do you trust?
The data was captured by one of my students and I got her consent to share it, and demonstrate to others that your GNSS data is the trustworthy source. Figure 1 looks great. The edge of the side walk looks to line up well and the point data also is representative to the positions we captured as a group. (the intersections of concrete, the location of a post and the marks on the sidewalk)
Most users at this point would be satisfied, walk away and never question the data. In this case they would have a good reason, everything looks to line up great. However, this is not the first class I have taught in Bismarck at this facility. The data did line up, and that shocked me.
Earlier this year I conducted the same training in Bismarck and when we got the export portion of the class, nothing “seemed” to line up with the Google Earth. I was prepared for the similar results and a tangent lecture of “Trust your Trimble, not Google”, but to my surprise it actually looked good. Checking the publishing date of the image I noticed it had been updated since the last training. “Ah-ha!”
Thankfully Google allows us to view historical images that they had published. Below are the results of the same data over the previously published image. Notice how everything shifts 3-4 feet.
To further confuse things, coincidentally, this happens to be the same shift distance and direction that occurs when data is exported or processed in the wrong datum. Google earth uses a standard Lat/Long, WGS84. If through the course of post processing, export or real-time correction a NAD 83 (2011,2007,or 1996) is accidently applied to the data, it will be falsely shifted. In this portion of North Dakota, the shift is about 3.5 ft (about 1.1m). It also happens to be in the same direction as the coincident image shift we see in Google Earth. So, data with a false datum shift would falsely appear to plot correctly above a bad image from google. Below are both images side by side with the same data to show the impact of the bad image compared to good data.
As a user, if you were to believe that because your data is (or is not) lining up with Google Earth, the quality of your data can be deduced, you might find yourself mistaken. Remember first and foremost, trust your data. Next verify your base map imagery before trusting in it. Finally, remember to shoot control within your data set.
As if this is not bad enough, I continued through some of the historical data, and the image from 2012 shifts in the complete opposite direction. I only throw this up there to further hammer home my point that verifying the source, quality and capture method of your background imagery is extremely important. Just because your data does not appear to line up does not mean your data is bad, or wrong.
Trust your Trimble.
For further clarification and information on this and related topics see our support note on data not lining up.