As previously announced, we are working with the UK’s Department for Transport to make advanced cycling data attributes available for incorporation into OpenStreetMap.

Rather than organising this along the lines of a bulk import, we are taking advantage of new technologies in Potlatch 2 and have commissioned Andy Allan, creator of OpenCycleMap, to develop new features to allow volunteers to collaborate on inspecting and merging the information into OSM.

This merging tool will also be of use for other external data that could be manually inspected and merged into OpenStreetMap.


The DfT commissioned survey work in various cities around the UK for their Transport Direct product. In 2011 they released the results of the surveys as Open Data, in a complex GML format based on Ordnance Survey ITN data – unsuitable for use with OSM. However, in addition, they have funded work to convert the survey data to be based on OSM geometries suitable for incorporation. This has been done through brilliant work by Ralph of CCG.

The kinds of things surveyed include cycle routes, cycle parking, cycle lanes and their widths, surfaces widths and lighting conditions of cycleable paths, and so on. We are working to add support for these attributes into CycleStreets, so that routes are further improved.

In the UK wide areas of the cycling infrastructure have been mapped in OpenStreetMap, often more recently than the data from the DfT. Also, with the development of Vector Background layers in Potlatch 2, there was an opportunity to create an improved process for dealing with external datasets.

Further background information is available in blogs and on the mailing lists.

The demo

We’re pleased to announce that a demo is now available, and we’d like people to test it.

A demo is now available. It contains sample data for Nottingham and Cambridge, but it’s deliberately unable to save the data back to the main OSM server. When the final version of the data conversion is complete and available, this will be updated and fully able to work.

Two test areas are currently loaded:

How to use the merging tool

The merging process works as follows:

  1. Click ‘Map style’ > ‘Wireframe’ to make things much easier to work with.
  2. The background data is highlighted either orange (needs attention) or blue (already processed).
  3. Click the background features to select them.
  4. Ctrl+click (or cmd+click on a Mac keyboard) the relevant OSM feature (line) to see a side-by-side comparison.
  5. Click on ‘Advanced’ in the left panel to see the merging controls.

Feel free to play around with this – the snapshot data is being reloaded from time to time as we get better imports, although we think we’re almost at a stage where the data conversion is fairly bug-free.

The merging tool is currently a beta and further improvements are planned. See the main Merging tool page on the OSM wiki.

The first screenshot shows the thick gray line (DfT data, as a background layer) highlighted. It shows the attributes it has:

The second screenshot shows what happens if we now control-click (or cmd+click on a Mac) on the OSM line – we now get a merging interface where we can accept/reject each attribute, and click the button at the end to accept all the changes:


Feedback on the data

We would really welcome feedback as to any errors you spot in the data conversion. The aim is that the data is pre-processed and snapped to the OSM geometry as effectively as possible, so that merging is merely a case of manual confirmation of each attribute according to your local knowledge.

Issues we have fed back so far on are:

  • Alignment. The data was originally snapped to an OS Open Data, and has been geographically aligned via advanced GIS techniques to OSM. It’s already well over 90% matching and further improvements are being made.
  • The issue of streets being broken up but having the same data. Our GIS contact plans to merge when the street name and data matches.

The software

A number of software components are used to make all this work

  • Potlatch 2 is used as the editor, and can load data from both OSM and the DfT data. The splash pages and other resources are available on github
  • Snapshot Server is used to serve the DfT data for each user, saving them from having to load the whole country at a time
  • Some scripts are used for loading data in and out of the server. These use Osmosis to read/write between XML and Postgres.


The data is expected to be released under the Open Government License. We have been seeking an early letter of confirmation from the DfT on this and will update this page and the OSM Wiki accordingly. (The ITN-referenced dataset is released under the OGL already.)


We’d really appreciate it if you could try out the beta and add comments below, or contact Andy Allan with any feedback you have. Did you figure out how to use the tool? Did you manage to merge some data? What doesn’t work? How could the tool be improved?

If you have local knowledge of the areas in question, it would be great to hear back from you on the datasets themselves – do they match reality? Are the tags appropriate?

One thought to “Merging tool – new cycling data”

  • Josh

    Hi, thanks for working on this! For joining ways with identical tags, try OsmGlommer, the not-yet-on-SVN code Mike Nice wrote and I modified for doing just this. Unfortunately it’s in C# and only has an MS VS project file, but it shouldn’t be hard to make it compile on Windows or for that matter re-implement it in some other language. Frederik Ramm made, another option, which is on, but OsmGlommer does a check for dual carriageways and matches on all tags (rather than requiring you to list them all), though of course his script could be modified to do these things as well.

    Can you share details or code for how you matched the geometry up to OSM? Also, any plans for there to be an option to match the OSM geometry to the background? (Think of JOSM’s “Replace geometry” feature in the utilsplugin2, but likely not moving intersecting nodes.) This is certainly more advanced, and likely outside the scope of this current cycling attribute work.

    What about a feature to say the background data is plain wrong? This would be in order to provide constructive feedback to the data provider. Or perhaps with the semi-automatic conflation it can be inferred what tags are wrong if the user decided not to merge them, but still said it was complete.

    Good work, I’d like to use this tool once it matures for my county’s data.

Leave a comment