Overview of CycleStreets

CycleStreets is a system of two parts. It is created for cyclists, by cyclists. This section tries to give an overview of what it does and how it works.

1. Cycle journey planner

The UK-wide cycle journey planner (covering England, Wales, Scotland and Northern Ireland), enables you to plan a cycle route from A-B. Route planning is one of a number of things which help people to start cycling. Select a start and end point, in each case either by clicking on the map or searching by name or postcode.

The journey planner will return three choices: a fastest route (generally suitable for more confident cyclists), a quietest route (generally avoiding busier roads), and a balanced route giving the best of both (generally suitable for an average cyclist). The journey planner will do its best to avoid hills where possible. The route listing includes photos that have been submitted to the Photomap (see below) to help illustrate the journey.

We aim to provide the leading cycle route planner in the UK. As cyclists ourselves we are familiar with the real needs of cyclists undertaking their daily journeys.

2. Photomap

The Photomap is the second half of the system. It is basically a map with cycling/transport-related photographs added and pinpointed to a specific location on the map. The Photomap intended for cycle campaigning purposes, to enable people to highlight problems (e.g. a lack of cycle parking or a poor-quality cycle lane), or to give examples of good practice that others can point to.

We encourage people to add photos of their area. To do so, firstly create a free sign-in account (top right) and then use the 'add a photo' link in the Photomap area. Once a photo has been added, you will be asked to pinpoint it on the map, as well as adding a category (e.g. 'cycle parking', 'road environment', etc.) and whether the photo shows something good or bad.

Homepages for 1,500+ towns/cities/districts around the UK

As well as the UK-wide version of CycleStreets at www.cyclestreets.net, local versions of CycleStreets have been set up for towns, cities, metropolitan districts and boroughs all around the country, e.g. cambridge.cyclestreets.net . These versions of the site focus the map on that area, and limit the photos in the Photomap with a 5-20km radius. (Route-planning is not restricted to the area concerned, however.) The local versions are otherwise the same as the UK-wide version.

Branded versions for Local Authorities and others

We are very willing to create branded versions for Local Authorities (and others) which are specific to their area. Please contact us to discuss requirements and funding.

A wider programme of rollout to Local Authorities and others is projected once the route planning has reached the high quality standards we have set ourselves.

Community-based, not-for-profit

CycleStreets Ltd is a registered company based in the UK. Our governing documents include a not-for-profit clause as we strongly believe that CycleStreets should maintain its roots as a community venture, whilst offering a good service to cyclists and a professional outlook to organisations such as Local Authorities who wish to offer a cycle journey planning facility on their website.

The map data: where it comes from and how you can contribute

CycleStreets uses map data from ground-surveys conducted by volunteers, who add their data to OpenStreetMap (OSM). OpenStreetMap is like a 'Wikipedia of maps'. Although not all areas of the UK have full coverage yet, areas are being completed rapidly. Southern areas of the country, as well as larger cities and towns, currently have the best coverage. Areas like London, Cambridge, Edinburgh and many more have incredibly detailed coverage, rivalling every other source of map data.

Anyone can contribute by adding map data to OpenStreetMap, at a variety of levels. Most easily, you can go to the OSM website and (after registering, free) click to add points of interest (e.g. a bike shop). At a more advanced level, if you have a GPS device, you can record road and cycle route data from your riding and, on return home, upload this to the OSM website, adding information that you have collected such as road name and type.

You can also contribute by fixing any errors you spot in the data (e.g. a one-way-street marked the wrong way), and we have a group of volunteers who handle route problems and correct map data where necessary.

People sometimes ask why we don't use Google Maps. The reason is simple: Google Maps only provides a picture of an area and not raw data. Without raw street data (i.e. list of all streets/paths/locations in the UK), routing is not possible. Although Google provides a route-planning interface, it is not specialised for cycling.

The other main map provider in the UK is the Ordnance Survey. However, we are unable to use their data because (1) We do not have the funds to pay for a licence fee; (2) It is missing key cycle route data; (3) It contains unacceptable licensing conditions; and (4) Cyclists cannot contribute to it.

How we use the map data

We take an update from OpenStreetMap (OSM) data several times a week. This means that CycleStreets will plan routes through the street/path/location you added within only a few days.

Having obtained the data we translate and covert it into the optimised format that CycleStreets requires. This process runs overnight and takes over 12 hourson our current high-speed server. The import includes a process called Cellular Optimisation (Cello) which effectively compresses the data, reducing the overall volume of data to a fifth or so of what it was originally. Effectively cello pre-computes the possible solutions for travelling through groups of streets so that the route-planning engine operates more quickly. Cello operates in the three modes (fastest/quietest/balanced routes) in both directions, so six solution permutations are stored.

In translating the OSM data, the system interprets a variety of 'tags', and we are continually refining the data to route over it as accurately as possible. As time permits, we are adding more map features to refine the routing quality. For instance, if there are steps in a walkable section the journey planner will now take account of this in deciding whether to avoid a longer section that can be cycled. CycleStreets does not yet take into account the finer details of riding surface or the width of obstaclesbut these are projected to be added, and we encourage OSM ground surveyors to add this data.

A variety of other compression and normalisation techniques take place during the import data phase. These tend to involve heavily-optimised, complex SQL statements, to enable efficient, one-shot batch processing.

Most day to day cyclists want to avoid un-necessary hills. The data we use for hills is based on a US satellite survey, known as STRM. Because it is satellite data it only has a resolution of about 90 metres (i.e. the height is sampled at points on the ground 90m apart), but in practice this has proved good enough so far to improve the quality of the recommended routes. The journey planner takes the hills into account by adding a time delay when hill climbing and a saving when descending – known as Naismith's rule. As the quality of the routes improves we plan to get higher resolution elevation data from another satellite survey system known as ASTER (which has a 30m resolution).The final stage of processing copies the compressed routing data to a 4GB RAM drive. Indeed, the whole live journey planning phase is done entirely in RAM, without reference to disk-based storage.

The routing engine

The routing engine is a custom-written engine created by Simon Nuttall with advice and input from other developers. It mixes raw uncompressed data and cell-optimised data (see above) and operates in the three modes (fastest/quietest/balanced routes) and takes account of a variety of factors such as hills.

The engine is currently based around the A* algorithm. It firstly scopes out an ellipse around the start and end point and fills the ellipse with the compressed routing data. The router then scours through the possible routes from the start point to the finish point. When an optimal route is found the routing data is expanded to produce a detailed itinerary.

The core routing code (as well as interface binding code) is written in Object-Orientated PHP, and this handles the mathematical phase of the journey planning after extracting the database data. Although PHP is not as fast as, say, C, it has the benefit of being quick to develop in and accessible to a wider range of programmers as the system becomes open-sourced. The improvements in specialised array handling in PHP 5.3+ are employed to optimise stack processing.

We are continually refining the engine to increase both the quality and speed of its processing, as well as to cope with the ever-increasing volume of data coming from OpenStreetMap and the range of detail it can contain.

The cartographic map base

A variety of cartographic renderings of the OpenStreetMap data are available, and one is needed so that a map can be clicked on. (Generally these are much more detailed than Google Maps, which for instance omits much park path data.)

CycleStreets currently makes use of one of these, Andy Allan's excellent OpenCycleMap rendering, which attempts to highlight key features of interest to cyclists (e.g. bike shops, crossings, Sustrans routes, etc.) whilst reducing the dominance of features such as motorways which are of little relevance to cyclists. It also is fairly unique in showing topography (hills).

Open-sourcing

We fully intend to open source CycleStreets in due course so that people in other countries might be able to set up their own versions, and so that the complex routing engine can be improved by a community of programmers. We plan to do this once key security audits have taken place of the code and once the engine has matured and stabilised (the engine code and the database schema are subject to ongoing revision at present).

In the meanwhile, we encourage anyone who would be interested to join our coding team to get in touch. We are gradually publishing the technical documentation about the system as time allows.

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