Mysterious bicycle routing …

routechoiceThis is only a quick note on a recent observation I’ve made while using bicycle routing portals on the web. However, the relevance of data quality and implemented model routines becomes obvious very nicely. And because I’ve been struggling with these issues for quite a while now and things don’t necessarily turn to the better, I’m curious about your ideas on the following examples.

Imagine an absolutely normal situation in your daily mobility routines. You are at location A and you need to go to location B. Because you are a good guy, you choose the bicycle as your preferred mode of transport. What do you do? Of course you consult a routing service on the web, either via your desktop browser or mobile app.
But which service do you trust, which recommendations are reliable and relevant to you? Give it a try.

  1. For many people the big elephant Google Maps is their first choice . Whether you like it or not, Google has made a big leap forward with their bicycle routing service.

    routing1_google_maps

  2. Because you love OpenstreetMap and the GIScience group internet at Heidelberg University did a great job, you try the bicycle version of OpenRouteService. What you get is what you know from Google.

    routing2_openrouteservice

  3. If you consult another routing portal that is based on OSM data, you might get surprised. Naviki suggests the following route:

    routing3_openrouteservice

  4. So far we’ve tried a commercial service and two platforms which are fueled by crowd-sourced, open data. Let’s turn to authoritative data now. The goal of the federal routing service VAO is primarily the provision of a multi-modal routing service, with a focus on public transport. The bicycle version gives you this recommendation:

    routing4_vao

  5. The bicycle routing portal for the city and federal state of Salzburg, Radlkarte.info, is designed for the specific needs of utilitarian bicyclists. The data base is identical to the VAO service, but the result differs significantly.

    routing5_radlkarte

The intention of this blog post is not to assess the quality (validity, reliability, relevance) of the routing recommendations as such. What I want to point to is the fact, that three different service, with different data sources in the back result in exactly the same routing recommendation, whereas services that are built upon the same data result in significantly different suggestions. That’s really mysterious. And it tells me, that the data and data quality is only one side of the medal. Obviously the parametrization of the routing engine and implemented model routines have a huge impact on the result. By the way, for all five examples, I’ve used the default settings.
Following the argument of the impact of parametrization and modelling, one can conclude that it is not so much about the data (they seem to be of adequate quality in all three cases), but about how well you know the user’s specific needs and preferences and turn this knowledge in appropriate models and services. Thus the next consequent step is to offer users the possibility to influence the parametrization of the routing engine in order to get what he or she expects to get: routing recommendations that perfectly fit their preferences.
Do you know routing services on the web that a allow for a maximum personalization (not only pre-defined categories)? To which degree would users benefit from personalized routing? And finally, would bicyclists use it at all? Let me know what you think and share your ideas!

Advertisements

4 comments

  1. Ralpg

    one other route finding is Strava. It appears to be driven by its riders only. Which is a subset of riders that would nominally exclude commute and working cyclists (cargo). I’ve only tried it in Munich with the find my way home option. Surprisingly it took me away from many roads which may have been faster but less pleasant because of motor vehicle traffic.

  2. Didi

    Let me throw one more route planner into the mix: http://map.bikecitizens.net/at-salzburg#/!/1/1/47.7887,13.06041/47.79578,13.02717 (I’m personally involved in development).
    My opinion about the mystery: It’s the many details supported by the OpenStreetMap data model which increase the probability of different results for different routers. Just take a look at https://wiki.openstreetmap.org/wiki/Bicycle to see what I mean. And that’s only a subset of the tags relevant for a bicycle router.
    Regarding personalization: While I believe in the importance of good defaults, I personally also like more options most of the time. I have however also learned that it’s really a challenge to offer this without breaking the design and/or usability. Users tend to quickly go away if a tool requires elevated cognitive effort (and the threshold for what’s acceptable has gone quite low imo).
    A somewhat extreme example for max. personalization is http://brouter.de/brouter-web/.

    I’ve come to the conclusion that – for such an application – for most users good predefined profiles are the best compromise and development and design effort is most of the time spent better in other areas then offering many manual personalization options. I do however think that routing engines should become more intelligent, taking into account more parameters, considering additional data sets (e.g. air quality) and being able to learn from the users behavior, ultimately leading to automated individual parameterization (e.g. I would guess Google does this for car routing, based on previous travel speeds of individuals – at least they calculate the estimated time accordingly).
    I also think route planners should better visualize how they came to a specific conclusion (e.g. by coloring / annotating segments), giving the user easy and understandable options to manipulate a suggested route.

  3. Ollyver

    In the UK, I have found http://www.cyclestreets.net to be really useful – it lets you select your speed and which roads you are comfortable on separately. This greater degree of parametrization is better than the official Transport for London route planner (which combines the two), or Google Maps (which doesn’t distinguish between busy and quiet roads at all). I’m comfortable with that level of detail – more parameters to set would be a waste of time for me, when it works well already. But if I had a box bike, I’d like to be able to include “no narrow gates” as a parameter. So I think if you can, better to allow users the full power of your application – but set all the defaults to the most commonly useful values, rather than making people figure them all out by trial and error.
    I am much more likely to cycle places now that I’ve discovered Cycle Streets – TfL and Google both gave such poor directions that I would end up lost or scared by traffic or both and give up. So a decent route planner can make a big difference, at least to some of us.

    • gicycle

      Thanks Ollyver for your comment. Indeed, there are plenty of journey planners and cyclestreets.net is definitely a good option.
      The point I wanted to make here is, that data are crucial for the quality of the routing recommendation, but the parametrization of the routing engine is even more decisive. That the results of applications which are built upon the same data source is a pure fun fact.
      You raise a valid question concerning the tradeoff between usability/comfort and parametrization/personalization. To my current knowledge there is no (quantitative!) evidence for user preferences in the context of bicycle routing apps – please let me know if I’ve missed a relevant study. I guess fixed habits and a strong market presence are still the major drivers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s