I’m adding routing to a webapp I maintain and trying out several different services. GraphHopper seemed like the most interesting one since it’s open source (like my project as well! and offers a lot of customizability so that we could implement a more flexible routing feature that takes into account different urban cyclists profiles.
However it seems to do really badly in some specific cases and I’m trying to understand why.
Compare for instance when I run it along with other routing services inside my app. Note I’m calculating a score based on how much that route is covered by cycling infraestructure:
Here’s one of those streets in OSM. Notice how it has a cycleway=lane with oneway:bicycle=no, which should be perfectly cyclable and preferred than streets with no infrastructure at all.
Is it some specificity of the algorithm, a bug, or something I’m doing wrong on my side? Or do you suggest some other model customizations that would make the route prioritize this kind of cyleways?
I’ve also found this weird, and might point us towards where the problem is: even when forcing the route to go via that street with the cycleway, bike_network value along all of it is MISSING.
Thanks for reporting. This is indeed a bug in our prioritization code. Currently we prefer a highway=residential without bicycle infrastructure over one with bicycle infrastructure. It is interesting that we discover this after such a long time as I’m not aware of a recent change which would have introduced this. We need to think a bit about how we can improve this best. Unfortunately, you currently cannot influence this via custom rules.
@karussell : We currently have residential in preferHighwayTags, which we assign priority PREFER. A cycleway=lane gets assigned with SLIGHT_PREFER only.
If we reduce the priority of the preferHighwayTags, more higher classified highways such as secondary will be preferred over simple residential highways.
We also could boost cycleway=lane infrastructure from SLIGHT_PREFER to PREFER, but I don’t want to do that because then cycleway=lane would get the same priority as cycleway=track. Additionally, it would boost secondaries or primaries with cycle infrastructure too much.
Thanks for the quick reply! Happy to know I’ve helped uncover this bug.
If I may add my 5 cents, regardless of how you guys decide to fix this, it’d be great if we could expose this kind of infrastructure to custom models as well so we can adapt routing not only to different urban cycling styles but also social contexts.
In big cities in Brazil even residential streets tend to be dangerous places, where only hardcore cyclists would venture themselves. But now that I’m living in Spain I notice how, even having great cycleway networks, drivers here have a very different approach and are way more patient and respectful and I don’t really mind too much sharing.
Those and similar issues are on my list and I would like to simplify the priority handling in general after consolidating the bike speed (discussed here). Because currently such small differences/inconsistencies lead to strange routes and/or detours.
Also exposing some more information to the custom_model would be really nice (like the cycleway tag, or if something is separated from car or “segregated” from foot, I think there was an issue about it already but couldn’t find it).
As a quickfix I would also reduce the preferHighwayTags.
The discussion you are referring to is most likely this one: #3008. Nobody answered there how we would populate such a new bicycle infrastructure encoded value on separated ways, which also belong to the bicycle infrastructure.
and offers a lot of customizability so that we could implement a more flexible routing feature that takes into account different urban cyclists profiles.
