Donate using PayPal

CycleStreets blog

News from CycleStreets

Archive for the ‘Research’ Category

CycleStreets.net in the Propensity to Cycle Tool

Wednesday, December 21st, 2016

A guest post from Robin Lovelace:

After 2 years in the making, the paper describing the Propensity to Cycle Tool (PCT), and the thinking behind it, has finally been published (Lovelace et al. 2016). The PCT is an online tool for helping to decide where to prioritise cycling policies such as new cycle paths.

The PCT would not have been possible without CycleStreets.net, so as well as describing the PCT and its use of their routing services, this article serves as a big Thank You from PCT to CycleStreets.net.

What is the Propensity to Cycle Tool?

For those new to the PCT, it’s an online tool for helping to decide where to prioritise cycling policies such as new cycle paths. It lives at www.pct.bike – check it out!

The context of its development is explained in the accompanying video on that page. This article reports how the tool itself works and how it uses data from CycleStreets.net.

The PCT is best understood by using it to explore current cycling levels, at regional, area, desire line, route and route network levels. We will take a look at how the PCT works at each of these levels, after a brief look at the scenario results at the regional level (the senarios are described in more detail in the paper).

Under the 2011 Census scenario, the PCT represents levels of cycling to work based on the Census. This is a reasonable proxy for levels of utility cycling overall. We used origin-destination (OD) data from the Census as the basis of the PCT as this is best publicly available dataset on English travel patterns. The input data is described in the paper and can be freely downloaded from the official UK Data Service website.

The regional picture and scenarios

The first thing the user sees on the front page is a map of England, broken into 44 regions:

We used deliberately large regions because successful cycling plans should be strategic and joined up, covering both large areas and large spans of time. This discourages the stop-start investment plans that have typified funding for active travel.

By hovering over different regions, the user can see what the current level of cycling to work is. We can discover that West Yorkshire has a low current level of cycling to work, 1.3% in the 2011 census, and that Cambridgeshire has a relatively high (but low by Dutch standards) level of cycling of 9.7%.

An exciting feature of the PCT is its ability to allow the user to imagine ‘cycling futures’. This can be seen on the front page map by clicking on the different scenarios (set to Census 2011 by default). We can see, for example, that under the Government Target to double cycling levels by 2025, West Yorkshire’s level would rise to 3.3% (more than a doubling) whereas Cambridgeshire would see cycling levels grow to 13.7% (a larger rise in absolute terms):

plot of chunk unnamed-chunk-2plot of chunk unnamed-chunk-2

Under the Go Dutch scenarios, these regions would see 23.1 and 13.5% of people cycling to work, respectively. This represents a huge leveling-out of cycling levels across the country, but still highlights the fact that some regions have higher cycling potentials than others, due to average trip distances and levels of hilliness.

Cycling levels at the area level

To launch the PCT for a region, click on it. Try clicking on West Yorkshire. You should be presented with the following image, which shows the area-based level of cycling to work from the 2011 Census. (When using the PCT, it is worth remembering that the visualisations work for every scenario.)

This shows that West Yorkshire has very low levels of cycling to work, hovering around 1% to 2% in most places. This suggests strongly that the region has low levels of utility cycling overall (despite the successes of the region’s sport cyclists). There is a cluster of zones with a higher level of cycling to the north of Leeds city centre (around Headingly) but even there the percentage of people cycling as their main mode of travel to work does not exceed 5%.

Cycling potential at the desire line level

This is all useful information, especially when we look at how the cycling potential could shift in the future. However, it provides little information about where current and future cyclists actually go. This is where the desire line level can be useful. This can be selected by clicking on the Straight Lines option from the Cycling Flows dropdown menu. The results (zoomed in for Leeds) are shown in the figures below (see Figure 3 in the paper).

What the above figures show is that as the level of cycling increases in a city, the spatial distribution of cycling can be expected to change. Under current conditions (be they related to socio-demographics or infrastructure or other factors), cycling in Leeds is dominated by the travel corridor to the north of the city centre. Yet there are clearly many short trips taking place from the south into the centre, as illustrated by the high cycling potential south of the city under the Go Dutch scenario.

Allocating cycling potential to the route network

This is where CycleStreets.net comes into play.

We know how many people go from A to B by cycling from Census data. But we have very little idea of how they are likely to travel. This is where the routing algorithm of CycleStreets.net comes in handy. We used the CycleStreets cycle routing API to estimate the ‘fastest’ route for all short (well, up to 20 km in Euclidean distance) desire lines in England.

Not only does CycleStreets.net allow us to find all the fastest routes, a good indication of where new infrastructure should be built as people (especially women and elderly) have a strong preference for cycling along the most direct routes.

The results of all this routing work is illustrated in the future below, which shows the fastest and quietest routes associated with the top cycled routes in Leeds.

Interestingly, the big fat line up to the north-west is Otley Road, well-known to have very high level of cycling. This also shows up in Strava data as having high current levels of cycling:

This is not formal validation but it is a good sign that the PCT and other data sources line-up for the current level of cycling. The big question is whether the PCT’s estimates of cycling levels under various cycling futures, including Go Dutch.

Here is not the place to answer such a question. Only the passage of time, and commitment from people (perhaps informed by models such as the PCT) to sustainable travel will help answer that one.

There is much more to say about the use of CycleStreets.net in the PCT but it gets rather technical very quickly.
Suffice to say at this stage that it involved writing lots of code in R, a language for statistical programming, and that this has now resulted in the publication of stplanr, an R package for sustainable transport.

(For more on how to install R and (for bells and whistles) RStudio, which this blog post was written in, please see the relevant sections of the book Efficent R Programming (Gillespie and Lovelace, 2016).)

With R installed, stplanr can be installed with:

install.packages("stplanr")

With this package installed, you can start using the CycleStreets.net routing algorithm with the following function:

library(stplanr)
route = route_cyclestreet(from = "Leeds", to = "Cambridge")

which results in spatial data, which can be visualised as follows:

library(leaflet)
leaflet() %>% addTiles() %>% addPolylines(data = route)

There is much more I could say about the technical side of things but at the request of the editors I will leave it there for now. For more info please see the stplanr vignette.

I plan to follow this overview article up with a more technical blog post in the New Year. Watch this space!

Reference

Lovelace, R., Goodman, A., Aldred, R., Berkoff, N., Abbas, A., & Woodcock, J. (2016). The Propensity to Cycle Tool: An open source online system for sustainable transport planning. Journal Of Transport And Land Use, 0. doi:10.5198/jtlu.2016.862

Cycle commuting analysis of Bristol

Saturday, December 19th, 2015

We love it when our API comes in useful for academic purposes. This is a guest post by Richard Thomas.


Average time to cycle commute

Bristol: Typical cycle commute time

For my MSc dissertation, I investigated determinants of the proportion of people who choose to cycle for their daily commute. Specifically, I wanted to see whether an analysis of realistic cycling routes of a representatively large sample of a city’s population could give improved predictors over existing models.

From 2011 Census data, I extracted commuting origin/destination data for everyone in the Bristol built-up area in its most detailed form of aggregation (typically accurate to within 500m). I wanted to generate plausible cycling routes for these commutes, then for each of these routes to evaluate metrics (distance, hills, cycle paths, traffic). As census data is available giving the proportion of commuters living in each small area who cycle, multi-variate correlation could then be used to estimate the influence of these routing metrics, together with other known influential population measures taken from the census.

So how best to perform this cycle routing and evaluate suitable metrics? On both these counts the CycleStreets Journey Planner API proved invaluable (and made my MSc dissertation a feasible proposition!) I had considered using an existing open source routing engine (such as pgRouting or Graphhopper) operating on an extract of the OpenStreetMap database as this would allow me to directly query tags on each node of a route. However the complexity in interpreting OpenStreetMap cycle-related tags is quite daunting (as documented here on CycleStreets.net).

Because the API returned not just the route, but details of routed distance, duration, “quietness”, estimated calories required and spot heights, useful metrics could be derived quickly from the JSON data using just Python scripts. It would have been good to more directly quantify dedicated cycle infrastructure along routes: although the “quietness” measure included this, it also included road traffic expectations. Given more time, this could have been done by using the actual route coordinates to interrogate the OpenStreetMap or CycleStreets databases, though this was complicated by API-returned points being only in latitude/longitude format rather than database node/segment numbers. In order to limit the amount of data to be processed (and the load on the CycleStreets API server, routing was limited to the 4 most popular routes from each area, although this still required nearly 16,000 routes to be generated and analyzed!


Summed routes (detail)

Summed cycle commute routes (Overview)

The most notable results of these new routing-based metrics (i.e. beyond the key predictor of crow-fly distance) were as follows:

  • Directness (Crow-fly / Routed Distance): strong indication that cycling was less popular if a reasonable (“balanced”) cycling route was particularly circuitous.
  • Max Height Increase (Maximum of sum of all hill climbs for outward or return direction): strong indication (as might be expected) that hills were a strong detractor. This metric was only developed after the MSc was completed; interestingly, in the MSc analysis, the related metric of Effort Ratio (calories / distance) was not a statistically significant indicator.
  • Traffic Exposure (Inverse of “Quietness”): Although this metric visually gives a good indication of cycling routes along busy roads and/or away from dedicated cycle infrastructure it was not a statistically significant predictor of cycling. Although not conclusive, this supports other research showing that cyclists are more sensitive to time taken than to pleasantness or safety when it concerns their daily commute (priorities may be different for a leisure ride).

Summed routes (street level detail)

Street level detail (OpenCycleMap)

 

More details of the analysis are available in the full dissertation (or short synopsis). Detailed 2011 census origin/destination data (table WF02 for OA/WZ) was only made available after the end of my MSc (and then only to academics for specific projects). Thus for the MSc, synthetic data was generated based on (publicly available) census data. However, a later reworking of the full analysis using the new WF02 census data gave very similar results showing that lack of public access to detailed statistics need not be a serious impediment to analysis.

Beyond the key MSc analysis, an interesting spin-off of all the cycle routing was the development of maps (see right and below) that sums the 4 most popular commute routes from the centroid of each census Output Area, giving a good indication of the number of cyclists along individual streets if all these people were to commute by bicycle.

Thanks again to CycleStreets for making the API available to enable this research project. Data processing was done in Python and SPSS with additional processing and map rendering in the open source QGIS package.

Richard Thomas

Editor’s note: We now have a batch routing system available which we’re keen to encourage for academic use like this. It can handle millions of combinations happily – not just the 16,000 combinations noted above!

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.

Ideas In Transit survey on CycleStreets

Tuesday, March 20th, 2012

Interested in sharing your views and experiences of CycleStreets and other web-based travel information?

The Ideas in Transit Project at the University of the West of England Bristol is working with CycleStreets to investigate people’s use of CycleStreets and other web-based travel information. The project is looking at the ways in which people use technologies during and to organise travel – particularly where they do so creatively and to solve particular transport challenges they face.

We’d love to hear from you, and there is a chance to win £100 for completing the survey.

Please follow the following link to give your views…
https://www.surveymonkey.com/s/Cyclestreets

Hiring soon – to work on routing engine challenges

Saturday, May 21st, 2011

CycleStreets will shortly be hiring a full-time core developer to work on our routing engine and website. The aim is to enable us to implement improvements to the routing and implement lots of feature requests a lot more quickly.

This is possible thanks to a series of contracts and grants we've recently obtained, some of which we've recently reported about on this blog.

Our core aim with CycleStreets is to create "routing that thinks like a cyclist". This means including some things, such as turn delays and complex rules that would seem to be challenging to implement with off-the-shelf engines.

We're therefore wanting to take someone on who is able to work on what are interesting computer science problems (as distinct from purely "web development"). 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.

Background info: about our routing engine

The CycleStreets routing system finds, quietest, fastest and balanced cycling routes between two points in the British Isles. 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 2 million streets that pass through 20 million points. 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 UK & Ireland map into a graph by application of a series of rules.

That system is currently rather more complex and opaque than we'd like. Choosing the right values for all of those numbers has been an iterative process as we've tuned the routing engine, often in response to our user's feedback.

We need to:

  • Review the ruleset, re-examining the assumptions they are based on and the order they are applied
  • Make it much clearer to users how the rules have influenced the chosen route (this will confer greater confidence in the generated advice)
  • Include additional sources of information (more information to be published soon on this)
  • Handle junctions better, which is of particular interest currently.

Here in more detail is discussion on some of these:

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.

Finding the shortest path

Shortest path algorithms are very familiar to computer science students, and there are many well established standard techniques that solve the problem. CycleStreets currently uses the A* algorithm, which is implemented in a combination of a Python program and a C++ module.

The 2 million streets and 20 million points of the map, become 5 million edges, and 4 million vertices in a graph. These are compressed by a non-standard technique, called Cell Optimisation (Cello), into 2 million edges and 1 million vertices.

The Python/C++ program can scan the compressed graph to find a route from Land's End to John O'Groats in 2.1 seconds. The vast majority of routes we're interested in are about 10 miles, which can be solved by this program in milli-seconds.

The process of interpreting the generated route from a list of edges and vertices into an itinerary that includes street names and turn directions – the 'unpacking stage' – and storing in a database takes much longer. Performance seems to vary quite a bit, sometimes its very quick but it can take several seconds to process, even for a typical-sized route.

This issue will grow in significance as the number of users of CycleStreets continues to grow, and as new ways of using the routing system emerge.

We want to make the performance aspect of the routing itself, as well as the 'unpacking' stage, as fast and efficient as possible.

More types of route

There is a growing clamour for many more customisable types of routing. Ultra-quiet routes, routes where there is no dismounting and routes that are indifferent about hills.

We should also consider taking into account intermittent links, such as ferry crossing times, or gates that are closed at night.

Our system uses pre-compiled graphs, so each new routing type potentially means adding a new graph. Ulitmately RAM sizeputs a cap on that approach.

Are you the kind of person who can tackle these interesting problems?

We think that these and other challenges form interesting computer science problems.

Do get in touch if you'd be interested in an informal discussion to discuss things further. A formal job description and other details, including application deadlines and details will be online very shortly.

Interested in talking about your use of CycleStreets?

Tuesday, March 29th, 2011

Ideas In Transit

Fancy taking in an exciting new research project?

Interested in talking about your motivations and experiences of using CycleStreets?

The Ideas in Transit Project at the University of the West of England Bristol is working with CycleStreets to investigate how and why people use CycleStreets and what they think about it.

They are searching for people to help with their research:

We would like to interview you, the users. It would only take around 40 minutes of your time and we could meet you at your place of work or another suitable location (a library, café, etc.), whatever is easiest for you. We will be offering a £20 voucher for Evans Cycles to each participant as a thank you.

If you are interested in taking part, please contact Tilly at Tilly.Line@uwe.ac.uk.

CycleStreets iPhone app coming soon!

Saturday, May 22nd, 2010

In town somewhere unfamiliar and don’t know how to get home? Want to avoid a hilly area for your cycle journey? Know about main roads but don’t know the quiet route home? Found somewhere that needs cycle parking or infrastructure improvements which you’d like to tell others about?

An iPhone app has been the number-one feature request we’ve received over the past six months. So …

We’re extremely pleased to announce that we’ve obtained significant funding for a full CycleStreets iPhone app, from the Rees Jeffreys Road Fund.

The Rees Jeffreys Road Fund grant is for £5,000, which will be split between mobile development costs and improvements to the core journey planning algorithm/speed to support mobile use. We’re extremely grateful to the Trustees of the Fund for their support – their funding has enabled this much-requested new interface for CycleStreets to come about.

CycleStreets for iPhone will include the Journey Planner, Photomap (including photo upload) and other CycleStreets features.

We are also seeking further funding of £2-5k to cover the remaining costs. This will enable us to add more functionality more quickly, including getting the Photomap into the initial release.

We’ve engaged mobile developer Alan Paxton to carry out this work for us, who is kindly undertaking the Objective-C coding work below a commercial rate.

CycleStreets for iPhone will be released free of charge. (A future version may add paid-for features such as streetname voice emulation which have knock-on costs.)

Here are some early development screenshots!

Other platforms?

We would love to cover other platforms, in particular Android, as soon as possible, although we have no identified funding at present, nor do we have expertise ourselves in the coding required. Development time donations would be welcome from people with knowledge of developing for Android :)

It is also a high priority in our interface development programme to create a generic HTML interface more suitable for mobile devices, i.e. with bigger buttons, a cut-down feature set and quicker downloads. Again, we welcome offers of expertise or coding to help this happen more quickly!

Other mobile apps using CycleStreets routing coming soon!

Some other forthcoming mobile apps will be using CycleStreets routing, via our API – which is really great news! (These will include CycleStreets routing in some form but are not due to feature the Photomap and other parts of CycleStreets.)

Forthcoming apps include:

  • The exciting new BikeHub app, which will include a bike shop finder, journey planner and more!
  • For London, the London Cycle Hire App, which will help you find one of the 400 cycle docking stations in Central London so you can pick up or drop off a bike – and then plan a cycle journey from there!
  • TrackMyJourney, a Java-based app (targeted to Nokia, Sony Ericsson and BlackBerry platforms) for location tracking, map display, navigation and route plotting

If you have an app that would be interested in using our routing, do check out our API pages.

We are working solidly at present to improve the routing speed/resilience and deal with over-wiggly routes. Improvements will be experienced automatically by API users as we roll these improvements out.

Research-based routing

We are partners in a grant bid to one of the UK Research Councils with some academic colleagues in the other place (Oxford!) for a collaborative project to look at cycling habits and data collection to measure behaviour and impact of cycling interventions. We think there is a lot of scope for adaptive routing – a new field for cycling, and this grant bid is something we’re very excited about. It will require a lot more development work than the basic iPhone app outlined above will include. We are hoping to hear back within the next few weeks and have our fingers crossed!

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.