Routing performance developments

The main focus of our development work over the last few months has been to improve the performance of our routing engine. This has become a priority with the need to serve routes on new mobile platforms, where the expectation that a route should appear quickly is even higher than those interacting with CycleStreets via a web browser. We need to generate routes as fast as possible – as that will form the basis for developing a stronger user experience.

We have explored three other routing engine architectures in addition to the original engine.  This has involved changing our system so that it can interface to all four routing engines. Getting that to work has forced our code quality in that area to improve and become more modular and generic.

One of the routing engines is emerging as a clear winner in terms of performance speed. It is written in the Python language, and is based on some code initially provided by a participant at our developer day back in March. This engine has now been serving all routes since last Thursday. The routes it produces are identical to those produced by our previous system, but they are now generated more quickly (and more reliably) than with the previous engine.

API users (mobile phone interface developers) have already remarked at the speed increase.

We shall be extending this engine to cover other parts of the route generation process that are still relatively slow.

We've been able to undertake this concentrated period of work to speed things up and improve resilience thanks to grant funding from two sources: the Rees Jeffreys Road Fund, as part of our efforts to improve performance for mobile interfaces, and hosting optimisation thanks to a grant from the Co-op Community Fund. We are very grateful for their support.