Paul Ramsey gave a great 5min speech at Where 2.0 - making the point that data measurements, maps and deductive GIS processing heavily relies on a stack of relative measurements.
Atanas Entchev condenses Paul's major points into three sentences:
- there is no "perfect" accuracy
- all measurements are based on other measurements
- relative accuracy matters
... adding up with Mike Popoloski's posts on positional accuracy (1, 2).
This post is a remix and extension to Mike's wording, adding more opinion and some facts.
Data doesn't exist in a Vacuum
„Data doesn’t exist in a vacuum. Most data is positioned relative to other data - which is positioned relative to other data ... asf.“ [Paul Ramsey]
Paul shows a 40 year old map of downtown San José (left picture), contrasting it with today's aerial/sat imagery (right picture):
„GPS has an error radius of 10m - 60ft. (...) And 40 years ago, when they built this map - how did they know where things were? Relative measurement (...) a chain of quality." [Paul Ramsey]
One data stack built on another.
Error coming with data stacks also is stacked - even if you actively maintain an error model over time. Once the error is in, modelling just describes it. You better might tell your user.
Each of those cases has a valid use case. The San José city map smoothly guided a human to a destination. It depicts reality and relative positions.
The sat image shows the pixelised whereabouts and leaves lots of room for subjective interpretation. Just pixels ... fair enough.
Mismatches come as payload.
Mike Popolski gives a real life example of someone working with a mix of many data stacks, suddenly identifying an obvious error or mismatch:
Meanwhile it turns out that the data they used to base their decision on is off by 50 feet (...) and the apparent violation doesn’t exist.
A common reaction of a product manager is an angry call the likes of "your data is faulty", "doesn't match", "can't use it without manual correction". This is true and it isn't - both the same time.
For each GIS data collection project (...) I must determine acceptable tolerances and uses for the data. Unfortunately many GIS’s are populated with data without these considerations. Instead data is downloaded from the cheapest data provider or collected with the lowest cost equipment and/or the lowest cost labor without consideration of the consequences.
The trained GIS expert, data collector or database manager probably also would call, just asking for the error model or the inherent accuracy and thresholds of the data in question.
So how do you define accuracy?
In a GPS/GIS setting, accuracy can be defined as how close the GIS feature is to its true location on the planet.
But how can one find the true location of any feature? Go out to the field, pack your Trimbles and all the best gear money can buy - go out, do field research and measure every single spot to its true GPS-location. The more you spent on precision (gear, time, people, opportunity), the more precise your measurements get. Go out and drive every single road on this earth, map every feature. If you're done - start over.
It'll eat up resources faster you can replenish.
Look good or be accurate?
Here comes the important stuff, in Mike's words:
Does the true location really matter? (...) people often don’t want “accurate” data, they want data that looks good. By looking good I mean that the data agrees with the base mapping that is currently being used. So even if the base map is of poor quality as long as the other data overlays nicely everything else doesn’t matter.
That's the sweet spot and the hard part.
Once you are invested into processes, databases, toolchains and people to achieve a maintainable, professional level - you'll likely stick to it.
If reality can't be measured accurately, adjust its representation to fit your use case.
(As) most people are now using orthophotos as their base map, (...) It seems hard for people to understand (...) that everything we look at on a map has an error associated with it and that it's ok for a +/-1cm point to be "off" 80cm when the base map itself is +/-1m.
Some features may have more error or lower accuracy than others, even the base map itself.
Here's two examples illustrating the case:
Visually, we instinctively trust the aerial/sat image - as pictures are supposed to show the truth.
The colored vectors describe roads and pathes more or less correctly. There's some omissions, offsets and strange connections.
If the left situation was transferred into a PND or onto any smartphone app, the user won't recognize an offset - as the app likely will guide correctly through the park. Different for the right picture: you'll bump into a wall.
Which of those layers is correct?
Is the building on the right side still there or already removed? You won't be able to tell without field research or the latest, most expensive ortho photo - but you won't note anything without matching different data sets.
