From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Verifiability
· Afrikaans · Alemannisch · aragonés · asturianu · Aymar aru · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · bamanankan · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · Latina · latviešu · Lëtzebuergesch · lietuvių · Limburgs · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tagalog · Tiếng Việt · Türkçe · Türkmençe · Vahcuengh · vèneto · walon · Wolof · Yorùbá · Zazaki · isiZulu · српски / srpski · авар · Аҧсшәа · башҡортса · беларуская · български · қазақша · Кыргызча · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · भोजपुरी · मराठी · संस्कृतम् · हिन्दी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 中文(繁體)‎ · 吴语 · 粵語 · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް
Vernier calipers.svg

Verifiability is an important concept to OpenStreetMap. OSM data should, as far as is reasonably possible, be verifiable. This is a good practice guideline covering all mapping activity, and also by virtue of common sense, this has become a policy governing choices we make about tags to use (and which tags gain acceptance)

What is Verifiability?

At the core, "verifiability" is that everything you do can be demonstrated to be true or false - 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 tags and values we use to describe the attributes of objects on the map. From a given scenario, a tag/value combination is verifiable if and only if independent users when observing the same feature would make the same observation every time. For a user's tagging to be verifiable, it is desirable to have objective criteria for tagging. This principle applies to any observable characteristic which is a matter of fact, be it numerical or descriptive - a concrete road surface, a red brick building, etc.


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 sets up an experiment and determines that the building is approximately 17m tall. This is a factual observation which can be definitively shown to be true or false, and is therefore verifiable. As such, recording building heights as numerical values is clearly preferable over the more vague 'average' / 'tall' values.

Improving Verifiability by Documenting Values

One thing which always helps with verifiability of tags, is to clearly document them on the wiki. This means defining the meaning of values, and nailing down exactly how a mapper should go about measuring or deciding upon a value, and covering awkward edge cases.

For instance, consider waterways. Someone may make a distinction between wide ones and narrow ones. So, someone may choose to call these "big" and "small" waterways. Unfortunately, two users may not agree on what makes a waterway "big" or "small", and this is aggravated by using relative adjectives. Someone suggests that instead of "big" and "small" waterways, we use "river" and "stream". This has narrowed the definition by replacing general relative adjectives with names that people know. However, people may have vague mental images of the difference between a "river" and a "stream", and these may be difficult to reconcile. This can be done by imposing a testable definition. This need not be perfectly objective, as long as it is not entirely subjective. 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. Other water features have tests based on observable facts - e.g. the difference between a weir and a dam is that a weir is designed for water to flow over it.

Subjective opinions

Do not tag individual subjective or hypothetical opinions, reviews or evaluations of objects or businesses (e.g. "poor service in this hotel" or "good meals in this restaurant") as they are not ground-verifiable and other observers might have a different experience. Also, do not copy such values from rating platforms that collect such opinions. The exception are hotel and restaurant categories or stars that are awarded by recognised tourism boards, based on objective criteria, or based on association memberships.

Problematic tags

There are a number of tags in use in OSM that are problematic regarding verifiability. Some are very longstanding tags which are widely accepted and used despite the problems. Let's look at some examples.

We have highway tags which 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 much 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. The same has been attempted for distinguishing highway=unclassified and highway=residential (and other such low level highways) but, in fact, mappers often struggle to make the distinction. Despite concerted efforts to document the application of these tags and provide examples, these tags (or the distinction between them) is actually fairly unverifiable.

Meanwhile, other tags have been invented more recently and have caused controversy because of their poor verifiability. A popular example of this is smoothness=* (see Harry Wood's blog for an entertaining recap of the discussion). Other examples include trail_visibility=* and sac_scale=* (discussion at Talk:Proposed_features/Hiking). A positive outcome of the debates has been improved careful documentation of the tag values and how they should be applied by mappers but, nonetheless, tagging concepts which require such subjective judgement remain very problematic in terms of verifiability.

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 chapter in the wiki tab named Talk. Expose your arguments on why this tag is not verifiable.