Good practice
OSM is a free project done by volunteers, anybody can enter anything he likes. But like all means of communication a map works best, when all participants agree on the same code of conduct.
This page lists a few general rules that will increase the quality and value of our data without any additional effort. Nobody is forced to obey them. Neither will it ever be an aim of OSM to force any of its mappers to anything. There also might be cases where these rules just don't apply or contradict each other.
Don't map for the renderer
Draw things the way they are on the ground and don't care what the renderers make out of it. They are continually improving, don't bend the data to make it look prettier, just be patient.
One feature, one OSM element
Don't place nodes in identically tagged areas just to see some icon appear on the map. The renderers will display icons on areas as well and there's no need to have every parking-lot, soccer-ground etc. twice in the database.
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. Some roads are perfectly straight even when your GPS-track might think differently.
Potlatch and JOSM both 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 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 bends with an appropriate number of nodes
Ensure you use a reasonable number of nodes to record bends and other features. There's no hard or fast rule about how many nodes should be used to map a bend in a road - you need to use your own judgment - but there should be enough so that the angle between successive parts of a way should not be too large (e.g. shouldn't be close to 90°). This means that on sharper corners - the nodes will need to be closer together to map a smooth curve in the road than on relatively shallow corners.
Average out GPS-traces
- See: Accuracy#GPS
The accuracy of the points in a single GPS trace may be out by several meters. This depends on lots of factors such as the positions of the satellites when the trace was taken, tree cover, proximity to nearby buildings, position of the GPS unit relative to the center of the road etc. If many traces are taken for the same road, then the effect of errors in any one trace will have a much smaller impact on the average position of these traces.
To help with this, it's useful if you upload all 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 and should eventually result in lower position errors. If you have many tracks covering the same way, you may also try the "average tracks" script to make one "average" trace.
Align Aerial Imagery before Tracing
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 tracks or high precision POI data
- existing OSM data
Both JOSM and Potlatch have tools that support imagery alignment.
Do Not Trace from Outdated Imagery
Just because it is available doesn't mean that aerial imagery is up to date. Always check before changing or deleting existing OSM data. Best is to only map areas that you visit and verify yourself.
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 from local signs in 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 it makes sense to correct these.
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.
Verifiability
- See: 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).
Document your custom-tags
- See: New Features
When you use tags yourself that aren't on map features, give other mappers a chance to understand (and maybe adopt) them by documenting them in the wiki.
Do correct errors
If you find elements with tags that you think are wrong then do correct them. It's a wiki, your corrections can always be reverted, so be bold.
Mark estimations with FIXME
Sometimes it is 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 map your local legislation, if they are not bound to objects in reality
Things such as local traffic rules should only be mapped through the objects which represent these rules on the ground, e.g. a traffic sign. Other rules that can not be seen in some way should not be mapped, as they are not universal verifiable.
See also
- Editing Standards and Conventions - technical details on proper mapping.
