Donate using PayPal

CycleStreets blog

News from CycleStreets

Archive for the ‘Routing performance/quality’ Category

What do you call a path alongside a road?

Thursday, November 28th, 2013

Cycle routes very often use un-named paths. These create a headache for anyone who tries to give directions to a cyclist:

“take the cycleway alonsidge this road, at a junction with two other paths turn right under the bridge, then go down a snicket on the left …”

It’s a key issue for us trying to produce intelligible itinerary listings — and even more important for our sat nav users where the names are called out!

Showing a fork in a cycle path.

“Bear right onto un-named link.”

Some examples include:

  • short links from a cul-de-sac onto one of a town’s radial routes
  • useful permeability links or short-cuts often known by colloquial phrases such as jitties or snickets
  • paths across open spaces
  • roads that begin paved but farther down revert to a track
  • bridleways
  • redways in Milton Keynes, cycleways in Stevenage
  • old railway lines that have become cycle routes (though these usually get a name)
  • short links addded to join cycle routes – often forming the hypotenuse of a triangle

Direct tagging

CycleStreets uses the street name if directly tagged in OpenStreetMap. If the name is not available any cycle route tagging from the way or any of it’s relations is checked. This results in names such as NCN51 or CS3.

Using only direct tagging still leaves an awful lot of un-named ways. As a fallback they can inherit names from the ways they join. Depending on how many joins there are we’ve used names following these patterns:

  • Link with …
  • Link between … and …
  • Link joining …, …, …

This has always been rather awkward and only slightly better than leaving them un-named. But when our sat nav apps call out such long conglomerations it sounds really painful — and something we just had to sort out!

Shared use path between Fulbourn and Cherry Hinton.

What’s a good name for the shared-use pavement cycleway between Fulbourn and Cherry Hinton?

Inferring better names

We’ve tackled this problem by using indirect data to invent more useful names. The result is that you’ll see the following phrases appearing in the street names of our itinerary listings:

‘Alley off …’

Where there’s a short un-named spur off a named way, for instance: Alley off Braithwaite Cresecent

‘… continuation’

An example is Gairbraid Avenue in Glasgow, the criteria used to identify these cases include:

  • Short: up to about 100 metres – renaming very long ways that match stretches the credibility of the idea
  • Only has two joints
  • Continuations of ways join to only one other way at one end
  • Cases where the joins at both ends are more complex are ignored.

‘… Blind Alley’

Like continuations but have connections only at one end, Canberra Close for example

‘Alongside …’

Some very useful cycle routes often run alongside roads, and are also often un-named in OpenStreetMap. We detect these cases by checking that the name of the nearest road at several points along the length of the cycleway. If the same name matches at least 70% of the length then the cycleway inherits the name of the road by being prefixed with ‘Alongside’. As an added bonus, we added a little easter egg relating to road names with ‘Drive’ in them.

A good example of the alongside names are shown in this route and this one.

Other names

The techniques above result in more sensible names for many tens of thousands of ways in the British Isles. We use some more techniques for fixing names across open spaces and inferring names of very short links between named ways.

As a general principle we try to make best use of what data there already is in OSM rather than suggest new rules about how it should be used. But in doing this work we’ve noticed that some ways drawn in OSM carry on round the corner to run alongside differently named roads. Such cases won’t inherit the ‘Alongside …’ name because of the 70% quality threshold. To fix that those ways should be split at the corner. We did split the long cycleway between Cherry Hinton and Fulbourn at the point where the adjacent road changed its name.

The second street named in this route shows that we’ve still got a way to go to cover more cases for choosing better names, but as ever this work is ongoing.

How far would you ride to avoid a busy right turn?

Friday, July 12th, 2013

The graphic shows work in progress to improve the quality of CycleStreets routes by taking into account the cost of making a turn.

This is part of routing enhancement work being undertaken by Codex Cambridge with us as part of the Technology Strategy Board Innovation Vouchers scheme.

Maps showing routes through a junction

Top: balanced route (amber) recommends turning right across busy Perne Road.
Bottom: by including turn cost the advice changes to straight on at the roundabout.

The upper frame shows three routes for a journey along Cherry Hinton Road, Cambridge from west to east. The quietest route in green avoids the busy roundabout by using the shared use footway and toucan crossing of Perne Road. The fastest route in red goes straight across the roundabout. The balanced route shown in amber takes the first roundabout exit and then uses the service road marked Adkin’s Corner to connect with the shared use pavement.

The problem with the balanced route is that it is rather awkward to make that right turn off Perne Road. A rider willing to make such a right turn would likely be equally confident to have gone straight on at the roundabout.

Turning right from a major road into a minor road usually requires looking behind and moving out into the road to get into the right position to make the turn. If there is a lot of traffic it may require stopping at an arms distance from the middle of the road and waiting until it is safe to complete the turn. These factors amount to an extra delay and make the route feel more busy.

The lower frame shows the situation when the cost of making a turn has been included in planning the route and shows the balanced route going straight on at the roundabout.

Choosing the numbers

In the case of the fastest route the cost of turning right can be estimated as a number of seconds. The estimate has to be for a typical rider and represent an average time. In reality the amount will vary by the time of day, amount of traffic, the type of roads involved and the rider. In CycleStreets the only data we can easily access are the types of road. So as a starting point we can create a table with the following columns:

  • from road type (e.g. primary, secondary, service)
  • to road type
  • turn type (eg. turn left, turn right, straight on)
  • estimated delay in seconds

So for instance a right turn from a primary road into a service road could have a delay of eight seconds, whereas a left turn from a residential road to another residential road might have only a one second delay.

Turn delays in seconds only affect the fastest routes, and have no affect on the quietest routes which are only concerned with how busy the route. To account for turns in quiet routes involves comparing a right turn with an equivalent cycling distance. Eg. are you prepared to cycle for an extra 100 metres to avoid a right turn off a busy road into a service road?

Choosing the right numbers for that is a bit of an art and a lot of experimentation. This is work in progress, and there’s a bit more to do before we can include this in CycleStreets routes.

Routing developer needed for short-term work

Wednesday, May 15th, 2013

We’ve obtained a £5,000 grant from the Technology Strategy Board’s Innovation Vouchers scheme, to work on some interesting routing challenges to help increase the quality of the routing we can offer.

Our core aim with CycleStreets is to create “routing that thinks like a cyclist”. One of these aspects is the way that cyclists treat junctions and turns, something that is not currently modelled in the engine. Another challenge that the grant can cover is our desire to incorporate changes to OpenStreetMap data into the routing engine shortly after they happen, rather than after a one-day import period. Both of these are challenging in the context of a routing engine that works over a heavily pre-compressed network and in an environment where expansion of hosting capacity is cost-constrained.

We’re therefore looking for someone with a computer science approach (as distinct from purely “web development”) who can work on these interesting challenges. However, we’d hope that a suitable person can help work on the website (e.g. backend/frontend integration, general web development, refactoring) as well where this is required to implement these changes.

If you are interested to discuss this further, please contact us (by Friday 24th May 2013).

The work must be completed by 31st July 2013, and we are required to work with a company we have not worked with before. The £5,000 includes any VAT we are required to pay by the supplier. The supplier must be a public sector provider or a registered company.

Background info: about our routing engine

The CycleStreets routing system finds, quietest, fastest and balanced cycling routes between two points in the UK (and other countries being added). It does this by building a route planning version of the map (known as a graph) for each of these types of route.

Each graph consists of vertices and edges that correspond to junctions and streets. On each graph the length of an edge corresponds to the cost for that route type of travelling along a street. So, roads and wide cycle tracks will have relatively short links on the graph for fastest routes, but the links that represent footpaths and bridleways where the cycling speed is slower will be longer. By contrast, on the graph for quietest routes, cycleways and park paths will be short relative to busy roads.

The optimal route of a certain type will then be the shortest path on the graph for that type.

So there are two main parts to the CycleStreets routing system: (1) Building the graphs (2) Finding the shortest path. The quality and performance of CycleStreets is governed by how well we do 1 and 2 respectively.

The current OpenStreetMap (OSM) map of UK & Ireland contains millions of paths and nodes. Streets are usually represented by their centre line, with nodes at junctions. The characteristics of each street, including for example the type of road, whether it is hilly, has a cycle lane, or is a one-way street are used to measure the suitability for cycling. In graph theory speak, they translate into the cost of an edge.

These costs are measured during our daily translation of OSM’s data into a graph by application of a series of rules.

Junctions – reducing wiggly routes

Simple graphs constructed from maps of street centre-lines lack are limited in their capacity to express how easy it is to cycle through a road junction. This series of photos introduces the problem.

In essence, the simple graph cannot represent banned turns, and nor can it indicate that a right turn across a busy road might incur quite a wait until it is safe to cross. However, some of the turn delay modelling can be derived automatically, knowing the ‘before’ and ‘after’ street types, and the turn angle. We believe that accurately representing that sort of information has the best chance of improving the quality of routes recommended by CycleStreets.

The way this route wiggles on and off Glasgow Road is a good example of this problem. (NB Click on the + button in the top-right corner of the map and switch to the OpenCycleMap view to get a better map background.)

Implementing turn delays at every node presents real challenges in terms of the use of a standard A* routing engine. This is further more difficult given the need to avoid very large amounts of RAM being needed.

Solving this problem is a significant technical challenge. It needs to be transparent so that there is a clear link between each piece of data and each rule used in the solution and the decisions that a knowledgeable cyclist would make. The solution must also be scalable, so that neither the amount of time taken to find a route nor the amount of data required to represent the problem, increase significantly. That will make it attractive and manageable. A solution also needs to avoid creating excessive hardware cost requirements.

England Cycling Data project

Monday, September 3rd, 2012

The England Cycling Data project aims to incorporate open data on cycling infrastructure released by the UK’s Department for Transport into OpenStreetMap.

We’ve started taking account of a greater range of information about cycle routes in OpenStreetMap (the project from which our routing is created). In particular, taking account of surface quality, barriers, traffic calming, and lighting in the routing, and have been continuing to develop this.

Earlier this year the DfT made available cycling data for England collected from surveying they undertook over the last few years. This has been converted to an OpenStreetMap-compatible format so that volunteers in the OSM community in each area can merge it in. The OS Open Data -based geometry has been ‘snapped’ to OSM geometries with intelligent matching of paths, and the metadata has been converted to using the OSM tagging system. This became available in June.

The conversion work has been undertaken by CycleCity Guides, who also did the original professional surveying for the DfT. The conversion work they have undertaken has been first-rate, and we’ve been impressed by the diligence taken, and accuracy of, the conversion process. We were particularly impressed by the skills of CCG’s GIS expert, Ralph Hughes. They seemed comfortable working with OpenStreetMap data and open data more generally as part of this process. We can certainly recommend CCG if you need professional surveying or data conversion work doing.

What’s in the data?

The data, licensed under the Open Government License, includes information on:

  • The National Cycle Network (Sustrans NCN), though this is generally already in OSM
  • Local Authority routes (again much of which is in OSM already, but this is a useful comparator), which helps us route cyclists over signed routes where practicable
  • Surface quality (which helps us avoid muddy bridleways)
  • The presence of traffic calming
  • Cycle lane widths (which means that we distinguish between a useful, wide cycle lane, and one which is much less useful to cyclists)
  • Whether a path is lit

The challenge now is to merge as much of this into OpenStreetMap as possible.

Andy Allan, one of the creators of the widely-used Potlatch 2 editor for OpenStreetMap, has created a new merging tool for OpenStreetMap. This was beta-tested earlier this year, and recent discussions on the OSM talk-gb mailing list have helped us identify some further improvements that will help assist the merging process.

How to merge in the data

Merging tool screenshot

We’ve created a screencast, which you can view below. But in summary, the merging process works as follows:

  1. Go to a Potlatch2 installation that has the data loaded
  2. Click ‘Map style’ > ‘Wireframe’ to make things much easier to work with.
  3. The background data is highlighted either orange (needs attention) or blue (already processed).
  4. Click a background feature to select it.
  5. Ctrl+click (or cmd+click on a Mac keyboard) the relevant OSM feature to see a side-by-side comparison of the tags.
  6. You can now review the tags, copy whichever ones are relevant
  7. Mark the background features as complete if there’s no more information to reconcile.

It takes about a day and a half to do a city the size of Cambridge (which has a lot of cycle infrastructure). Naturally, it does require local recognition of the area, but is a satisfying process.

What’s next?

We know that trying to get large areas of England in is a big task, and it will be interesting to see how the OSM community finds this in practice. So we’d welcome any feedback on your experiences with this data.

We’ve discussed with Andy Allan the remaining fixes needed to the merging tool, and have reserved funding for this. Clearly, we want to ensure this large task is made as easy as possible.

Shaun McDonald of ITO World has been working on some visualisations which we hope to report further on soon.

We’ve secured and written some articles for various widely-circulated cycling campaign magazines/newsletters, which we hope will raise awareness of OSM and introduce people to this data, as projects they could get involved in.

Estimating elevation inside tunnels

Tuesday, August 14th, 2012

CycleStreets has been using elevation data for several years to help avoid un-necessary hills in planned routes. The elevations we use are interpolated from open data surveys that provide an estimate of the height of the ground above sea level. The results of the processing can be seen in the elevation profile of every route planned on CycleStreets.

But what about paths and roads that run inside tunnels through mountains or under rivers? The ground level estimation is not relevant to them. How is that handled?

For straight tunnels through mountains the problem does not arise. The elevation profile for them is simply the height of the ground at each end of the tunnel, and appears like that in the route listing. For example this route through the Innocent railway tunnel in Edinburgh.

But when a tunnel has intermediate points showing how it curves beneath the surface the problem does arise because the elevation calculated at those points is the level of the ground above the tunnel. Without fixing this, routes though mountain tunnels appear as arduous and as slow as going over the top of the mountain, and routes under rivers appear as flat as taking the ferry.

To fix this CycleStreets now reads the tunnel=* tag from OpenStreetMap data and applies two new correction profiles:

  • Mountain tunnels are assumed to be as direct as possible between each end, so that the change in elevation along the length is a straight line, usually flat, (but can be sloping up or down).
  • River tunnels are assumed to dip linearly in the middle to 20 metres below the lowest end.

To determine which correction to apply, CycleStreets examines the flawed elevation profile. If it goes up between the ends it must be a mountain, if not, the river tunnel profile is assumed. The selected profile is used to correct the intermediate points and is completed before further processing builds the routing system.

As the elevation data is accurate to only 100 metres these measures are only applied to tunnels longer than 200m.

Monsal Trail Tunnel

This example shows how CycleStreets has interpolated a smooth profile for a tunnel that passes under a ridge, as shown by the map on this route.

Monsal Trail tunnel profile

Queensway Mersey Tunnel

This is an example of how CycleStreets estimates elevation through a river tunnel. These route options include a tunnel and a ferry route.

Queensway (Mersey) tunnel profile

 

Improved accuracy

Because tunnels are usually much shorter and faster than alternate routes these corrections to elevation inside tunnels are unlikely to make much difference to the choice of route offered by CycleStreets. But they do improve the accuracy of estimated journey times, calories counted and most obviously in the displayed route’s elevation profile.

Taking CycleStreets cycle routing another step further: surface quality, barriers, traffic calming, lighting

Sunday, May 20th, 2012

We’re pleased to announce a series of upgrades to the routing that have been rolled out in the last few months.

We’ve extended the range of OpenStreetMap tags that the CycleStreets routing engine uses to find cycle routes. This has helped us improve the quality of the suggested bike routes in two main ways: by handling the surface descriptions of the ways and accounting for the time delay caused by various obstacles along a route, as well as some other enhancements. This is part of an overall project (to be fully launched very soon) to help merge in some great new data from the DfT [see our blog post about the testing phase which is now completed].

The routing engine now newly takes notice, or takes more notice, of these aspects (where the data exists in OpenStreetMap) when planning journeys:

  • Surface quality (e.g. avoiding muddy bridleways)
  • All manner of hurdles (gates, bollards, barriers, kerbs) that can impede a cyclist’s journey
  • The presence of traffic calming
  • Presence on a greater range of established route (e.g. mtb)
  • Streets with a cycle lane only on one side
  • Whether a path is lit

Based on the feedback we’ve seen recently these changes are already improving the quality of routes served to users, but as ever we continue to monitor, tune and enhance the various parameters.

Surface quality has a major impact on the suitability of some routes for cycling. A few bridleways make excellent cycle tracks but the majority are usually deeply rutted a sometimes difficult even to push a bike when dismounted. Now that we are now doing more in our analysis of the tags to look at surface quality we’ve been able to significantly downgrade our default assumptions for the rideability of footpaths, tracks and bridleways. Only if they have tags that indicate good ride quality, such as tracktype=grade1 or surface=paved or surface=asphalt are they promoted to be considered cyclable as embedded in our routing sieve.

We’ve introduced the concept of ‘hurdles’ to represent the various types of obstacle found on cycle routes. Originally the only types of hurdle we recognised were traffic lights at junctions or crossings. They introduced an average delay of 20 and 5 seconds into our route calculations. Following on from our collaboration with the Department for Transport and CycleCity Guides we’ve been able to extend the coverage to more types of hurdle such as bollards, chicanes, speed humps and stiles.

In the routing system the hurdles add an average delay to routes and so routes with fewer hurdles are preferred. All the hurdles encountered are now included in the route listing pages, such as journey #2,163,046 which lists several cattle grids and a toucan crossing on just over a mile long route through Cambridge.

OpenStreetMap detail strongly encouraged

We hope these changes will encourage more mappers to add more details to OSM. These will actively improve the quality of routing we can provide to users and ‘think like a cyclist’. Every cyclist can tell of a barrier that has caused them annoyance and delay, and adding the data to OSM will help them avoid that.

A wealth of this data is now available as open data for you to merge in (manually) as this new screencast explains. A major new set of pages and an introductory blog post will follow on this shortly now that the data is available!

The OSM tags we’ve added support for are:

  • barrier=bollard
  • barrier=cattle_grid
  • barrier=cycle_barrier
  • barrier=gate
  • barrier=horse_stile
  • barrier=motorcycle_barrier
  • barrier=kerb
  • barrier=kissing_gate
  • barrier=lift_gate
  • barrier=stile
  • crossing=pelican
  • crossing=toucan
  • crossing=uncontrolled
  • crossing=zebra
  • cycleway:left=lane
  • cycleway:right=lane
  • ford=yes
  • lit=yes|automatic
  • surface=asphalt
  • surface=paved
  • tracktype=grade(1-5)
  • traffic_calming=bump
  • traffic_calming=chicane
  • traffic_calming=cushion
  • traffic_calming=hump
  • traffic_calming=table
  • traffic_calming=yes

Detecting presence on a bicycle route via these (though several were already in place):

  • (icn|ncn|rcn|lcn|mtb)=name
  • (icn|ncn|rcn|lcn|mtb)_ref=name

Or via a way’s presence on a relation that has type=route,route=bicycle.

More tags (cycle lane widths) and more detailed support to follow – stay tuned…

Cycle journey planning in Scotland

Friday, May 11th, 2012

Over the last year we’ve been pleased to work with Cycling Scotland on a range of projects, now all completed and outlined below.

These projects, which have been achieved thanks to Cycling Scotland’s grant and funding of £22k, will help improve improve CycleStreets, to help people find their way and consider cycling as a practical option for their journeys.

Cycling Scotland is the national cycle promotion organisation for Scotland, working to establish cycling as an acceptable, attractive and practical lifestyle option, and aiming to make Scotland a nation of cyclists.

Cycle journey planner for Cycling Scotland

The new Scotland Cycle Journey Planner has launched!

This is a customised, embedded site within Cycling Scotland’s website, enabling people to plan journeys from A-B directly within their site. It includes quick links to a number of cities in Scotland.

Community mapping guide

We’ve created a community mapping guide, which explains how people can help improve the data used for the journey planner. This is part of Cycling Scotland’s ‘Community Cycle Mapping’ project which encourages local communities to capture cycling-related information so that it can improve the journeys of others.

Finding out about good cycle routes – where it is safe and convenient to cycle – means availability of good maps and the knowledge of local people about their area.

The guide is also available on Cycling Scotland’s website.

Improving the routing by supporting more detailed street data

Part of the grant from Cycling Scotland helped us to add support for more detailed information coming from in OpenStreetMap. By interpreting things like surface quality, various barriers, etc., we can improve the quality of journeys that we can suggest to users, leading to ever-improving routes.

We also began work on supporting turn delays in the engine, to reduce the problem of wiggly routes in the journey planner engine. We hope to complete this in coming months. Finishing this will mean we can improve the practicability of routes that people follow.

Hosting fund contribution

The grant included a contribution towards hosting, which has ensured we can cover use of the main journey planner for Scotland for three years. (Donations, enabling us to improve the hosting across the UK, are welcome!)

Android app

The CycleStreets Android app, available FREE was released last year more quickly as a result of the grant.

The app is well-rated, at 4.3/5 with 99 reviews. Most reviews seem very positive and highlight how the app has helped them find better routes.

Mobile web site

The grant also enabled us to develop a new mobile small-screen version of our website. The site ensures that people can access the journey planner easily via their mobile, for a variety of types of mobile device.

It has just been honoured as a winner of ‘Best Application Design‘ by the usability expert, Jakob Nielsen.

OpenStreetMap community mapping guide – for Cycling Scotland

Tuesday, March 27th, 2012

We’re pleased to announce the availability of a new brochure that we’ve done for Cycling Scotland, aimed at motivating people to get mapping for OpenStreetMap.

Cycle mapping for cycle routing with OpenStreetMap – the new community mapping guide – explains how you can get involved.

Cycling Scotland is the national cycle promotion organisation for Scotland, working to establish cycling as an acceptable, attractive and practical lifestyle option. We’ve been working with Cycling Scotland to improve cycle journey planning in Scotland. The new mapping guide is part of their Community Cycle Mapping project to encourage improved cycling information in OpenStreetMap to help people get on their bikes.

(Although it’s been created primarily for use in Scotland, the principles and details in it apply elsewhere too.)

The Guide has been written by Andy Allan, who has been contracting for us on a few projects recently, with additional contributions by Martin from CycleStreets. Ayesha Garrett did the design work and has, once again, done a superb job. Thanks to both of them!

 

 

 

Merging tool – new cycling data

Monday, December 19th, 2011

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.

Background

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.

License

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.)

Feedback

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?

Merging tool for external data for OpenStreetMap

Monday, October 24th, 2011

Back in July we wrote about our work to assist the DfT with the opening up of their cycling data, a dataset featured in the Telegraph this weekend. Over the summer, much progress has been made.

Andy Allan, who is perhaps best known for his excellent OpenCycleMap project, has been working for us to create a merging tool (within Potlatch 2) for helping to combine external datasets into OSM on a street-by-street basis. This tool will be useful not only for the DfT data that is becoming available soon, but also for other datasets.

The DfT data, which has mostly been collected by surveyors on bicycles, has the potential to significantly improve the quality of routing in some areas of England. We are well aware, however, that data collected by other agencies can undermine the work of OSM volunteers in the area if not handled sensitively, and so we've stressed that automated, bulk imports would not be accepted by the OSM community.

Instead, the approach taken is a method for OSM volunteers to inspect and merge the information on a street-by-street and attribute-by-attribute basis via the simplest and quickest means possible, using their local knowledge to enhance the end result.

Surface type, cycle lane widths and other data are amongst the attributes in the dataset, and these will shortly be supported in the routing engine.

The code for the beta release of the tool [included in this diff] has been reviewed and merged into the main Potlatch 2 codebase, and is already in the latest builds. We expect further changes to be made as we get feedback from initial testers.

OSMers should be able to try out the beta and the data soon as we have confirmation of the Open Government License for the data. Here are screenshots of the beta:

We welcome your feedback, especially to report bugs or give us route feedback.

My comments relate to: *






Your comments: *
URL of page: * https://www.cyclestreets.net/footer.html
How did you find out about CycleStreets?:
Your name:
Our ref: Please leave blank - anti-spam measure

* Items marked with an asterisk [*] are required fields and must be fully completed.