You can now sign up as a beta-tester for our Android app, simply by opting into the beta programme in the Google Play Store. This enables you to get the latest improvements and give feedback before they are released officially.

We’re currently making lots of changes to the app (thanks to the great work of our devs Oliver Lockwood and Jez Higgins), with lots of bug-fixes, improvements, and a new design coming.

The app is open source and we very much welcome new contributions of code, bug reports, etc.

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.

The data was originally collected for the DfT’s Transport Direct project (which has since ceased operation), which was an early attempt to create a government cycle journey planner, launching on almost the same day as CycleStreets itself. In order to ensure that taxpayer value for this expensive (£2.4m) dataset was not lost as Transport Direct fell into disuse, CycleStreets successfully encouraged the DfT to release the data openly and to do so in a way which would encourage use in OpenStreetMap. We helped with that process, and data for cities started to be merged in from 2011.

The data consists of the cycle network as of 2011 in each city of over 30,000 people. This does however not represent all cycle infrastructure – only where signage is present. Additionally, collection included the Sustrans NCN network.

Since that time, things have moved on. OpenStreetMap has become the go-to datasource for cycling data internationally. GeoJSON has become the de-facto format for open geographical data. Similarly, Github has become the de-facto location to distribute open data like this.

Accordingly, we have taken the opportunity to recover the data from 2011, and convert it to GeoJSON and republish it, in the hope it might be useful for some people. It is an OpenStreetMap-orientated version of the data published on data.gov.uk. As such it is subject to OSM licensing conditions.

We would stress that, for almost all uses, CycleStreets instead strongly recommends downloading data from OpenStreetMap, which is topographically routable and is maintained and has far greater geographical coverage. Moreover, the cycle network has changed from 2011-18. However, the data in this repository contains attributes on each geometry which remain often more detailed than OSM. Accordingly, the data is most useful for research purposes and for manual merging into OSM, which is encouraged.

Full details about the data are given in the README which can be found on the main repository page.

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’.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

the cost of riding along each street

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.

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.

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):

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!

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.