Donate using PayPal

CycleStreets blog

News from CycleStreets

Archive for the ‘Routing performance/quality’ Category

Our talk at State of the Map 2019: Is the OSM data model creaking?

Sunday, September 22nd, 2019

We gave a talk at the State of the Map 2019 conference, the main annual meeting for OpenStreetMap, whose data we use for our cycle routing.

Our talk was entitled “Is the OSM data model creaking?”.

A video of the talk is now online:

Here are the slides from the talk:

Is the OSM data model creaking? (PDF, 16MB)

OpenStreetMap was designed to enable ordinary people to create open geodata that anyone can use and maintain easily. Traditional GIS concepts such as layers are dispensed with in order to make editing simple and accessible. In the same way that the web would never have taken off if HTML were not so accessible and tolerant of mistakes, this simplicity in OSM has meant a low barrier to involvement.

However, as OSM is becoming more widely used in the mainstream, the need for accuracy and quality is becoming more and more important. Cyclists need detailed turn data to enable high-quality routing that takes full account of safety. Satnav companies, need lane data, which is difficult to represent accurately. Pedestrian routing is barely in its infancy and high quality routing for people walking or using wheelchairs is hard to achieve.

At its root, OSM tries to represent spaces as flows (lines). This results in fundamental compromises and inaccuracies. What is good for routing is not always good for cartography, and vice-versa.

For instance, a street containing cycleways with pavements either side is usually represented as a single line with attributes. However, it is extremely challenging to represent properly all the parts of the street, and in general people simply don’t bother: a single line with large numbers of attributes is unwieldy to edit (even when hidden by editor GUIs), and just as challenging for a router to interpret. Continual changes in the width of a street cannot be easily represented without segmenting the street heavily and creating a mess. Temporary disappearance of lanes makes editing complex. Routing ultimately ends up as a lowest common denominator result.

The alternative method of representing this same street is as a series of individual lines. But this is equally problematic. In this model, the street loses its coherence as a single entity – humans think of it as a street with multiple uses (walking, cycling, driving, trees). Where people have done this, attributes such as street names need to be kept in sync, and in practice separate pavements often fail to have names attached. Concepts such as the ability to cross from one side of the road to the other (or even switch lanes) are not modelled, with the result that a router may take the user to the end of the street then back down. And cartography ends up showing a series of parallel lines which looks messy and does not match the human perception of a street.

The bicycle tagging page on OSM provides a perfect demonstration of the current problem: It shows the complexity of representing many common scenarios, with increasingly incomprehensible tagging combinations. No router implements anything like all of this, and even expert OSM contributors would shy away at bothering to add this data.

Cycleways indeed are a good general example of inconsistent tagging. Cycleways separate to a road are sometimes tagged as an attribute of the street and sometimes as a separate geometry. What about a hybrid/stepped cycle lane of the kind seen in Copenhagen – is that a cycle lane or a cycleway? Do lane counts include cycle lanes or not? How is obstructive car parking represented? Is the one-way indication applicable to the cycle lane on the road? And so on.

Another example is junctions. Should traffic signals be treated spatially (i.e. represent the location of the traffic heads), or should they be treated linearly so that routing works properly? How should the linear model work accurately when there is only a single geometry for multiple directions? Have a look at the roads around the Arc De Triomphe in Paris – it is completely impossible for a routing engine to work out exactly how many signal delays should actually be attributed based on the presence of the marking of traffic signals in the data:

This talk will discuss these cases, and provide a starting point for discussion on what should be done to improve the situation. As people are ever keener to add more detail to the map, and as more and more mainstream users look to OSM, we have to ask whether the current model is arguably creaking too heavily. Is there a way that we can represent spaces as a set of interconnected flows in some way?

The speaker, Martin Lucas-Smith, is one of the developers of CycleStreets, one of the earliest and most established dedicated cycle routing engines. As such, he has spent many years considering the kinds of tradeoffs represented by the current OSM data model.

Turn cost factors – for safer and less wiggly routes

Saturday, July 1st, 2017

Urban cycle routes can often be very circuitous because they have to work around one-way systems, tunnel under major roads, use paths across parks and short links connecting residential areas.

For many years now, CycleStreets has included the cost of making each turn in the overall process of choosing a practical cycle route. The model used so far has been basic – counting 7 seconds for a left turn and 11 seconds for a right turn. That’s helped reduce their wigglyness, but we’ve long known of the limitations of applying that model equally to all junctions.

In particular, experienced cyclists know that right turns (in the UK case) from busy roads are to be avoided. So one of our objectives for routing quality is to avoid unnecessary right turns.

Turning cyclists

Different strategies for making a turn

We’ve developed a more comprehensive set of criteria for assessing the cost of making a turn.

The new model takes into account the types of road on the approach to the junction, the likely traffic volumes, the right of way, turn angles, speeds and gradients.

We’ve built tools to help us assess the impact of these new costs on route choice and when ready we shall be rolling out this new model into the live routes suggested by CycleStreets.

This blog post gives a brief overview of the model.


CycleStreets measures cycle routes by totalising these two components:

  1. the cost of riding along each street
  2. the cost of turning at each junction.

The best cycle route between any two points is the one with the minimum total cost.

Cost factor Route type
Time Fastest
Volume of traffic Quietest

Because the total cost measure includes the cost of turning at each junction, the routes produced are already likely to contain fewer turns than they would otherwise.

As mentioned in the introduction, the cost model in use is a simple one that is applied equally to all junctions.

Existing cost model

The current model of turn costs uses basic physics to estimate the time added to a journey by slowing down to pass through a junction, and accelerating back up to speed afterwards. It is assumed that a rider starts braking evenly from 10 metres before a junction, and accelerates away afterwards reaching full speed after 20 metres.

When a full stop from a speed of 12.5mph is required, the total time added is six seconds. If the rider can maintain some momentum by slowing only to a walking pace the total time added is reduced: only 3 seconds.

Where the turn is bear left or right then the slow down model applies, but when there’s a sharper turn, the stop model applies with bigger delays.

The model includes a small extra factor to account for expected waiting time – slightly more for turning right than turning left.

But that’s it, and that is currently applied to all junctions regardless of the type of roads involved.

New cost model

The new model takes into account the road types at a junction.

For example, at a junction between residential roads where there is not much motor traffic it is safe to assume that in general the cyclist will not have to come to a full stop to make any kind of turn and that they can maintain their momentum. This means that those types of junction will have little impact on the journey cost.

Where a minor road meets a major road, the issue of right of way has to be considered. When turning left or right from a side road the rider does not have priority and so must give way to other traffic until there is a gap. For such turns there is a waiting time to be considered. The waiting time is likely to be higher for bigger roads.

Making good estimates of the waiting time for turns between different types of road will improve the quality of the recommended fastest routes.

By using a related measure, right turns onto busy roads (in the UK case) can be avoided when considering the quietest route.



Right for Newmarket 6 miles on roads, or left on National Cycle Network route NCN51, 15 miles.

Junctions can make routes complicated, but what does help is good sign-posting. Routes that are clearly marked are usually helpful to most cyclists passing through an area.

Where a junction is on a marked cycle route, the cost factor can be made very low for sticking on the route and punitive for leaving it. The result of such a scoring scheme would be ‘sticky’ routes.

The fastest route between Clerkenwell and St. Paul’s is shown as the red line. The green route demonstrates the effect of adding an expensive (i.e. unrealistically high) turn cost at every junction, except for those that lie on the stations circular cycle route.

Current status

A significant part of this work has been modification of the A* algorithm to enable direction-specific node delays. This has been running stably now for some time. The key issue remains tuning this to give realistic values for each junction scenario.

The new model for applying turn costs at junctions takes into account a wide range of factors. Current versions of CycleStreets routing are building these factors into the model, but they are not yet being used in live routing.

We’re at the stage now of creating a series of tests to ensure a smooth transition to this new model as we finalise the calibration of the new cost factors.

We are grateful for funding which has enabled us to undertake the research and development in this area.

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!




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

My comments relate to: *

Your comments: *
URL of page: *
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.