Much of the world isn’t built for biking (yet). Here’s how our developers are creating a way to skew maps in a cyclist’s favour.
To get a feeling for one of Einstein’s most astonishing insights into the universe, simply start riding a bike. Every second on a busy major road can feel like an hour, while an hour-long jaunt down a leafy trail can zip by in a flash.
While the distortion of time doesn’t quite work like that in physics, it’s a very real phenomenon for cyclists – and becomes even more so depending on whether you’re an experienced road warrior or a parent whose kids still use training wheels.
So, when Zeitspace and CycleWR set out to create the Cycling Guide app, the first order of business was to work out how to distort the virtual world to better reflect a cyclist’s reality. Thankfully, we didn’t have to start from scratch.
In 2012, American scholar Peter Furth and colleagues developed a “levels of stress” framework to evaluate and guide bike network planning. The framework basically parses routes by how stressful they are for the cyclist: a dedicated cycling trail is considered low stress, while riding alongside multiple lanes of traffic on a major thoroughfare is designated high stress. Bike Ottawa had used that framework to create an online routing tool, and shared the open source repository with CycleWR.
Thanks to shared research and open data, the first big pieces were in place. Next came the hard work.
The back end
Cycling Guide is based on PostgreSQL, an open source enterprise database, and the PostGIS plug-in that provides map-related capabilities. We then layered in another plug-in, pgRouting, an open source geospatial database that plots routes using nodes.
But that software is designed to find the shortest route. We needed it to factor in the differing experiences of cyclists.
Bike Ottawa had developed an algorithm that processes OpenStreetMap through the experience of a cyclist. The algorithm assigns a stress level (SL) to a road or trail depending on the cycling environment.
But the Bike Ottawa algorithm contained its weighting information within the code itself, which meant making changes to the Cycling Guide could be arduous and time consuming, says Zeitspace software engineer Catalin Pop.
“If you wanted to modify or update it, you had to go into the specific code. It was a little difficult, especially for non-technical people,” Pop says.
His goal was to tease the data out so that updates could be made more easily. He created software that links the stress-level database to the route generator. Rather than having multiple unique functions, each with its own hard-coded data, he generalized the process into a single repeatable function with data inputs.
Then, the question became how to use those stress levels to dynamically respond to the needs of cyclists. Zeitspace software engineer Amy Colford came up with a solution that cleverly prompts the routing software to make cyclist-specific decisions. She used the stress levels to warp how the routing software perceives the world.
A low-stress 200m-long trail or separated bike lane, deemed SL1, is read by the routing software as the correct length. However, a 200m-long stretch of slightly higher stress infrastructure (e.g. quiet residential streets) receives an SL2 weighting, and a multiplier is applied to the distance. The routing software then reads the SL2 street as longer than it actually is.
Increasingly higher multipliers are applied as the stress level rises: SL3 roads, which might have more cars but low speeds, have a higher multiplier than SL2; and SL4 infrastructure, which is generally high volume and high speed, receives the highest multiplier. (Controlled access highways, such as the 401, are weighted to be nearly infinite so that the route generator will never direct a cyclist there.)
The router still generates routes by determining the shortest distance between two nodes, only now, Colford has manipulated the concept of distance. In this highly distorted model of the world, the “shortest” distances are actually determined by the experience of riding.
But getting that distorted model to work on a phone was a different matter. Again, Colford had some ideas.
Fitting this on a phone
Colford is a Zeitspace software engineer who loves playing with software and hardware. After leading work on route creation, she then started creating her own router that aims to use a sliver of the computing power.
It all tracks back to PostgreSQL, the big, open source enterprise database. “Huge websites run off it,” Colford notes. “It’s got every feature you could ever imagine. So you don’t want to run it on your phone. You could, but you don’t want to.”
Her goal was to make the routing not just lighter, but have it work offline. That way users could still access the Cycling Guide functionality without a cell phone signal or a big mobile data plan.
First, she created routing software that is able to read OpenStreetMap tags in real time, as the user progresses along a route. Then, she compressed the tag data to lighten the load. Finally, she changed how all the data is processed in order to make it phone-friendly.
Unlike a cloud-based server, which has powerful processors with a lot of memory and storage, a cell phone has multiple processing cores in a less-powerful processor that tend to operate slowly in order to conserve power but can operate in parallel. Making use of those multiple cores is more important on a mobile phone. Colford had to scrape out the process to make it light enough for phones to handle, and make it multi-threaded to share the load across the processing cores.
The software she created, currently called Offline Routing, takes less than a second to generate a route that will meet the stress-comfort level of whomever is using the app. And, as the name suggests, it runs completely offline. (“Technically it’ll work online as well,” Colford notes.)
“We wanted to take into account the stress model. We want to distort them in real time. [But] we don’t want to store a different map for each option – we want to have the same map and process it on the way through.”
Once final testing is done, any host of tags can be incorporated into routing. (The team is keen to incorporate hills.) It’s a huge achievement, says Zeitspace partner Mark Connolly.
“She’s reduced the amount of processed data that we need, such that we could now get all of Ontario onto a phone in the amount of space it would take to do Waterloo Region currently,” he says.
And it, along with the rest of the app’s infrastructure, will be fed back into the open source community.
The beauty of open source
The team is unanimous in saying open source software is the key to the app’s success – and to its future. Not only does open source software enable developers to crowd-source solutions to problems, but it opens the possibility for other groups and users to build on what the Zeitspace team has produced.
“All the work we did in processing the data to create our stress model, that will go back into the open source repository, and other groups can use it and do what they want with it,” Connolly says.
There are additional benefits for users, Colford says. Open source software is, by definition, open, so it tends to respect user privacy more than corporate software.
“You can pretty easily check exactly what data we do collect, which isn’t very much. It’ll be something you opt into, because you want to volunteer to provide data back to improve things, not because we’re trying to sell you something.”
And, as someone who doesn’t cycle but loves hiking, Colford is extremely keen to see what might come when other developers get their hands on her work.
“I’m an avid hiker, and I’ve already been thinking of making an offline hiking router,” she says. “You don’t have signal 99 percent of the time and getting lost hiking is much more of an ordeal than getting lost in the city. This open source release will let people build stuff off of it, stuff we probably haven’t even thought of.”