Good practice
_-_The_Noun_Project.svg){kind=small}
OpenStreetMap is a free project done by volunteers. Anybody can enter anything they wish. That said, a map works best when participants agree on a code of conduct. These "Good Practices" are guidelines that will increase the quality and value of our map data without any additional effort. Nobody is forced to obey them. There might be cases where these guidelines don't apply or even contradict each other.
Do correct errors
When OpenStreetMap is missing data or when things change in the real world, be bold, and edit the map to reflect the current situation.
Your additions can be refined or reverted when needed, so do not hesitate to edit the map.
However, be respectful to the work done by other mappers and consider consulting them especially when existing data is just tagged with unclear or undocumented methods or tags; often there is more than one way to interpret situations and mapping guidelines. Also be mindful when you remove data because finding or restoring removed data is harder than adjusting added data.
If you are a beginner, unsure or editing in a faraway location – feel free to contact other mappers and ask them to review your edits.
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.
Map what's on the ground
Sometimes there's conflicting information about, say, the name of a place. An old map might call it one thing, current maps another, and the place name sign something else. People using our maps (for navigation) won't care about the spelling in other maps, they need to find the names on local signs on the map and vice versa. The only exception to this could be obvious misspellings on signs like John-F.-Kennwdy Square. Assuming that people would intuitively look for the correct spelling, perhaps not even noticing the wrongly spelt name at all, it makes sense to correct these. See also: ground truth
Don't map historic events and historic features
Do not map objects if they do not exist currently, and do not map the location of historic events, because such features cannot be verified. If ruins are left (and thus verifiable), then map the ruins (for example using historic=ruins). Objects that no longer exist and historic events can be mapped on OpenHistoricalMap (see Open Historical Map).
Don't map local legislation if not bound to specific objects
OSM is a geographic database, not a legislational database. Legal aspects such as local traffic rules should only be mapped on specific elements (such as highways) insofar they are dependent on specific geographic features in the real world. For example, do not tag traffic rules on highways that apply by definition to all road segments in a country and that can not be overruled by traffic signs that may or not be present in the field, such as the blood alcohol limit for drivers or the legal age to drive a motor vehicle.
However, absence of a specific traffic sign or road surface marking can be sufficiently relevant to map. For example, the default legal speed limit can be entered as maxspeed=* to indicate absence of a different location-specific speed limit. In this case, maxspeed=* still provides valuable information relevant to the specific road. If the absence of the traffic sign would not have been tagged, data users can only guess whether the situation in the field is compliant to the legal default or that this road segment has not yet been evaluated by a mapper. Within the framework of the 
Vienna Convention on Road Signs and Signals, the presence of an intersection combined with the absence of a (repeated) traffic sign also means that prohibitory and restrictive signs placed before the intersection no longer apply beyond that point (unless the traffic signs are displayed with zonal validity).
Don't map temporary events and temporary features
Our map data is often downloaded and used offline on various devices for several weeks or months. For offline data to be useful, it should at least be expected to remain unchanged in the next few weeks when you map it. Certain events that happen in a regular pattern (like a weekly market) can be mapped by using different time tags.
Don't map for the renderer
- Main article: Tagging for the renderer
Draw things as they are on the ground. Do not enter incorrect data or remove correct data just because it will help a map renderer, a navigation system or some other data consumer which has problems with the correct data. They are continually improving, don't bend the data to make it look prettier, just be patient, try a different data consumer or report the issue to the data consumer it concerns (example for the Openstreetmap-Carto style).
Don't use name tag to describe things
- Main article: Names
The name tag should be used for the common name of a feature. It should not describe or label the feature. For example, it is incorrect to use name=track on a track road through a forest. Instead it should have the feature tag highway=track. If the track has a common name (like a street name), it would have a name tag too. If not, then there should be no name tag.
Don't map for the router
- Main article: Tagging for the router
Do not use inaccurate tags or distort data to influence routing navigation to your preferences. Familiarize yourself with best practices instead. Since routers are consistently improving, consider trying an alternative option or reporting any issues or improvement suggestions to the different routing projects.
Good changeset comments
- Main article: Good changeset comments
A good changeset comment should concisely and adequately describe an edit. You should do this out of courtesy to your fellow mappers, to avoid misunderstandings, and get mistakes fixed quickly. It makes your edits more valuable. It may even help you when you look back at your edits in the future.
Keep the history
- Main article: Keep the history
When things change in the real world, be bold, and edit the map to reflect the current situation. But be aware that OpenStreetMap can store the editing history of an element. You can help preserve this history by modifying the existing elements instead of deleting them and redrawing from scratch.
However, a single OSM element should not be used to store the history of multiple unrelated objects. See Don't mix the history for more information.
Before making significant changes to major objects, check their history.
One feature, one OSM element
- Main article: One feature, one OSM element
An OSM element should represent a single on-the-ground feature once and only once. Don't place nodes in identically tagged areas just to see an icon appear in the editor.
If you draw the area of an object that previously existed only as a node, remove the node or reuse it in the outline as described in Keep the history, then remove the tags from the node and add them to the area.
See the full article for notable exceptions to this rule.
Editing Standards
- Main article: Editing Standards and Conventions
Align aerial imagery before tracing
- Main article: Using Imagery
Aerial imagery will, regardless of source, have offsets to the real positions of objects on the ground. While this can be small enough to be ignored, it can be substantially more than typical GPS errors (>> 10 meters) and change over small areas (requiring re-adjustment). It is mandatory that you check this before moving existing OSM data, or adding more.
Potential ways to align and check alignment:
- existing GPS traces or high-precision POI data
- compare imagery with existing OSM data
iD, JOSM and Potlatch have tools that support imagery alignment.
Do not trace from outdated imagery
- Main article: Armchair mapping
Just because it is available doesn't mean that aerial imagery is up to date. Be sure to check that the existing OSM data you are about to change or delete is indeed older than the imagery you are looking at by checking the history and changeset comments of the object. The best is to only map areas that you visit and verify yourself (but doing the best isn't the case for strictly-armchair mappers).
Average out GPS-traces
- Main article: Accuracy of GPS data
The accuracy of the points in a single GPS trace may be out by several meters. This depends on many factors. If many traces are taken for the same road, the effect of errors in any one trace will have a much smaller impact on the average position of these traces. It's useful to upload all GPS traces to the server – even if they cover roads already in the database. This allows others to use your traces to average out the errors.
Keep straight ways straight
When there's a road that's dead-straight, draw it as such. That's done by just one line between two nodes without any nodes in between. Many roads are actually perfectly straight even though your GPS-track may not reflect this (Accuracy of GPS data).
JOSM, iD and Potlatch all have tools to straighten streets with intersections. That keeps our data slick and makes the maps look better. Having said that, if you have multiple GPS traces for a particular road and they all show a bend in the road, or you see the road's shape in an aerial photograph – then depict this shape in OSM.
Map curves with an appropriate number of nodes
Use a reasonable number of nodes to map curves and other non-linear features. There's no hard or fast rule about how many nodes should be used to map curves – you need to use your own judgment – but there should be enough so that the change in heading between successive segments of a way is relatively small – that is, the angle between adjacent segments should be closer to 180° than to 0°. Therefore, sharp curves require many closely-spaced nodes, while broader curves can be mapped with fewer, widely-spaced nodes.
Mark estimations with fixme
Sometimes it makes sense to map estimated positions rather than not mapping the object at all. But always mark your estimations with a fixme=* so you or somebody else will come back to it.
Don't over-use semi-colon separated values
Semi-colon value separator characters can be introduced into values, where the same key needs to take multiple values. This can be useful for putting lists of values into certain types of minor attribute tags, however, it should be avoided in more important top-level tags such as highway=*. In general, these special characters should not be over-used, since they detract from the simplicity of the tagging system and are therefore often generally rare and poorly supported by data consumers for top-level tags (whereas multiple values separated by semi-colon are generally well supported for tags that have a more list-like nature such as opening_hours=*).
Document your custom tags
- Main article: New Features
- Main article: Creating a page describing key or value
When you use tags that aren't on map features, give other mappers a chance to understand (and maybe adopt) them by documenting them in the wiki. Please do not use the map features section of the wiki for this (including all wiki pages whose name starts with Key: or Tag:), as these are the community-endorsed tagging recommendations reserved for well-established tags with significant usage. Instead, you should set up a proposed feature page or put the documentation on your user page or a subpage of it. Or mention the tag on a "Discussion" section of a wiki page. Setting up a proposal is the preferred method of documenting custom tags.
Don't remove tags that you don't understand
Sometimes you will come across elements with tags that have no meaning to you. This doesn't automatically mean you should remove them. They may have been added for a specific purpose. If you think they might be junk then try to contact the author. See also: Chesterton's fence on Wikipedia.
Don't remove objects that you don't need or like
Be brave in what you add but careful in what you delete. Someone added a catenary mast or a manhole? And you think it's stupid or unnecessary because it doesn't display on the map? Inaccurate mapping is not forbidden, but you certainly should not work the other way and remove details that someone else added. It is known that not everything is always needed by everyone, but you should not remove something just because you do not need it / you think it is stupid / the validator ordered it so.
See also
- Editing Standards and Conventions – Another set of recommendations on aspects of mapping.
- Organised editing best practice
- Tagging_samples – Tagging samples with actual photos.
- Category:Tagging guidelines by country – These country-specific wiki pages usually contain better explanations than the main wiki.
- Any tags you like
- Just Map
- Mapbox QA guide
- Limitations on mapping private information
- Good practice in OpenHistoricalMap