Donate using PayPal

CycleStreets blog

News from CycleStreets

Intern vacancies Summer 2018

April 11th, 2018

CycleStreets is seeking one or more paid interns to work on a variety of projects this summer.

About CycleStreets

CycleStreets is a social enterprise based in Cambridge, working to help get more people cycling by the provision of information on cycle-friendly routes, and various tools for use by cycle advocacy groups.

We are best known for our journey planner, aimed at finding practical cycle routes in urban environments. To do that effectively requires collating data from a variety of sources and configuring a routing engine to make the same decisions a knowledgeable cyclist would make to find a route to their destination. We are aiming to provide the highest quality cycle routing in the world that tries to ‘think like a cyclist’.

Our bike routing is used by our own website and apps, as well as in a range of third-party apps (such as Citymapper, Bike Hub, London cycle hire apps, etc.), as well as a variety of transport companies (SDG, Virgin East Coast, mxdata, Traveline Wales/Scotland, etc.). It is also being used for academic research and transport planning, e.g. the Propensity to Cycle Tool and CyIPT projects.

The website also includes our Photomap – around 80,000 user-contributed photos of cycling related infrastructure from around the UK and beyond. These are used by activists to promote good practice and highlight problems to avoid in future. The Photomap also powers Local Authority websites such as the Urban Cycle Parking website for TfL. Further tools that present transport data that affects cycling are also in development.

CycleStreets also manages Cyclescape, a geographically-based discussion forum increasingly used by cycling campaign groups across the UK.

With our limited resources given over to focussing on keeping the core services up-to-date and responsive several areas have been left lagging and with work to do. We have a powerful API suite, but the front-end website and apps do not currently reflect its abilities in design and UI terms.

A wide range of potential development areas

Although improvements to our main codebase – the website – is our ideal focus, we’re happy to see work on any of our projects – routing engine, mobile apps, Cyclescape, etc.

The codebase for the main website is a rich collection of page-generation code, database procedures and webpage classes, system configuration scripts, and a low-level routing engine implementation – all written in commonly used mainstream languages. The codebase has been reorganised thanks to help from a previous year’s intern. This codebase primarily consists of over 200 PHP classes, using traditional inheritance/loading techniques, arranged as a fairly purist MVC structure. Much of the core functionality has been converted to a public API (with over 40 calls in total) that powers the website and third-party apps/sites.

Much of our code is on Github and we are trying to get the main website there too.

Some specific areas which we would welcome help with (though this is not exhaustive) include:

1. System coding and refactoring

Ours is a large codebase, with large amounts of functionality. There is always plenty of development that can be done throughout the system. Our previous intern’s work on refactoring was particularly beneficial and further work can be done; new functionality is also very welcome.

2. Overall website design, including integration with mobile

There’s an opportunity to update how CycleStreets presents itself to give the service a ‘personality’ – particularly on mobile. Here we’re mainly thinking about the look and feel but also what can be done with it. The codebase can serve webpages based on templates, and these are ready to be used by responsive stylesheets that will work on a variety of screen widths. Developments in this area could provide a major benefit to users on mobile In general, we are aiming to unify our various interfaces into a single implementation.

3. Usability

Interaction with the journey planner works smoothest on desktop but there is a lot of scope for improving mobile interactivity. Interaction of the journey planner with the map is one area that needs work, but there a lot of small things that would help such as, for instance prompting users’ frequently used locations when they search.

4. Cycle route quality

Changes to the cycle routing engine are perhaps beyond the scope of a summer intern, unless you are starting from a more advanced base of knowledge. A major challenge is how to know if the suggested cycle route is good – and whether changes to input data or configuration parameters produce a better route or not. Ideas and developments of the testing regime could make a significant difference to route quality.

5. Elevation data

The routing engine takes into account the cost of hill climbing and that depends on accurate elevation data. There’s scope for adding to our library of data provided by countries such as Australia and Finland.

6. Geocoding

Maintaining an up-to-date way of translating text into a location has proven quite a distraction over the years. We’d really like to get on top of this issue and resolve it once and for all. It’s quite a well-defined isolated project, primarily involving sysadmin and code integration work.

7. Work on our mobile apps

If you have skills in Java for Android or Objective-C/Swift, we would also be willing to consider work on these also. The apps have been created by colleagues rather than the two of us who will be running the internship; accordingly we can’t provide training on the actual programming languages, but things like code structure and UI would be possible to be covered. A new design has been created and is almost ready to be implemented.

8. Bikedata site

We’ve been working to get lots of public data on our new Bikedata site. There are many ideas for development here – new layers, new features, graphing, visualisations, API improvements, etc.

About the internship

This is an opportunity to get involved with a live and dynamic project that faces continual resource challenges. The successful candidate will have a choice of which projects to work on based on their own preferences and ideas. We’ll provide supervision and work together to define goals and help solve problems.

As an intern, you will be a proper part of the CycleStreets team, as a fully-paid employee over the summer period, with daily training and co-working.

Read about how our previous intern, Patrick, found the process.

The intern will be hired as an proper salaried employee. Our intern(s) will earn £400 per week, are regarded as part of the team from day one, and the internships last for 10 weeks. We will also come to a flexible arrangement regarding working locations and/or expenses for public area working to ensure that the successful employee is never out-of-pocket.

The paid internship will be based in Cambridge (UK). This is because we feel it is important that there is daily contact as this is aimed to be a two-way process providing lots of training.

As our two current employees work mainly from home, we’ll expect the intern to find their own workspace as we cannot provide an office environment. We’ll meet with you to discuss and plan your work schedule and ideas at internet cafés or meeting rooms in Cambridge, as well as online.

We are not expecting someone with many years of development experience, as such a person would be in a stable job, and the salary level is not intended to reflect this. What is more important to us is someone with the right mindset, a fast learner, who can work at a good rate. Being an internship, this will be a two-way arrangement, with us helping give the student knowledge of working in a large codebase and the challenges this brings – though we do want someone who is a self-starter.

How to apply

To apply, all we need is your CV and a covering letter, sent via e-mail by the end of Monday 30th April 2018. Your covering letter should explain your interests, and include some thoughts on our site (such as a critical analysis, max 1 page), and point us to any code you have written (public code on Github is always a good sign). Feel free to contact us if you have any questions.

We will contact all applicants by the end of Tuesday 1st May.

Interviews will take place on either 2nd/3rd May, according to your availability.

PhD studentship with University of Leeds: Towards data-driven policy development: the case of London’s built cycling infrastructure

April 10th, 2018

An exciting PhD studentship opportunity which we are involved in, cross-posted from the Data Analytics and Society Centre for Doctoral Training website.

Towards data-driven policy development: the case of London’s built cycling infrastructure

In 2013, £913m of funds was allocated over 10 years for investment in London’s cycling infrastructure. Much of this — including guided quietways, protected cycle superhighways and London’s crossrail for the bike — opened in summer 2016. The chief objective: to make cycling ‘a normal part of everyday life  […] something people hardly think about […and] something everyone feels comfortable doing’ (Greater London Authority 2013).

Traditionally, attempts to evaluate such interventions might rely on survey data describing changes in *claimed* behaviour or high-level data from Automatic Traffic Counters describing infrastructure occupancy. The former are often expensive to collect and suffer from numerous (well-documented) biases and the latter are too high-level to capture more subtle changes in behaviour.

This project will instead use new, large-scale observational datasets – from London’s bikeshare, underground and bus network, from route planning services (CycleStreets.net), user-contributed and social media data —  to describe changes in city-wide cycling behaviours pre- and post- the intervention. Crucially, it will identify rich detail around the impact of current investment on behaviour and contribute quantified estimates, under uncertainty, around the impact of future investment.

Applications are welcomed from those wishing to develop expertise in statistical model building, geospatial data and information visualisation.

Start Date: October 2018
Lead Supervisor
: Roger Beecham (University of Leeds)
Other Supervisors: Robert Aykroyd, Robin Lovelace, Stuart Barber
Partners: University of Leeds
External partners: CycleStreets.net

Read more and apply online here.

Every GB road collision – mapped

October 1st, 2017

As campaigners for getting more people cycling, a crucial issue for us is safety of our streets. Safer streets means more people cycling – as places like the Netherlands and other European cities show.

Every year, the Department for Transport issues a massive data release, detailing every reported road collision in Great Britain, what vehicles were involved, and the outcome in injury terms. Known as STATS19, the data contains around 60 pieces of information for every collision – whether slight, serious or fatal. This is excellent work by the DfT who collate this.

We’ve plotted every collision, and made available the full details, on a map on our new Bikedata website.

The data for 2016 has just been released – we got it online within a few hours of its release.

The site is a beta – the two things we want to improve are removing the jumpiness of the icons, and dealing with the question of how to show large numbers of collisions when zoomed out – currently a limit is applied. Zooming in shows all.

Since the data was first made live, we’ve fixed a few issues. The latitude/longitude values in the original data were incorrect, so we’ve reprojected these from the northings/eastings values which are the original data. Some data in London was also misnumbered, which the DfT have corrected after we pointed this out. Our interface also was not filtering correctly for car occupants – now fixed.

For every collision, you can click to get full details – available openly without charge.

 .  

Behind every one of these is a human story:

Users of the site are finding that the visual display enables patterns to be spotted – such as the way that the typical British roundabout design fails cyclists:

as do junctions more generally:

We’re now working to add new comparison facilities – we want to bring out the policy implications hidden in this data.

For instance, how do different Local Authorities compare? What happens when streets are upgraded to add safe, segregated infrastructure? How can we most easily demonstrate that allowing two-way cycling in one-way streets is a perfectly safe improvement.

We’ve also wanted for a long time to link these to newspaper reports and are considering methods to enable people to do that.

Let us know what you’d find useful.

Developers – need cycle parking in your app? Use our Cycle parking API

August 29th, 2017

This is a post for app developers. So it contains some techy stuff which probably won’t be of interest to our cycle routing users.

Knowing where you can find cycle parking as a cyclist, especially in cities, is helpful in avoiding theft, as well as helping keeping busy streets tidy.

By providing information on where cycle parking exists, developers of apps can easily help people find cycle parking before they even reach their destination.

CycleStreets provides a Cycle parking API as one of the points of interest (POI) types that can be retrieved in our extensive cycling API suite. Developers can embed this in our app – either by making realtime calls or obtaining the data en-batch using the CSV export mode.

You can see an example implementation on our new Bikedata website:

The API provides the following data:

  • Locations of all cycle parking in the UK and other areas that we support (much of northern Europe and various cities around the world – contact us if you need other areas)
  • Whether the parking is public or private
  • Number of bikes that can be parked (where data is available)
  • Details of whether the cycle parking is covered, what type of stands, etc. (where data is available)
  • The location of the entrance point rather than the centre point (for larger installations, where data available)
  • (Coming soon) Large areas of parking to be available as areas rather than (entrance) point

By default, all locations (whether public or private) come through, but you can specify a filtering option (as seen in the Bikedata example) if you wish.

We perform a range of pre-processing to enhance the raw data:

  • If the location is on private land, but the parking itself is not marked as such, we pre-process the data to mark it as private
  • For larger installations such as cycle parks, we use the entrance point as its location, rather than the centre-point
  • We convert data defined as either points or areas into a unified set of points

This data is all possible thanks to the power of OpenStreetMap. We regularly import OSM data, perform a range of processing on it (e.g. convert locations on private land into private POIs, determining entrance points, etc.), and turn this into an indexed API.

Our API is a flexible, robust and well-maintained interface (it has been running since 2010). If you need a Service Level Agreement, or are likely to require high volumes of requests, we can also provide the API on a contractual basis.

To get started, just obtain an API key, and set your application to make API calls to the POIs API and render the GeoJSON response on your map.

If you would like to request any enhancements to the API, to cover your use-case, do get in touch.

Also, if you have any existing cycle parking data, we are happy to provide advice on how to make it available.

Turn cost factors – for safer and less wiggly routes

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.

Junctions

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.

   

Legibility

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.

Bikedata beta – data for cycle campaigners in one place

June 11th, 2017

We’ve been working on a new website, Bikedata (working title), providing cycle campaigners around the UK with a ‘one-stop shop’ for data that helps them in their work.

Today we announce the open beta of the site – ready for you to try out, but we know there are bugs.


Collision data

Helping campaigners campaign

Getting more people cycling means improving the infrastructure on our streets so that everyone, whatever ability or level of confidence, is able to cycle easily and safely.

To achieve this, cycling campaign groups around the country work daily to make the case for cycling. They look at traffic consultations, propose changes to the highway, scrutinise planning applications, and work with local people and their local council to achieve these improvements.

Getting changes on the ground involves both a solid factual case for improvements as well as making an emotional case. For instance, reducing speed limits to tame traffic relies on having good access to collision data to demonstrate that there is a problem.

Thanks to our Outlandish Fellowship and some kind follow-on funding, we’ve been working on Bikedata, which is now ready as a beta site. (Beta means there are some problems we know about still but it’s good enough to start making public.)


Traffic counts

Data to make campaigning easier

The site gives you direct access to UK data for:

  • Collisions
  • Planning applications
  • Traffic counts
  • Cycle theft
  • Trip length (from CycleStreets journey planner)
  • Problems reported by cyclists
  • Photos (72,000+ images) for campaigning
  • Cycleability ratings of every street and path
  • Campaign groups around the UK



Cycleability ratings

In most cases, you can use filtering controls to show what you want to find. For instance, you can filter collision data to showing serious/fatal collisions at junctions. Or, perhaps you’d like to see all the reported places where cycle parking is needed:



Cycle parking problem locations – filtering in action

You can enable multiple layers at once. Our aim with this in the future will be to enable various correlations, e.g. showing how high pollution and traffic levels in an area might result in low levels of cycling.

You can also (again in most but not all cases), draw over an area to filter for that. Some layers also have an export facility enabled, so that you can easily obtain a spreadsheet of the same data as the map is showing.



Area drawing, to obtain an area for export

What layers do we want to add next?

  • Pollution
  • Taxi data (Cambridge only at this stage)
  • Census trip data
  • School travel data
  • … and more!

Next steps

We’re on the lookout for funding to enable us to develop this further. We’ve achieved everything you see with under £7k of funding, so think how much further the site could go.

Things we want to do include:

  • Change the UI so that it automatically ‘tells a story’
  • Add more data layers, e.g. pollution and accessibility analysis
  • Add charts to show change over time, ‘telling a story’
  • Add heat map views of several layers
  • Enable comparisons between Local Authority areas
  • Add a proper design and interface – the current UI is essentially a prototype
  • Enable more filtering controls
  • Ensuring all data is up-to-date, e.g. collision data needs an update
  • Add permalink URLs to enable all views to be persistent; currently this is only partially working
  • Fix oodles of bugs and inconsistencies

If you’d be interested in supporting any of the above developments, please do get in touch.

Also, code contributions are very welcome – the code is open source and on Github, and should be very easy to start working on, so let us know if you need advice, or just submit pull requests!



Lots of collisions, and the cycleability of the road is marked as low: 40%

Thanks

Thanks again to Outlandish Co-op, without whose funding and support would not have enabled us to get this project off the ground.

Lastly…

What should we call the site? Let us know your ideas!

CycleStreets.net in the Propensity to Cycle Tool

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

Bike Hub app relaunched

December 18th, 2016

A guest post from Carlton Reid, who writes about the fantastic new version of the Bike Hub app:

The Bike Hub cycle-specific satnav app, available for iPhone and Android, has been redesigned from scratch. Now six years old the all-new app still uses the CycleStreets routing engine so can still navigate on quiet roads, cycleways and away from hills. However, it now sports many of the core upgrades that smartphone operating systems have benefitted from in the past twelve months.

    

A tender was put out to three agencies and the contract was won by Tinderhouse of Canterbury, the existing development house. The app is now more intuitive to use, and – because it’s a new-build – works better with the latest smartphones. It can still find the nearest bike shop from where a user is standing, but is now quicker and slicker. The satnav voices for the app have also been updated.

While it has a UK focus – it’s paid for by the Bicycle Association of Great Britain – the free app is able to route in various other countries too. With upgraded graphics the maps are sharper, including up to tablet size for ride pre-planning. Users can toggle between three map styles: OpenCycleMap, Ordnance Survey Opendata and a clinically-clean Bike-Hub-specific map. Users navigate by choosing the quickest, shortest or quietest route, or a mix of all three.

Within a few weeks more features will be added to the app including syncronisation with Map My Tracks, Wahoo RFKLT and Apple Watch.

The Bicycle Association is the industry membership body that represents UK cycle and accessory suppliers. Industry companies and bike shops donate funds to the Bike Hub levy, which pays for the app, sponsorship of British Cycling’s Go Ride scheme and other projects. The Bike Hub app was first released in 2010.

    

The Bike Hub app makes use of map data from OpenCycleMap, pulls down map tiles from Thunderforest, and has a rendering engine from Map Box.

The Bike Hub app works on iPhones and Androids.

CycleStreets wins Cycle Planning Awards 2016 ‘best innovation’ category

September 26th, 2016

We’re delighted that CycleStreets has won the ‘best innovation’ category in the Cycle Planning Awards 2016, organised by Landor Links.

The award, for ‘CycleStreets and Cyclescape’, recognises our work on developing the CycleStreets suite of tools, including Cyclescape.

As the winners announcement states,

“CycleStreets provide data to a wide variety of journey planning websites and apps, encouraging the uptake of cycling by giving people information on where it is convenient and safe to ride and also providing better routes to existing cyclists.”

Beating off some stiff competition in the Best innovation – use of technology or new technique category, we were nonetheless pleased to see that another project making use of CycleStreets, the Propensity to Cycle Tool (PCT), was one of the runners-up too.

An unfortunate clash of dates meant we were unable to attend the awards in person, because we were in Brussels attending the main OpenStreetMap conference, State of the Map 2016. So thanks to James from the PCT project for collecting the award on our behalf:

  

As all good things come from Cambridge, it was great to see also that that the hard-working Cycling Officers at Cambridgeshire County Council won the category of ‘Most cycle-friendly policies (Local Government) – a well-deserved award to our friends there.

Thanks too to AECOM who sponsored the category!

You can read more about the awards on BikeBiz.

Making data more usable by campaigners: our Outlandish Fellowship

August 24th, 2016

We’re really pleased to announce that we’ve been selected for the Outlandish Fellowship to help local cycle campaigners by expanding our collisions data pages into a broader resource covering more types of data (e.g. traffic counts, pollution) and add lots of new ways to access it.

Helping campaigners campaign

Getting more people cycling brings a more sustainable and efficient transport system, improved public health, and greater access to employment. However, in the UK, cities have failed to make space for cycling on our streets, preventing mass uptake.

We know from our own activity as campaigners in Cambridge, that making a good evidence­-base for reallocating roadspace or challenging poor developments involves significant work. For instance, developers often claim that their route has “good connections to the local cycle network” whereas in practice we know that this often means a shared-use path that is hard to access.

We lack the data to make a strong case that, for instance, a combination of a high collision rate, congestion, pollution in an area means that a developer or a Local Authority needs to improve their plans. Of course there remains the need for making arguments based on broader policy, such as that cycling should be prioritised as a positive and healthy form of transport, but hard data for specific cases helps backs this up.

What kind of data is out there?

There’s lots out there that could be useful for cycle campaigning. Things like collision data (which we’ve already done a bit of work on), traffic count data, travel time data, census travel data, on-street counts, etc. Imagine if, instead of having to search these out and find someone technical to process it, you could simply point and click, with national coverage?

Collisions

This data is becoming available but it’s very scattered, meaning that correlations are hard to make. It’s often in raw formats that need significant work before it can be understood, or hidden in Local Authority websites that are not sufficiently flexible or easy for non-specialists to use. Often it’s not arranged for the kinds of tasks that cycle campaigners specifically need.

We’re aiming over time to build up a multi­functional resource to help build this case, enabling users to a build and link to an interactive display of the relevant data (involving multiple layers, clickable points, reports, summary info) for a particular location or route, that they can use in their advocacy and liaison work.

Mark, better known as ‘Ranty Highwayman’ in cycle planning circles, said:

“The project looks really exciting. From my point of view, the ability to generate information from one place is a great idea as at the moment, it’s a really labour-intensive process, this could create maps for reports, committee papers etc.”

Our plan is that it would be available for embedding in local campaign websites, exporting to reports, used in apps, and so on.

Some examples

Here are just a few sample stories that we’ve come across in our own work as cycle campaigners, some from Cambridge:

  • Justification of removal of one-way street restrictions for cycling. In previous decades, traffic planning favoured one-way streets as a way to regularise traffic flows and avoid rat-running. However, the side-effect is to stop easy cycling. If we could compare collision data easily in a particular location, we could show how streets that have been made two-way for cycling haven’t caused a safety hazard.
  • Worsened likelihood of collisions in areas with an existing poor record. A supermarket developer wanted to open a local store under a just-in-time delivery regime in a high street with a narrow carriageway that has heavy traffic and high pedestrian and cycle flows. A good evidence base, combining flow level data, Origin/Destination data, collisions and traffic data delay data, would have enabled us to argue that the developer will need to amend their delivery plans to be more sympathetic to the local circumstances.
  • Higher levels of pollution in areas with significant problems already. Areas with many schools particularly need to avoid pollution. A developer proposes a new estate in such an area but fails to provide good connections into the site for walking and cycling. A better evidence base, combining socio-economic data, school travel data, pollution and cycling levels would help us convince the Local Authority that the developer needs to provide this connectivity.

What changes can people expect?

We’ve started from our collision data viewer as the base, and to this we’re adding:

  • Completely reworking the search facility so that it’s actually useful – currently it’s stuck in a prototyped state, with lots of non-useful fields. This will mean that common scenarios like “Collisions between a date range in area X” are possible.
  • Adding typical scenarios as new front-end ways to access it. Currently, it’s very map-based, whereas we want to enable common use-cases much more easily.
  • Making everything Local Authority -aware. Currently it’s all manual boundaries, but we’d like users to be able to do things like compare casualty rates (and other data – see below) between areas.
  • Upgrading the interface. We’ve now got some nice new icons for a start :)
  • Adding a better way to import the data. Currently, updating it each year is not as easy as we’d like, and new data types (see below) need to be supported.
  • Adding generalised origin-destination data for areas, using analysis from our own journey planner
  • Adding traffic count data, from the DfT
  • More data (in future – after the current Fellowship work)
  • Adding the ability to switch between multiple layers of data
  • Making all the above available through a more generalised Advocacy data API. In fact, this will be the system powering all the above!
  • Adding the ability to embed custom views of the data in other sites

The code will be open source too :)

We’ll be giving updates via this blog over the coming 6 weeks – stay tuned!

Collisions

Blackfriars Bridge, scene of many unfortunate collisions over many years. With the new data platform, it will be possible to make easy comparisons about how the introduction of the new Dutch-standard cycle infrastructure just built reduces these collisions.

Outlandish

OutlandishOutlandish is a web agency based in Finsbury Park, down the train from us in Cambridge. The members of Outlandish want to unleash technology’s potential to make the world a fairer, better place. It’s a worker co-operative and invests all surpluses into projects that help achieve the members’ goals. They build digital applications and websites for companies, charities and universities that make their lives easier and help them to discover and communicate new insights from their data.

Outlandish has made available fellowships for people who are using the Internet and digital technologies to address social issues. The fellowships include funding and other forms of support to allow participants to start their own projects. The aim of the fellowship is to support work that matches the mission of Outlandish, and to expand the network of people that they actively collaborate with.

We’re really proud to be in the first set of Fellows, and it’s going to be great to be working with a co-op!

  
Photos from the launch of the Outlandish Fellowhip

Our project team

Our main developer on this project is Martin, doing most of the work, as the Outlandish Fellow.

He’s being helped by Simon (CycleStreets’ other principal developer), when he can be wrestled away from interesting routing quality challenges like turn delays that we’ve been working on recently.

We’ve also set up a Stakeholder board, to ensure that the data work we’re doing is genuinely useful. This is:

A version of this blog post also appears on the Outlandish blog.

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.