Verifiability
The concept of verifiability in OpenStreetMap essentially means that another mapper should be able to come to the same place and collect the same data ("verify" the data you have entered). OSM data should, as far as is reasonably possible, be verifiable. This is a good practice guideline covering all mapping activity and a policy governing choices we make about which tags are used and gain acceptance, and other aspects of data representation.
What is verifiability?
At the core, "verifiability" is that everything you do can be demonstrated to be true or false by other mappers – the latter hopefully implying that there has been a change on the ground that needs mapping.
- We apply this not only to the mapping data itself, but also to the way in which we record it – the geometries, tags and values we use to describe objects on the map.
- A tag/value combination and geometry is verifiable if and only if independent users observing the same feature would make the same observation every time.
- Objective criteria, clearly documented on the wiki, help to make tagging verifiable by individual mappers.
Examples
Objective criteria
It is desirable to have objective criteria for a user's tagging to be verifiable. This principle applies to any observable characteristic, be it numerical or descriptive.
For example, buildings come in various sizes. Two users look at a building to establish its height. One comes back with height=tall, the other with height=average.
Without further definition of those values, a third user would be unable to verify the correct value, so "tall" and "average" are unverifiable values for height=*.
Another user measures the building as approximately 17m tall. This is a factual observation which can be definitively shown to be true or false, and is therefore verifiable.
Improving verifiability by documenting values
Clearly documenting tags on the wiki always helps with verifiability.
This means defining the meaning of values, and nailing down exactly how a mapper should go about measuring or deciding upon a value.
For instance, we could tag waterways as "big" and "small", but two users may not agree on what this means.
Instead, we use "river" and "stream", replacing general adjectives with more specific terms. However, different people may have different ideas of a "river" and a "stream". Instead, we use a testable definition.
The test used to distinguish a river from a stream is that "an active person should be able to jump over" a stream. This definition is still somewhat subjective, but restricts the range of variation.
Verifiable geometries
The position of a node, way or area may be non-verifiable if the geometry cannot be demonstrated to be true or false by another mapper.
Some features which are not verifiable as ways or areas can be mapped as a node near the center of the feature.
For example, a settlement such as a place=hamlet often lacks verifiable borders. Hamlets in farming areas often have scattered houses and farms extending outward for some distance. In this case the approximate center of the place may be well-known, but the outer limits are not clearly determined, so mapping as an area is not verifiable.
Statistical properties
Numerical properties like height=* and width=* are often verifiable, but only if they are locally measurable. In contrast to that, statistical properties often cannot be verified by individual mappers.
For example, the use frequency of a road in cars/hour is not a practically verifiable quantity, since determining it would require long-term observations which are not realistic for mappers to do.
It is not sufficient if something is verifiable in theory. It must be practically verifiable in everyday mapping.
Subjective opinions
Subjective opinions, reviews or evaluations of places or businesses are not verifiable by other mappers, because other observers might have a different experience. You should not copy such values from rating platforms.
The exceptions are hotel and restaurant categories or stars that are awarded by recognised tourism boards and based on objective criteria.
Examples of what not to map:
- This restaurant serves very delicious food.
- This hiking trail is too dangerous to walk on.
- This area is dangerous at night.
- This hotel is noisy.
Problematic tags
There are a number of tags in use in OSM that are problematic regarding verifiability. Some are longstanding tags which are widely accepted and used despite the problems.
Highway tags call upon the mapper to make a classification. The difference between a highway=trunk and highway=primary may be unclear to some mappers, but has been made more verifiable by documenting in the wiki, even to the extent of explaining how mappers in different countries might apply the tags based on local road signage.
Meanwhile, other tags have been invented which caused controversy because of poor verifiability. An example of this is smoothness=* (see Harry Wood's blog for an entertaining recap of the discussion).
A positive outcome of the debates has been careful documentation of the tag values and how they should be applied by mappers. But tagging concepts which require such subjective judgements remain problematic in terms of verifiability.
Planned features
Planned roads, rails or buildings are not objects that can be seen on the ground, so the source of the data must be specified each time. Information about the source of the data is best added in the source=* tag as the tag of the object in question, because the source=* added in the changeset, can get lost when someone, for example, divides the planned road into pieces.
If you have to add a planned feature, try to add only those whose construction will start soon. For example a plot of land for a road is designated and a construction project and exact route is available.
When you can add:
- there is information on the site about future construction, but construction has not yet begun
- the first construction work on the site has already begun, but there is no track of a road or rail yet, but the exact course of the route has already been determined in the project
When not to add:
- when you've read an article in the media that "track construction is planned," etc.
- when you've read in the newspaper that "a tender has been awarded," "a contractor has been selected," or "construction is starting" (note the present tense, which often appears in the press, but refers to the future).
- there are several planned variants of the road route
For various reasons, many plans are never implemented and remain in the planning stages. Mapping proposed features is problematic, controversial and only real plans should be mapped, if at all.
Flagging
If you find a tag documented in this wiki that you believe isn't verifiable, you can flag this using the Verifiability template like so: {{Verifiability}} and open a discussion under a new section in the wiki tab named Talk. Explain why the tag is not verifiable.
Community viewpoints
The principle of verifiability is often cited in community discussion fora:
We have a general rule that says stuff must be verifiable. General rule doesn't mean "no-exception-made set in stone", but it means: You need a very good reason for mapping something not verifiable. Such a reason could be that the data is of a relatively high usefulness to relatively many people, or that the data is useful for mappers in their work.
— Tagging mailing list, Aug 2022, "RFC: Removal of Eruvs from OSM, and further boundry=religious".