Providing data to

OpenStreetMap

a guide for local authorities and other data owners

Contents

Before you start 3

1: Why should you want your data to be in OpenStreetMap? 4

2: How OpenStreetMap works 5

3: Licensing 8

4: Approaches 10

5: Challenges in adapting data 14

6: Maintenance 16

7: Working with the community 17

8: Using the OSM ecosystem 19

Appendix 1: Conflation tools 21

Appendix 2: Case studies 22

About this guide

This guide is intended for data owners including those at local authorities, other Government organisations and non-profits. Some basic GIS knowledge is assumed. It is not intended as a complete guide to editing and using OpenStreetMap, but rather, to help you through the considerations particular to contributing third-party datasets.

The document is licensed under the Creative Commons Attribution 4.0 licence. You may freely share and adapt this document, as long as you give appropriate credit. All map extracts in this document include data © OpenStreetMap contributors, licensed under the Open Database Licence (openstreetmap.org/copyright).

Thank you to the OpenStreetMap Foundation’s Data Working Group and Licensing Working Group for feedback. This guide is not issued or formally endorsed by the OSM Foundation.

Production of this guide has been supported by the Open Data Institute stimulus fund, and by Oxfordshire County Council and Buckinghamshire Council.

Guide written by Richard Fairhurst (www.systemed.net). This is version 1.0, published in May 2020.

Before you start

You don’t need any prior knowledge of OpenStreetMap to read this guide. However, even a small amount of hands-on experience will help you understand how OSM works, so you can get more from this guide.

Go to www.openstreetmap.org , zoom in closely to your area, and browse around the map for a while.
Use the ‘?’ tool on the right of the screen, then click on a feature on the map, to inspect the data underlying the map. Choose a feature from the ‘Nearby features’ list. Look at the ‘tags’ (attributes) for the feature.
Click ‘Sign up’ in the top right to create an account, and confirm your account by email.
Zoom into an area near your house or place of work, and click ‘Edit’.

Follow the interactive walkthrough.

Using the skills you’ve just learned, add a feature currently missing from the map, and click ‘Save’.

Viewing the tags for a feature on openstreetmap.org.

We’d also recommend that you take a look at WeeklyOSM, the OSM community’s informal news summary, to get a flavour of the many uses to which OSM data can be put, and of on- going activities in the community. You can browse the current and previous issues at weeklyosm.eu.

Why should you want your data to be in OpenStreetMap?

Reach

OpenStreetMap is the world’s only free map database – which means it has colossal reach.

Countless websites, apps and publishers base their maps partly or entirely on OSM data. These include Facebook, Wikipedia, Amazon, Microsoft and Apple; outdoor-focused leisure companies such as Strava and Garmin; map publishers such as Michelin; map service providers such as Mapbox; and thousands of independent and hobbyist developers. In markets such as walking and cycling maps, OSM is the dominant provider – not just because of its free, open nature, but because its data can be much richer than car-centric commercial datasets.

As such, getting your data into OpenStreetMap greatly increases the impact of your data and helps you achieve your organisation’s mission. For example, by providing data on greenspace, active travel infrastructure, or health providers, you can help your citizens live healthier lives through the apps and websites they’re already using.

An OSM-based event map on Facebook.

Maintenance

OpenStreetMap has a worldwide community of motivated volunteer mappers, with over six million registered users since its foundation in 2004. Typically, 16,000 users make changes to the data every week, making it the world’s largest crowdsourced, open database.

Where there are active mappers in your area, they can help to build on your data by updating OSM with any changes they observe.

The OSM ecosystem

Thousands of tools have been developed to work with OSM data, for map visualisation, routing and analysis – on the web, natively on mobile, or in print. OSM’s open nature means thousands of these tools can be hosted independently, with no need for approval by a central OSM organisation: the tools just download OSM data and work with it.

By integrating your data into OSM, you can benefit from this ecosystem of tools. The tools you already use, such as ArcGIS and QGIS, are also able to work with OSM data.

How OpenStreetMap works

An all-purpose database, not just a map

OpenStreetMap is not just a display map. It’s a global database of factual mapping information – paths and roads, shops and businesses, rivers and peaks, administrative boundaries, bus and train routes, and so on. This data is used for map display, routing, analysis and more.

The default map that you see at openstreetmap.org is just one possible view on this data. But much of the database is not surfaced in this cartography. Other sites take a different selection from the OSM data, and use that to show contrastingly styled views. You can see a few examples of this using openstreetmap.org's layer switcher, but there are many more.

You will find that people often differentiate between OpenStreetMap, meaning the project and database, and www.openstreetmap.org , meaning the website which offers a showcase (but by no means the only one) for the data.

Thunderforest’s ‘Outdoor’ style is a topographic rendering of OSM data, in contrast to the ‘street map’ default appearance at openstreetmap.org. Style © Andy Allan/Thunderforest.

A collaborative project

OSM data is owned and maintained collectively by the map’s editors. No-one has special privileges – once you make an edit, it’s there for anyone to improve and adapt.

For “data owners” who are accustomed to being the authority for their data, this can take some getting used to. But community maintenance works surprisingly well; conflicts and vandalism have been rare. When data is damaged, the offending edits can be rolled back.

There is no formal review process in OSM, no super-users or other privileged editors. Your map edits go live immediately. Consequently, it’s worth making the effort to ensure your edits are right first time.

A single database without layers

The software used by GIS professionals often organises data into layers. But as a ground- up, community-organised project, OSM does not have pre-ordained layers which volunteers are forced to work with.

Instead, all geometries are ‘tagged’ with rich attributes – key-value pairs agreed by the community. One OSM feature might have tags that would typically span multiple layers in a GIS system. For example, a line geometry could be both a cycleway (highway=cycleway) and an abandoned railway trackbed (railway=abandoned).

This intricate, connected data model is enormously flexible. Data consumers, such as display maps or routing applications, can extract the data they want by querying the tags. New uses are constantly being devised for OSM data, not restricted by a fixed set of layer definitions.

As a result, you need to take extra care when contributing your data, which needs to ‘mesh’ with existing data rather than just sitting in a separate layer. For example, if you are providing path data, it will need to connect topologically with existing roads and paths, and you will need to avoid overwriting existing path information in OSM.

Factual, long-term, observable data

OpenStreetMap does not include subjective data such as restaurant reviews. All data should be ‘verifiable’ – i.e. two people observing the location would make the same observation.

Nor does it include short-term data such as potholes or week-long road closures. Long- term closures or characteristics, such as a poor quality road surface, are suitable for inclusion.

OSM is principally for observable facts: the name and geometry of a road, the classes of traffic allowed to use it, the signposted road number, and so on. Private administrative data, such as internal reference numbers or boundaries, is not included; public administrative boundaries (such as country, region and county boundaries) are however included for their sheer utility, even if they’re not always visible on the ground. OSM is not a business directory, but shops, restaurants and offices are mapped, with some metadata such as phone numbers and website addresses.

As a general rule, OSM’s most valuable resource is its mappers. Data is organised for ease of mapping, not consumption. It is expected that most data consumers will need to do some processing to make the downloaded data suitable for their use.

Unbounded but pragmatic

There are no restrictions on the level of detail that can be mapped in OSM. You will find parks where every tree is mapped, zoos with every enclosure mapped and labelled, allotments with every shed mapped. This is tempered by a pragmatic concern for data maintenance – very detailed mapping can be hard for a community to maintain – but overall, OSM does not presume to restrict what its contributors can map.

Detailed mapping of Bristol Zoo, showing paths, gates, animal houses and even individual trees on Gorilla Island.

Volunteer-driven, corporate-supported

You may be asking if “the OSM organisation” can do the work of integration if you supply them with your data. The answer is that there is, broadly, no “OSM organisation”.

OSM is volunteer-run. The OpenStreetMap Foundation, which exists to support the project, takes a deliberately hands-off approach and has only one administrative employee.

Generally, mapping in OSM happens because volunteer contributors want to do it.

As OpenStreetMap has become a viable platform and data source for major companies, corporate contributions have increased. Facebook, Apple and Amazon all have teams working on improving OSM. There is no charge to use OSM’s data, but several of these companies support the OSM Foundation with sponsorship (direct or in-kind) to help with server running costs. Ultimately, however, OSM is run and led by volunteers.

Licensing

The sine qua non of any data incorporated into OpenStreetMap is that the data’s licence must be compatible.

OpenStreetMap data is distributed under the Open Database Licence (ODbL). All contributors also agree to a set of Contributor Terms. All contributed data must be compatible with these. In practice, this means that the data must be licensed without restrictions on reuse except for some attribution requirements (see below).

Compatibility with popular licences

Your data may already be licensed under a popular data licence. Some licences are already compatible with OSM’s Open Database Licence, meaning that you can legally incorporate the data into OSM without further waivers. Others may require you to provide a waiver of incompatible terms. The most common licences are:

Creative Commons Attribution (CC-BY 4.0): This licence is almost compatible with OSM licensing, but there is one small technical incompatibility, and attribution needs to be clarified. In practice, this means your organisation should provide a waiver for use of the CC-BY-licensed data in OSM. See blog.openstreetmap.org/2017/03/17/use-of-cc- by-data/ for details.

Creative Commons Zero (CC0) / ODC Public Domain Dedication & License / US Federal Public Domain: Data licensed this way can be included in OSM without further licence considerations.

Open Database Licence (ODbL): This is the licence used by OSM. As such it is compatible, but you should document that your data was initially made available under the ODbL.
Open Government Licence UK: OGL-licensed data can be included in OSM, subject to attribution and derived data issues (see below). You should document that your data was initially made available under the OGL.
Other Creative Commons and ‘open data’ licenses: These licences are unlikely to be compatible with OSM’s licensing. To make your data admissible for OSM, you should ‘dual-license’ it – i.e. also offer it under one of the above compatible licences.

Common issues

Many licences require attribution of the original data source. OpenStreetMap itself provides attribution of third-party sources on a wiki page (wiki.osm.org/Contributors) and, for the very largest sources, at www.openstreetmap.org/copyright .

It is impractical to attribute the thousands of data sources on the map itself. As such, if your organisation requires that attribution is visible at all times when interacting with the data, it will not be suitable for OSM. You may need to consider an explicit waiver to take account of this point, particularly if your data is currently licensed under a Creative Commons Attribution licence.

Several ‘open’ licences, including some in the Creative Commons family, have a prohibition on commercial use. This prohibition is incompatible with OSM. Although the OSM Foundation itself is a non-profit organisation, OSM data is used by many commercial organisations.

Some ‘open’ licences have additional clauses that require the user to indemnify the data provider, or to refrain from derogatory treatment, and so on. These additional clauses are incompatible with OSM.

The OSM Foundation is unable to relax the requirements for a compatible licence.

Future liability

Once the data is in OpenStreetMap, you are no longer liable for it. OSM’s licence and Contributor Terms expressly disclaim contributors’ liability and offer no warranty. You will therefore not be liable for any changes that OSM contributors may make to the data.

Additional rights in the data

You should be confident that there are no additional rights in the data other than those held by your organisation. This is most likely to be an issue if the data was created with reference to a copyrighted map; by looking up addresses from a copyrighted database; or by using a commercial dataset.

For example, data created by tracing over Google Maps, or by using the Google Maps API, is not acceptable for use in OSM. You would need to recreate it using OSM as a basemap. Similarly, data built on a commercial dataset such as those offered by TomTom or HERE will not be acceptable.

UK public sector organisations may have data created with reference to maps from the Ordnance Survey. The OS has a special ‘Presumption to Publish’ process for these cases. You should follow the guide at www.ordnancesurvey.co.uk/business-government/licensing- agreements/presumption-to-publish-form.

Using the data

The above explains the licensing requirements for data contributed to OpenStreetMap. What are the restrictions placed on data downloaded from OSM?

The Open Database Licence has two main requirements. First, anyone using OpenStreetMap data must attribute (credit) OSM. For maps displayed on-screen, this is usually taken to be a credit visible in the corner of the map.

Secondly, when OSM data is mixed with another dataset, that data must be available on terms compatible with OSM’s. This is sometimes known as a ‘sharealike’ or ‘copyleft’ clause and prevents (for example) another map supplier taking OSM’s footpath data and combining with its own road data, without contributing the road data to OSM. However, although mixing data has this stipulation (a ‘Derivative Database’), independently overlaying different datasets does not (a ‘Collective Database’). The subject is reasonably complex and there is guidance on the OSM Foundation website.

Approaches

The OSM community does not generally recommend programmatically ‘importing’ data into OSM, without human review or intervention. The intricate, connected nature of OSM data means that automated imports are almost certain to cause problems.

Instead, there are two broad approaches you could consider:

an ‘unmanaged’ approach, where you provide your raw data to the OpenStreetMap community, and invite contributors to integrate it;
a ‘managed’ approach, where you process the data into a format suitable for inclusion, and provide tools for OSM contributors or your staff to use.

If you are unsure after reading this which is the most suitable approach, then the local community and/or OSM experts will be able to advise. Below, we discuss these two recommended approaches, and then look at two further alternatives.

The unmanaged approach

Assuming your data is openly licensed and factual, you can simply publish it and ask the OSM community to integrate it. This is most suitable if you have limited resources.

There is no guarantee, of course, that the community will take you up on this offer. The response is likely to depend on the community’s strength in your area, and how compelling your data is. You may find that some areas/aspects of the data get higher take-up than others, and that the speed of integration will depend on the availability and enthusiasm of OSM contributors.

You should publish the data in a very common format – ideally GeoJSON, shapefile, or OpenStreetMap’s own .osm format. OSM editing tools are not generally able to open other GIS formats such as geopackage and Esri file geodatabase. Make the data available for straightforward download without requiring a login wall.

You can then inform the OSM community in your local area that the data is available (see section 7).

Do provide documentation for the fields and collection methodology of your data. This will help the community settle on the most appropriate tags (attributes). Often, a third-party data project will be co-ordinated informally by interested contributors through a page on the OSM wiki.

The managed approach (‘conflation’)

This requires more effort on your part, but is a more certain way of making sure your data is included. In this approach, you convert your data to a format ready for direct incorporation in OSM. This will usually entail:

setting the appropriate OSM tags from your original attributes

ensuring geometries are OSM-friendly (no multi-linestrings, no overly detailed runs of points)
removing any data that duplicates data already in OSM

This work is typically carried out automatically by a purpose-written script.

The data can then be provided to OSM users or your own staff for manual ‘conflation’ – i.e. bringing the data into OSM piece-by-piece. Since most of the work has been done by your script, the manual work is reduced correspondingly: it will mostly comprise reviewing the data for duplicates and positioning, and making sure that all geometries connect with existing data.

For example, if you are bringing in a woodland dataset, you would want to check that the woodland polygons do not overlap rivers or built-up areas. If you are bringing in footpaths, you would need to manually connect them with existing footpaths and roads so that routers can navigate between them.

There are several tools currently available to assist with conflation, which are listed in Appendix 1.

Using OSM Live Conflation to bring features from a third-party dataset into OpenStreetMap.

The bulk import approach

A third approach is to programmatically insert the data with minimal human intervention. This is strongly discouraged unless you are exceptionally experienced with the OSM community and data model.

It is in theory possible to perform a fully automated import. This will involve all the scripted steps of the managed conflation process (setting tags, fixing geometries, removing duplicates), loading the resulting data into an OSM editor, and then uploading it.

This is a very dangerous process and liable both to result in data errors (which will result in the work having to be reverted) and reputational damage. There are also community impacts to consider – it is easy to demoralise a local mapping community by flooding their area with poor-quality data. If you are considering this route, you must follow OSM’s Import Guidelines.

The reference approach

Finally, you may decide in consultation with the community that the data is not suitable for direct inclusion in OpenStreetMap. This could be due to the difficulty of converting it to a suitable format; the lack of resources to do so; or the complexity of integrating with existing OSM data.

That does not mean the data is useless to OSM. It may be useful as a reference to assist further mapping, even if none of the data is directly used.

For example, you may have road network data for your area. Creating aggregate statistics from this (e.g. “this area has 530km of paved roads”) will help mappers compare against OSM’s existing data and identify where coverage is weak.

Publishing the data as a ‘rendered’, cartographic background map can also be useful for mappers. This can then be used in any OpenStreetMap editing software as a reference to inform manual mapping activities.

US Forest Service road and POI data has not been directly added to OSM due to the complexity of integrating it with existing road data. Instead, it is available as a background map for OSM contributors, allowing them to add missing features (such as campgrounds and trailheads), and modify existing data to add road surface information.

OSM guidelines for large-scale editing

The following guidelines will be applicable to your work. They set out expectations for community approval and engagement. Please read them and identify any processes you will need to follow:

Import Guidelines
Automated Edits Code of Conduct
Organised Editing Guidelines

Who can do it?

You may choose to leave the task of integrating the data to the community. OSM contributors are enthusiastic and know their local area intimately. We would recommend that you make yourself available to answer questions and to otherwise engage with volunteers.

Alternatively, you may choose to employ people to carry out the work. There are numerous consultants working in the OSM space who can be employed to carry out the technical activities, such as the conversion from your attributes to OSM tags and identifying duplicates. There are also some services companies who can be hired to manually integrate the data into OSM. (See https://switch2osm.org/providers/ for a list.)

If you follow this approach, you should be transparent about who is ultimately behind the work. We would also recommend publishing any scripts you use for public study (such as on Github) so that your assumptions and methods can be understood, examined, and potentially improved, by the OSM community.

Whoever does it, the OSM guidelines require that bulk editing is performed under a discrete user account. So if your usual account is (for example) SallyRT, you might set up a new account, SallyRT_TreeProject, for this project. This makes it easier for other OSM contributors to identify how this data was contributed, and means that if a systemic problem is later unearthed, it’s easier for your data to be corrected.

Challenges in adapting data

What’s involved in converting a typical dataset for use in OSM? These are some of the issues that you, your contractors or volunteers will need to consider:

Tags/attributes. The attributes in your dataset will need to be converted to OSM ‘tags’. The most common of these are documented on the OSM wiki. You should accord with local usage (as an example, highway=secondary always means a B road in Britain; in Ireland it would be an R road; in France it would be a principal D road). Some of your attributes may be unsuitable for OSM and will need to be omitted entirely.
Matching to existing data. If an OSM feature already exists for the thing you are mapping, you should modify that feature, rather than adding a new one. For example, if you are providing cycle parking information, you should check that a cycle stand has not already been mapped at that location before creating a new feature. If you have more information (such as capacity), add that to the existing feature.
Topological correctness. OSM is a topological data model – that is, roads and paths are connected to indicate that you can move between them at that point. Any data you add should retain this. For example, if you are adding footpaths, they should be properly connected to nearby roads. This is very complex to do automatically and will usually require manual mapping.
Relative positions. Any dataset will have some positional inaccuracy. You should be prepared to adjust geometries by hand, so that they align with existing data: for example, checking that bus stops are on the correct side of the OSM road centreline, or that building polygons do not overlap.
Simplifying data. Some data may be too detailed for OSM’s standards – for example, OSM way (line/area) geometries typically have enough nodes (points) to delineate the shape, but no more. You may need to simplify your data first.
Future maintenance. Similarly, if your data is particularly detailed, consider whether the mapping community will be able to keep such detailed data up-to- date; and whether the sheer amount of data will make it difficult for mappers to edit features in this area. For example, the consensus in most areas is that OSM maps highway centrelines, not areas (except in special cases such as city squares/ piazzas or complex junctions). Pavements (sidewalks) are often mapped as attributes of the road, rather than as separate geometries.

In a few cases, the challenges of integrating data are such that even partly automated methods will be unsuitable. This is most likely to be the case when there is a high density of existing OSM data in the area you’re working in, and your data requires integration with it.

As one example, adding parking restrictions in an already well-mapped Western capital city would be exceptionally complex to automate. In cases like these, the local OSM community may be able to help through manual mapping.

Getting it right

Most OSM activity is iterative, and your data addition should be no different. Start small. Try a few test edits before launching into the full project. Ask for feedback on these edits: people might have spotted nuances that you haven’t yet noticed. (We detail below how you can engage with the OSM community.)

Where possible, we would recommend that you use ‘OSM-native’ tools for your principal editing, and in particular the iD and JOSM editors. These have a lot of built-in logic to cope with the conventions of OSM tagging, which may not be present in generic GIS tools – even when extended with OSM plugins. The OSM-native tools are therefore better equipped to cope with the numerous edge cases that can arise. That said, your early data preparation steps may be greatly assisted by third-party tools, such as ogr2ogr (which can translate between most GIS file formats).

There is extensive documentation available for OSM. The community-maintained wiki is a wealth of information, but can sometimes be unfocused, contradictory and opinionated – do not always rely on it to provide definitive answers. LearnOSM takes a more didactic approach, and is helpful though with a particular steer towards humanitarian mapping tasks.

Topological correctness in OSM: note that the two paths connect directly to the road, representing that walkers can pass directly from one to the other.

Maintenance

Keeping your data fresh

As your data changes, you’ll want to keep OSM updated. If the changes are minor or sporadic, you will find it easiest to make the changes by hand in OSM. Learning how to use an OSM editing tool will be worthwhile.

If you don’t have the resource for this, consider publishing a list of changes on your website, or on a platform such as Twitter, or on an OSM forum or mailing list. Local mappers then have the option of updating OSM based on your information.

If there are significant data changes, you may prefer to take a managed conflation approach once again, as detailed above. Note that OSM feature IDs are not guaranteed to be stable; many editing operations, such as splitting or joining features, will result in a new feature ID being assigned. You’ll therefore need to check against the latest OSM data rather than simply uploading newer versions of the data you originally created.

Benefiting from edits to your data

OSM data is communally owned. The original contributor does not have any special rights to the data.

That means that, in an active area, your data will benefit from the improvements that OSM users make over time. These might include fuller metadata (tags) or geometry improvements. You can download this improved data and use it.

Downloading data from OSM

openstreetmap.org has an ‘Export’ function which provides small areas of data in .osm format. The full worldwide database download is available from planet.openstreetmap.org.

For most purposes, you will want data covering a city, region or country. These are available (free of charge), in either .osm.pbf or shapefile format, from Geofabrik (updated daily).

For advanced data export, Overpass Turbo provides a powerful query language (documentation on the OSM wiki).

Your GIS package may also provide a direct “download from OSM” feature or plugin.

Note that any data you download is bound by the conditions of the Open Database Licence, as described above.

Working with the community

Getting in touch with your local community

Local OpenStreetMap contributors take great pride in their area. By keeping them abreast of your plans and working with them, your data is more likely to land safely in the OSM database, and to benefit from ongoing maintenance and attention.

As a decentralised project, OSM has many disparate avenues of communication. Each local community chooses its own favoured method. For example, the German community mostly uses a web forum; the US community uses Slack; the UK community mostly uses a mailing list; and the French community uses both a mailing list and a web forum.

You can see who uses what, and where, by visiting the unofficial index at openstreetmap.community.

A list of communities relevant to the London area on openstreetmap.community.

To post on the forums at forum.openstreetmap.org, you can use your standard OSM login. The mailing lists at lists.openstreetmap.org require a separate signup.

Some countries have ‘local chapters’ of the OpenStreetMap Foundation. Generally, the Foundation supports the project but does not control it, so these chapters don’t have any particular power to approve or facilitate your project. However, they may have resources that are relevant or helpful.

Getting in touch with the international community

One of the best ways to keep the community informed of your project is using the ‘User diaries’ feature of openstreetmap.org. As a registered OSM user, you can post diary entries

essentially blog posts – which are visible to all at www.openstreetmap.org/diary . Browsing through existing diary entries will give you an insight into some of the mapping work going on – everyone from first-time humanitarian mapping volunteers to corporations such as Facebook and Amazon.

The international conference of the OSM community (State of the Map) takes place in a different country each year and attracts OSM contributors from around the globe. Talks are welcome on all OSM subjects, but even if you don’t want to deliver a talk, it’s a good place

to meet other people involved in the project. Many countries also have their own national or regional conferences, usually with the same SOTM branding.

You can follow the latest events in the OpenStreetMap community through the Weekly OSM newsletter. There are also international mailing lists and forums for discussion of the project.

Responding to feedback

Other users can leave comments on any edits you make to the OpenStreetMap database. These are called “changeset comments”. You will get an email notification of any such comments.

Such comments can offer valuable feedback as to how to improve your edits. If you have started with a few trial edits, do keep alert for any comments that are left on them.

Other users can also send you private messages through openstreetmap.org. Although these can be helpful, discussions held in public through changeset comments are much more worthwhile and will bring more of the community’s expertise to bear. Rather than conducting long conversations through private messaging, use public changeset comments instead.

Occasionally there may be a disagreement between two or three users that cannot be resolved amicably. Do not be tempted to get into an “edit war” where you repeatedly overwrite each others’ changes. The OSM Foundation has a Data Working Group that can offer help in cases such as this. You can contact them at data@openstreetmap.org .

How to get advice and help

There is a dedicated help site at help.openstreetmap.org. You can ask questions on any OpenStreetMap-related matter and volunteers will answer it. You can also search through previous questions to see if your issue has already been answered.

For instant help, there is an online chatroom at irc.openstreetmap.org. Choose a short nickname and connect to the #osm channel (or another channel for particular country/ language queries, such as #osm-us or #osm-de). You can then type a question and wait for answers; note that you may not receive a response for a while and that the general channels are most active during European daylight hours.

You can choose to engage a consultant who specialises in OpenStreetMap. Some are listed at switch2osm.org or on the OSM wiki. They will be able to guide you through the steps of getting your data into OSM, or suggest someone else who can.

Using the OSM ecosystem

By adding your data to OpenStreetMap, you benefit from the many tools that have been developed around OSM data. To list every single tool would be a ceaseless, ever-changing endeavour: this section aims just to illustrate the scope. Follow the WeeklyOSM newsletter for news on other sites and tools that are available.

Tools designed to work with OSM data are typically written for a Unix-based platform (Linux/Mac) rather than Windows. Most cloud providers, such as Amazon Web Services, Google Cloud Platform, and Microsoft Azure, offer Linux environments suitable for these tools. The tools usually require basic system administration skills to install.

Web/app map display

You can use OpenStreetMap data to serve rendered (display) maps for websites or within apps.

Like most webmaps, the map shown at openstreetmap.org is made up of individual ‘tiles’, which are rendered from the OSM database and then stitched together on a webpage.

OSM’s own render servers have limited capacity and are largely funded by volunteers, so they should not be used for production services.

Instead, if you anticipate moderate to heavy usage, you can download a copy of the OSM database, and render your own map tiles on your own server. The standard OpenStreetMap raster rendering stack is fully open-source: there are detailed instructions on how to host it yourself at switch2osm.org.

If you don’t want to set up your own server, there are numerous companies who offer a hosted map service based on OSM data, such as Mapbox, Geofabrik, Thunderforest and Maptiler. Many of these have a free tier, and offer a variety of map styling options.

Sometimes these map styles are practical and useful, such as Thunderforest’s walking and cycling maps; sometimes they’re strikingly artistic, such as Stamen’s Watercolour and Toner styles. You can see a fuller list at switch2osm.org/providers/.

OSM’s open nature makes it particularly suitable for mobile apps. Since the data can be downloaded in advance and then used offline, you can provide maps to your field teams who may not have internet connectivity at all times. Mobile apps generally use ‘vector tile’ technology, which has lower storage requirements and offers greater styling flexibility.

Routing

OpenStreetMap’s topological data model makes it suitable for routing – both consumer- level A-to-B queries, and complex route optimisation analysis. There are several routing applications designed for use with OSM data, including Graphhopper, Valhalla, OSRM and Itinero. Again, you can install these on your own servers, or use a hosted service.

A bike route planned with cycle.travel, an OSM-based routing service.

GIS

Both ArcGIS and the open-source QGIS can work easily with OpenStreetMap data. Esri provides the ‘ArcGIS Editor for OpenStreetMap’. As well as offering tools for limited editing of OSM data directly in ArcGIS, this can be used to download OSM data into a file geodatabase; and to create routing networks for use in ArcGIS Network Analyst. QGIS has no OSM editing functionality, but can download data directly or through the QuickOSM plugin.

Map annotation

OSM is often used as a basemap for data collection exercises, including consultations and field surveys. uMap is the easiest off-the-shelf platform for this, and can either be used in its hosted version, or installed on your own servers. If you wish to develop your own interface, the Leaflet library is favoured by many web developers.

Custom development

When existing OSM tools don’t do what you need, there are numerous OSM specialists who are able to develop custom tools. The listing at switch2osm.org is a good starting- point for contacting them.

Appendix 1: Conflation tools

There are numerous tools available to assist conflation of your data with OSM data. A full survey would be outside the scope of this guide, but this list should provide pointers for further research.

Cygnus: This specialist tool is designed for conflating road datasets in areas where OSM has limited coverage.
Hootenanny: This is a sophisticated tool using machine learning to conflate two datasets, with a user interface extending the standard OSM web-based editor (iD). Deploying this will require some technical knowledge.
JOSM: The popular power-user editor for OpenStreetMap has a Conflation plugin. JOSM is already used by many experienced OSM mappers, making this a good choice for any project with heavy community involvement.
Live Conflation: This provides a direct user interface for conflation tasks where every feature needs to be manually reviewed.
OSM Conflator: This is a command-line script for basic conflation tasks.

In addition, these tools may be useful for co-ordinating community involvement:

MapRoulette: A project for splitting large improvement tasks into easy-to-achieve ‘micro-tasks’.
Tasking Manager: Task management software which can divide large-scale editing projects into grids, allowing users to record which ‘squares’ they have completed.
MapCraft: Similar to Tasking Manager, this allows tasks to be divided up into arbitrary areas.

Appendix 2: Case studies

Since the early days of the project, the OpenStreetMap community has worked with partners to integrate numerous third-party datasets. Four examples from the UK demonstrate the approaches taken and the benefits for the data owners.

Birmingham City Council 20mph streets

In 2016, Birmingham City Council rolled out a speed limit reduction on many urban roads, from 30mph to 20mph. As the scheme progressed, BCC officers kept the local OpenStreetMap community informed of progress, by forwarding the weekly reports prepared for the City Council cabinet.

OSM mappers were able to use these reports to update the streets in near-real time. This meant that the work was of immediate benefit to local residents, walkers and cyclists, as routing engines began to prefer these streets for active travel, and conversely made them less favourable to motorised travel.

Transport for London Cycle Infrastructure Database

Transport for London (TfL) surveyed every street in every London borough to collect information on over 240,000 pieces of infrastructure. The data was released as open data on TfL’s website.

In addition, TfL worked with the OpenStreetMap community (via the developers of two leading route-planning websites, CycleStreets and cycle.travel) and with London Cycling Campaign to integrate this data into OSM. The sheer size of the dataset made this among the most ambitious integrations ever attempted for OSM.

All the TfL data was matched against OSM to identify differences. The matching process was sophisticated and tailored to each datatype; for example, distinct matching algorithms were used for cycle parking and for traffic calming features.

The data was then classified by complexity of integration. Some data (such as new cycle parking) could be added simply, with minimal human intervention. Others (such as traffic calming) required active review. The most complex data, such as on-road cycle lanes, had to be closely integrated with the existing OSM road network by extensive manual work. TfL funded OSM experts to carry out the conversion work, and made staff resource available to assist the OSM community with manual integration tasks.

The great majority of cycling apps and online maps use OSM data. By providing the data to OSM and supporting its integration, TfL ensured that their investment both in the Cycle Infrastructure Database, and in the cycle infrastructure itself, would reach the greatest number of cyclists. The combined database, including both TfL/borough-managed infrastructure and facilities on private land, informs cyclists through journey-planners and maps, and helps policy-makers manage and plan the network.

Transport for West Midlands bus stop information

OSM is used by several public transport apps, either as a visual background map or as a primary data source. Some bus stop data for the UK was added to OSM in 2009 from the NaPTAN dataset (National Public Transport Access Nodes), but was not consistently kept up to date.

In 2017, Transport for West Midlands approached the local OSM community with an offer to assist in updating this data. OSM mappers and TfWM developers met weekly to assess the existing data and identify areas for improvement. The data was cleaned up, regularised to a common agreed format, and updated with new information. Over three months, the project saw 5,000 bus shelters added and 12,500 bus stops reviewed.

Oxfordshire County Council Cycle Infrastructure Evaluation

Cycle infrastructure provision in rural and semi-rural areas has developed piecemeal over time and rarely been consistently catalogued. Oxfordshire County Council, supported by the Open Data Institute, piloted crowdsourcing as a method to record existing infrastructure and its condition.

Volunteers from parish councils and local cycling groups surveyed cycle provision around Hanborough, an important transport hub in West Oxfordshire whose mainline railway station is within cycling distance of the growing town of Witney and provides commuter access to Witney and London. Their reports were compiled by OCC’s GIS team into a database that was made available for use in OSM.

To improve data integration efficiency, the project funded development of the Live Conflation tool, which made integrating this new data into OSM a simple point-and-click task. For each survey report, the tool identified existing OSM features that could be updated or proposed new ones. The result has greatly increased consistency and detail of OSM coverage in the area, as well as improving OCC’s knowledge of its asset base and helping to identify areas for future improvement.