Journey planner help


Map key

The cycle map legend below describes the map symbols and lines:

OpenCycleMap map key

The main maps on this site come from a project called OpenCycleMap (which is part of the OpenStreetMap (OSM) project).

[Back to journey planner]

Icon How is the CO2 saving calculated?

Journey listings indicate how much cabon dioxide (CO2) is avoided by cycling the journey in comparison to how much is generated by driving the equivalent distance in a small petrol-powered car. The calculation is based on a CTC article that suggests the average saving of CO2 by cycling compared to driving a 100 mile car journey is 30kg.

We have had the following feedback about this:

"It seems to me that the CO2 saved should not based on driving the equivalent distance in a car vs. a bicycle. Rather it should be the difference between the most suitable car journey available and the chosen cycle journey. E.g. on getting directions from Stapleford to The Babraham Institute the quietest route is impossible for a car, so the saving in CO2 should reflect this, i.e. the saving should be much higher. This level of refinement may be tricky, but it is worth bearing in mind."

In response, in practice cycling will be more direct for some routes and less direct for others (e.g. when avoiding main routes), so in practice we think this is likely to be averaged out.

A related article of possible interest: How far do I have to ride my bike to pay back its carbon footprint?, the answer is "around 400 miles to cover the bike's initial carbon footprint.".

Icon How are the calories burned calculated?

An estimate of the calories burned on a journey was introduced to some versions of CycleStreets in Dec 2010. The figure given in the journey listing is an estimate of the amount of energy required to complete the journey. It makes these assumptions:

The resulting figure is shown in Calories (actually kcal) in the journey listings on those sites that provide this feature.

Calculations are based on this wikipedia reference and a spreadsheet from CTC (no longer listed on their site). They use this formula:

P = g * m * Vg * (K1 + s) + K2 * Va2 * Vg

In this formula, the power is made up of three components:

Parameter Description Units Value
P Power Watts
g Earth's gravity m / s2 9.81
m Mass of rider and bike inclusive kg 90
Vg Ground speed m/s 12 mph is about 5.4 m/s
s Grade or slope % assumed to be flat, ie. zero
K1 A lumped constant for the rolling resistance dimensionless 0.0053 (equivalent to a slope of 0.5%)
K2 A lumped constant for aerodynamic drag kg/m 0.26  see note
Va The rider's speed through the air m/s

Note: The wiki reference quotes K2 = 0.185 kg/m, but that is for an aerodynamic bike with a drag coefficient of 0.7. The value of 0.26 is based on a drag coefficient of 1.0.

On the flat (s=0) at 12 mph ( = 5.4 m/s), when there is no wind this gives a power of:

P = 9.8226 * 90 * 5.4 * (0.0053 + 0) + 0.26 * 5.42 * 5.4 = 66.2 Watts

To convert this into energy burned by the rider, we note that 1 joule is approximately 0.000239 kilocalories (kcal) and an athletic human body is 24% efficient. The conversion factor is then 0.000239 / 24% = 0.001, and so in this example our rider burns approximately 0.07 kcal per second. On a 20 minute ride they would burn 80 kcal.

A raw eating apple has about 50 Calories.

[Back to journey planner]

Why has it sometimes produced an odd route?

The journey planner sometimes fails to find a route or produces a strange route. These are the main reasons why, which we continue to work to improve:

There is some sort of problem with the route, but exactly what has yet to be determined.
Too far:
The start and finish points are further apart than the current limit in the system. We shall raise this limit in the future when we are confident that the system can produce better quality long distance routes.
Too busy:
When a route is suggested that uses very busy roads where there are quieter alternatives. The underlying problem may be missing links or that the map data in the area may not include all the quieter options. The fastest route only considers cycling speed and the delays caused by traffic signals. We've discovered that this is 'too pure' and leads to some very busy routes being suggested. We have plans (Nov. 2010) to fix this by mixing in a measure of the quietness of routes.
Too meandering:
When a route is suggested that goes much further round than expected. This can happen if the map data in the area is not well enough connected, or perhaps if there genuinely is not enough permeability.
Too arduous:
Because the algorithm does not currently take into account inclines it sometimes suggests a hilly route even when there are easier alternatives. We have started to work on this problem and have so far found some good sources of elevation data. This will allow us to estimate how much a cyclist slows down or speeds up on hilly terrain and should lead to more contour hugging routes.
Too wiggly:
This happens where a suggested route turns into back streets rather than using a more direct route in order to avoid a traffic light or to use a very quiet section. Athough it might be technically quicker or quieter to use the wiggly route it makes the journey a lot more complicated, and not necessarily quicker or quieter in practice. We have started work to reduce this effect, and for instance making the suggested journey 'stick' to a designated cycle route.
Missing link:
This happens when a route takes an unexpected diversion at a junction or crossing instead of using an under pass or known direct crossing. The usual cause is a missing link or if the crossing is not joined up correctly to the neighbouring routes. This problem can usually be identified quickly by CycleStreets' route editors. They report it to the OpenStreetMap (OSM) project and contact a local OSM contributor who can review the map in that area. A fix can be in the system in as fast as 2 days, though it usually takes longer.
CycleStreets used to have problems handling estuary areas, but new routes should not suffer this problem.
Something else:
There is a problem but none of the other descriptions explains that. Over time these will be reviewed and further problem categories created or merged as the system evolves.
A copy of or reference to another route with a very similar problem.
No Dismount:
Where a route is requested that requires the rider to stay on the bike but that starts or finishes in an area only accessible on foot. There are plans to make this dismount option more intelligent, so that the rider stays on their bike as much as possible, but allows them to dismount for occasional short sections.
Too muddy:
Where the route makes use of too many footpaths or bridleways because they are direct even when practical and quicker alternatives exist.
The feedback was to thank us for providing the system or to say that the routes suggested were helpful.
Inaccurate map data:
A link where there shouldn't be, a path that is permanently blocked, or blocked at certain times of the day or night. A link that is marked as cyclable or walkable but is not.
Wrong translation from OSM data:
This problem arises from an incorrect interpretation of the underlying OSM data. For instance in the early days where it had marked a Service Road in OSM that was interpreted as a Busy Road in CycleStreets. We've since added Service Roads to CycleStreets and that has fixed a lot of routing problems. This class of error happens also if for instance an access tag such as foot=no is improrperly handled.
Edge case:
The expected route was not found by CycleStreets. Instead other routes are displayed. This can happen when the expected route is probably about as fast or quiet as the routes shown. Currently the system only chooses one route of each type, even though there may be almost equally good alternatives. Try re-planning but moving the start / finish points slightly to see if the expected routes is found.
Ferry routing:
There are some occasions, particularly within Central London where Ferry routes are used too much for the quietest route. We are aware of the problem and are looking to improve this case. On 16 November 2010 we've made a change so that journeys cannot start or finish at nodes in the middle of a ferry route. This eliminates a number of problems.
Not a routing issue:
The feedback was about something other than a journey planning issue.
Ignores turn restriction:
CycleStreets does not yet have support for turn restrictions. This may mean that it provides a route through a junction where there is a banned turn, and this is one of the reasons why we say that CycleStreets is still in its beta testing phase. We are working to add this knowledge to our routing system. It is a bit of a chicken and egg problem because when we started the project there were very few places in the map data that had the turn restrictions marked. Now they are much more common it is right to prioritize including them in the routing.
Scheduled closures ignored:
Currently CycleStreets ignores timed closures of routes. This may mean that it suggests a route that is barred by a closed gate at certain times of day. As the quality of this information from the (OSM) project improves over time we shall seek ways of including that in our routing system.
CycleStreets lag:
Changes have been made to the map data at the (OSM) project, but these have not yet made their way into the CycleStreets routing system.
Test submission of feedback, to be ignored.


  1. The current limit on journey length is 186 miles, 300km.
  2. Naismith's Rule suggests how hilly terrain affects speed.

[Back to journey planner]

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.

Warning / disclaimer | Powered by CycleStreets Powered by CycleStreets