Nowadays every cyclist uses OpenStreetMap – but not all might be aware of this. This great project, where thousands and thousands of people bring together their geographical knowledge in an open database, is the foundation of many of the useful applications that cyclists use every day. Think about the maps and navigation hints in navigation apps or on GPS devices, software for route planning or websites where you can upload and share your tracked activites. All these use data from OpenStreetMap. Of course also singletrails.com does.
As with every database there is a simple rule: shit in – shit out. Or from a cyclists point of view: whenever your navigation device leads you on a motorway, a rotten, non-rideable path or down some stairs the reason very often is that the underlying openstreetmap data are wrong or incomplete. That is reason enough for a closer look on how these data are gathered. And before all else the good news: everyone can (and should) contribute to improve the data. Thanks to good tools the start is very easy and doesn’t hold much risk if you are careful.
A practical example: provide surface information
Let me show you how it works on a practical example: especially for roadbike riders the surface of a road is one of the major criteria for which route to choose. On bigger roads, which are also used by cars, most applications assume that they are paved when no explicit surface information is provided. However on smaller roads, which you tend to include in routing as they are probably less busy and nicer to ride, this assumption doesn’t hold and so you often get nasty suprises and are led wrong.
The example is located in France near Saint-Symphorien south of Bordeaux. It is a beautiful cycleway with excellent pavement which follow an abandoned railroad track. On openstreetmap.org you will find it as a dashed blue line.
To inspect the properties of the way of interest you have to switch to editing mode. That is very easy – just click the “Edit” button in the upper left corner to start the default editor named iD. After logging in (if you don’t have a login you get one quickly via the “Register” button) and zooming in you will see all the openstreetmap objects as lines, areas and symbols. If you select them by clicking the respective object properties will be shown on the left hand.
On the very top you find the object type, which is a cycleway in this case.
Below that you will find Issues listed in some cases. These may be discovered and flagged from other openstreetmap authors or from quality assurance proccesses, which continuously investigate the data for inconsistencies. In this case the cycleway (marked red) crosses a small river (shown light blue) and neither a bridge nor a tube are existing. If you are faces with these issues you should check if they are relevant for what you intend to change and consider them respectively. Most of the time this will not be the case.
In the section All Fields we finally find the information that is interesting for us as cyclists: surface, oneway, street name etc. When changing these values the editor iD gives us very good guidance as he already proposes a list of possible values for each field. You may notice that some of the data are grayed out, for example “Allowed access for motor vehicles: no”. Indeed these values are not stored in the database but are assumed to be the default value if no other is specified. The problem with that is that there is no official definition for the default values, but rather only more or less binding recommendations. If you want to understand in detail how a particular field should be filled you will find helpful information by clicking on the info icon next to the field name. Following the presented link you will be guided to the appropriate openstreetmap wiki page, for example this one describing the “access” field.
Sometimes it is a bit confusing what information is really stored and which is only assumed by the editor. Fortunately there is also the section All tags, which lists all object properties exactly how they are stored in the openstreetmap database.
Finally – the change
From the proposed surface values I select “asphalt”. Immediately the database entry surface=asphalt is shown in the “all tags” section.
So are we done already? Almost, but there is still a small step to go. For now the change is only locally in your browser. To send it immediately to the global openstreetmap database, where it is accessed by all the applications that use openstreetmap data, is too risky as this would also happen for any mistyping or other accidental mistake. Instead before sending your changes you should review them carefully. The editor supports you in this, as it shows the number and the list of changes you have done. If you find some inconsistencies you can try the Undo command unless you reach a consistent state. If you are still insecure the best way is to cancel the editing session and start all over again. For what you should always be aware about: if you send you changes they “go live” immediately and globally. There is not central instance that checks the contributions – and that’s not needed if all authors act carefully and responsible.
So after I checked the changes again I decide to save them finally. It’s a good practice to provide a meaningful comment, which describes what has been changed, so following authors don’t need to figure this out by themselves from the tag history. In this case I enter “added surface information for cycleway” as comment and und click on “Upload”.
At this point you can check if you want your changes to be checked by another author. That definitely is a good idea for a beginner, but as there is no well-established process for this cross-check you will not get helpful feedback every time. Especially you need to be aware that this cross-check will not hold back your changes. They will also immediately “go live” if you choose that option. So be careful in any case.
No we are finally done. Our change will be taken over to the global database very quickly. Any subsequent author us will already see the changed information in the openstreetmap editor. However it may take some more time unless the change will become visible in a map or effective in an routing app. This typically takes some days to weeks, dependend on how often the map and application data are updated from openstreetmap.org and how they are processed.
Conclusion: contributing to OpenStreetMap is easy
The example above was very simple, but that holds for the most improvements that you will encounter. You will discover some inconsistency in the representation of a map or the behaviour of an application, go to check the object properties on openstreetmap.org and fix or complete them.
I want to encourage you trying this out by yourself when you find an inconsistency. To get started you will find a lot of additional tutorials, videos or posts that helps you. Here are some: