Limitations
This page attempts to document the limitations of OpenStreetMap.
Limitations imposed by policies
License
All data in OpenStreetMap must be licensed under the Open Database License (ODbL).
OpenStreetMap is intentionally very strict about this by taking a whiter than white approach. For example imports are only allowed if the source has given OpenStreetMap explicit permission to use the data.
Whoever is using OSM data is obligated to follow its license, that may put some limitations - for example typical use of OSM data will require clearly crediting source visible to typical user.
Privacy
OpenStreetMap does not map where individual people live, how to contact individual people or who owns which building or plot. Private backyards are also not mapped in detail. For the full policy, please see Limitations on mapping private information.
Not everything is mappable in OSM
While OpenStreetMap does not have any notability requirements, there are some limitations very much agreed upon:
- features that no longer exist should not be mapped in OpenStreetMap (but they may be mapped on the Open Historical Map)
- temporary features are not mapped because our data is often downloaded and used offline for several weeks or months
- certain events that happen in a regular pattern, like a weekly market, can be mapped by using different time tags
- intermittent features, especially lakes and waterways are mappable with intermittent=yes
- amenities or rooms that are inaccessible to the public are not mapped (e.g. televisions, washing machines, showers or toilets in private apartments/houses).
- Certain useful but quickly changing data like live traffic info is out of scope of OSM
Verifiability
- Main article: Verifiability
OSM data should, as far as is reasonably possible, be verifiable. The principle applies to tags and other aspects of data representation and essentially means another mapper should be able to come to the same place and collect the same data ("verify" the data you have entered). This principle excludes hypothetical or opinionated data like personal ratings and reviews.
For mapping fictional features one may use Geofiction - though they have own set of limitations and rules.
Any tags you like
OpenStreetMap lets you use any tags you like. While this is very much the absence of a limitation it does introduce some possible difficulties in using OpenStreetMap data: it can be tricky to discover how to extract interesting data, and this can suddenly break because people started using a new tagging scheme and deprecated old one.
Tags can contain accidental typos. Tags do not have to be documented anywhere (although documenting your custom tags is very much recommended). New tags do not need to be discussed with anyone before being used (but you are very welcome to do so in the forum, the mailing list or even by creating a proposal). Even deprecated tags can still be added, although you should have a good reason for doing so because tags are usually only deprecated if there is a very good reason for doing so.
Limits on editing
Putting fictional, low quality data is vandalism and unwanted. The same goes for damaging valid data, insulting or harassing others and so on.
Performing edits without review can be done, but only when following Automated Edits code of conduct
If someone employs paid mappers or controls what others are mapping - then they are obligated to follow Organised Editing Guidelines.
Following Import/Guidelines is mandatory while adding data from external sources.
Permanent limitations
The following limitations are inherent to the mission and nature of OpenStreetMap and will likely stay with OpenStreetMap forever.
Accuracy & completeness
- Main articles: Accuracy & Completeness
The infrastructure in the world is ever-changing. Roads, houses, bridges and railways are build, roads get closed, houses get torn down, etc. Businesses and shops open for the first time, change their name, opening hours and contact details and eventually close down. Since OpenStreetMap relies on volunteers to update the map, if nobody updates OpenStreetMap when the world changes, OpenStreetMap quickly becomes out of date. You are more than welcome to get involved!
The accuracy of OpenStreetMap can be harmed by vandalism.
OpenStreetMap is missing basic data in many regions. The completeness of OpenStreetMap is difficult to measure due to licensing issues. Since OpenStreetMap allows an incredibly high amount of detail to be mapped (down to the individual tree), it will never be complete.
API stability
The editing API is subject to change and break compatibility over time.[1] While OpenStreetMap does not have a formal API stability guarantee[2], the API has become quite stable over the last decade. The last major version change was in 2009, since then v0.6 has been used with only a few minor breaking changes that have been coordinated with API users. The deprecation period of API features will generally be several months.[3]
Current limitations
The following limitations are limitations to the status quo and may be resolved in the future.
Software
In many cases OSM data is good enough for some purpose but remains unused as there is no software that can do this. You are welcome to help with improving existing one or create a new one!
The limitations of the https://www.openstreetmap.org/ user interface are documented at /User interface.
No persistent IDs
- Main article: Permanent ID
Every element in OpenStreetMap has a unique numeric identifier. While these IDs don't change without reason, there are situations where they will change. Unlike Wikidata (where IDs are stable) or Wikipedia (where renaming an article will usually at least leave a redirect behind), OpenStreetMap doesn't have IDs that are guaranteed to be permanent.
The best current workaround is to link Wikidata identifiers via wikidata=*, however the majority of things in OpenStreetMap does not meet Wikidata's notability policy.
No area datatype
- Main article: Area/The Future of Areas
The OSM data model currently lacks a dedicated data type for areas. Instead, polygons are represented as either ways or relations. Each tool working with OSM data therefore uses its own set of rules to guess whether a particular way represents a line or an area. Because of #Any tags you like, any such rules must be incomplete. Making areas a proper part of the OSM data model (as is being discussed for future updates to the OSM data model) would lead to a consistent interpretation across applications, enable the API to prevent broken areas from being uploaded, and may eventually lead to support for partial downloads of very large areas.
Tags are just strings
The data model of OpenStreetMap is very simple, in particular tags are just strings mapped to other strings. This leaves many things to be desired:
- Tags are not directly linked to a specific explanation of the tag, instead the meaning of a tag is established via community consensus, which can not only vary from region to region but can also change over time. Sometimes it is not clear what is meant by a tag, see Homonymous keys and #Any tag you like. Sometimes tags are used in a different way than they are usually used, see also Counterintuitive keys and values. Sometimes different tags have the same meaning, see also Synonymous tags.
- there is no uniform way to express the absence of a value, so other tags like nohousenumber=* are necessary
- there is no uniform way to express that a value exists but is unknown, so other tags like artist:unknown=* are necessary
- there is no uniform way to express multiple values, most tags use semicolons, however some like turn:lanes=* use other characters, sometimes multiple values are also expressed via multiple namespaced tags
- values cannot have an associated language, so this has to be expressed via a key suffix, e.g. name:en=*. This does however lead to ambiguities, e.g. is note:bin=* a note in Bini or a note about the bin=* tag?
- in general tags cannot be qualified in a way that data consumers can know which tag qualifies which tag without knowing about the specific tags that are being used