A 2.672Mb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE
Happy 2017 everyone–May all of your ground points be last returns!
I recently attended a transportation conference and sat in on a talk given by some GIS graduate students. The subject of the talk was generating predictive driving data based on real time inputs from GNSS-equipped cargo trucks. The idea was to improve transport efficiency over the monitored segment (about 40 km) by using analysis of driving habits and providing corrective feedback.
The talk was rather interesting, with a lot of discussion of the real time data collected by GNSS on the trucks, the transfer of data and other factors. The base map being used was Google Maps because that was the "free" data that was available and, as a bonus, it had elevation data. The elevation data were useful because part of the analysis was the efficiency with which hills were being traversed. There was an analysis section that discussed the track deviations from the road centerlines and the probable causes. Methods were suggested for improvements in future studies. Mind you, this was a funded project with a lot of hardware purchased and installed. As I say, it was rather interesting. The only criticism I have is that the design and conclusions were mostly wrong!
This made me think about debugging software (something my company, unfortunately, has to do a lot of!) or automobile repair. The two topics of concern (there are probably others) here are proper Design and Root Cause Analysis.
Proper design means that you have thought about the impact of every single major design decision you are making. In the student’s case, a number of design errors existed. The fundamental problem with the experiment was that absolutely no errors were predicted and no error budget was established. The Google map data was taken as truth and errors were computed relative to these data. No attempt was made at establishing the veracity of the base map data. There was no experimental design that dictated the necessary accuracy of the GNSS on board the trucks. This, too, was assumed error free.
Of course we all know that this is not an appropriate way to proceed. While data from satellite imagery is fantastic for many purposes, accuracy is not one of them. An example is illustrated in Figure 1. The green top of rail lines were extracted from sUAS data that has a planimetric accuracy of 4 cm (relative to a base station which, in turn, had 3 cm planimetric accuracy with respect to the CORS network). The red lines were extracted from Google satellite imagery. Measuring the difference yields about 60 cm (~2 feet) of error relative to the reference. Pretty darn good for satellite imagery but not quite autonomous navigation grade!
The point here is not that Google imagery is not as accurate as RTK drone data; it is that this was not even investigated in the researcher’s experiment. A second consideration was that not only did they not know the type of GNSS being used on the truck, they had no error budget for this component.
The researchers expected their truck GNSS tracks to be centered on the Google map. Of course, they were not. In some areas they were off by 2 or more meters. A long discussion section followed about the cause of the discrepancies ranging from the dynamics of GNSS in curves to solar storms and so forth. Of course, the primary error was they were using L1 only GNSS and the base ortho was probably off by a meter or so.
The cautionary tale here is the assumption of truth. The base map and the GNSS were simply assumed to be true. This led to completely erroneous conclusions regarding the fact that most of the time, the trucks did not appear to even be on the road.
Now this is a blatant example whereas most diagnostics are much more subtle. For example, I am now constantly seeing sUAS accuracy being reported with respect to image identifiable check points whose error relative to the network is assumed to be zero (which, of course, cannot be the case).
All processes require a careful plan and, when analyzing results or defects, a Root Cause Analysis. What we often assume to be the cause of a problem is simply another symptom layered on a more deeply rooted primary cause. Fixing the symptoms without knowing the cause is commonly called "shade tree mechanics!" Till next time, keep it between the ditches!
Lewis Graham is the President and CTO of GeoCue Corporation. GeoCue is North America’s largest supplier of LIDAR production and workflow tools and consulting services for airborne and mobile laser scanning.
A 2.672Mb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE