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…
12 thoughts to “Taking CycleStreets cycle routing another step further: surface quality, barriers, traffic calming, lighting”
traffic_calming is an interesting one.
You mention that you now treat it as a “hurdle”, but roads in a “20mph zone” often use traffic calming to help enforce the speed limit. Personally I quite like riding on these slower roads, especially if I’m plodding slowly along towing a kiddie trailer.
Hopefully traffic calming is only an obstacle for Fastest Route, but neutral (or even a benefit) for Quietest Route?
GrahamS
Yes, and this is something we’ve been discussing. Traffic calming can sometimes indicate a better environment or sometimes a worse cycling environment. The current first implementation for that tag is relatively simple.
How about cycleway=share_busway (where bicycles are allowed into bus lanes), makes highway=trunk much less threatening.
Excellent stuff. I’ve already started putting “surface” tags on pathways I map (as well as “bicycle=yes/no”) — I’ll start thinking about the other features you mention as well.
Another thought: do we have any suitable tags to indicate traffic calming that cyclists can bypass without penalty?
(e.g. chokers where the cycle lane cuts straight through the extended pavement; or speed bumps that don’t extend into the cycle lane)
@ Graham Stewart:
there is at least already traffic_calming=cushion (which seem popular around my way) which let cycles as well as fire engines pass through while being effective in slowing cars. I would consider these a good thing to have on a cycle route regardless of whether I wanted speed or quietness.
http://wiki.openstreetmap.org/wiki/Key:traffic_calming
http://en.wikipedia.org/wiki/Speed_cushion
Regarding other Chokers
And regarding your last comment, I’ve never seen a speed bump on a dedicated cycle lane (though given some of the craziness I have seen, I don’t doubt they exist) so maybe there needs to be some thought about what the default assumption of the router is in these cases.
This is great news.
With regard to traffic calming, I’ve used bicycle_bypass=yes to denote where a bicycle can avoid a traffic calming measure. I’ve used it with chokers and chicanes before. Likewise I’ve recorded bicycle_bypass=no in cases where there definitely isn’t such a bypass to make it absolutely clear. I’d say that the no-tag interpretation should be bicycle_bypass=no.
I’ve got a signifcant proportion of the maxspeed tagging completed in my area (east Kent), so I’m glad that these are now being taken into account.
The crossings in my area are tagged using the crossing_ref=toucan|pelican|zebra form instead of crossing=toucan|pelican|zebra form. I know that either form can be considered correct. Does CycleStreets also handle the crossing_ref form?
I would suggest that you also downgrade your default assumption for highway=path, since they are often similarly uncyclable as highway=track.
I have now initialized highway=path to quietness=50%, rather than 75% as a result of your suggestion. We should see the effects of this following completion of the next import run, which is due on Sunday morning.
Pingback: CycleStreets » Blog
Would it be possible to take into account surface for roads as well? Round Durham we have a few roads which CycleStreets tends to like to use but which are difficult to ride on because they have cobblestones (surface=cobblestone) or setts (surface=cobblestone:flattened). True cobblestones are dreadful to cycle on, especially uphill, and setts introduce quite a bit of delay. A delay for these surfaces would probably improve the routes round here. I appreciate this is different from hurdles, which are one-off delays, and different from the handling of the surfaces for bridleways, which as far as I can gather from your description just produce a yes/no as to suitability for cycling. The delay from cobblestones is in proportion to the length of the road.
Pingback: My Talk at State of the Map Scotland 2012 | Shaun McDonald's Blog