Stickiness for route relations (like turn penalties)

[systemed]

OSRM's running beautifully on my machine with route relation support and turn penalties - thanks @emiltin for these great bits of code.

When the cyclist is following a waymarked route, there's a benefit to staying on that route - it makes navigation much easier (i.e. "keep following signs for NCN 244").

At present, though, OSRM will sometimes hop on/off the route if there's a marginally better short alternative. For example:

It would be good to have something like turn penalties for routes - i.e. a Lua function that would take the routes on each edge as parameters, and could add a penalty when leaving the route, thereby encouraging OSRM to stick to the route.

[emiltin]

nice to hear you find it useful.

i agree that passing the ways to the turn penalty function would have several benefits. for example, you cancould penalize turning left from a big road into a small road where there is no signal (assuming right side driving).

but a better solution to your problem might be to separate impedance from speed (although it's not trivial to code). that way you can make the route 'sticky' without affecting the estimated travel time, by lowering the impedance on cycle routes.

work on separating impedance from speed is ongoing in https:/DennisOSRM/Project-OSRM/tree/feature/lua_impedance, but it's rather experiemental at the moment. check impedance.feature and testbot.lua.

as a workaround, you can set the speed higher on cycleroutes, and then manually calculate the travel time cient side based on distance.

[systemed]

I'm pretty much doing that already - I currently have a profile where cycleway=default_1.3, unclassified=default_1.2, trunk=default_0.4, then NCN adds a multiplier of 1.3 and so on (so a cycleway on an NCN route would be default_1.69). As a result I don't use the OSRM-generated time values at all (they're fairly arbitrary for cycling, anyway, as people's cycling speed varies so much and because there's no elevation support yet).

I'm loth to increase the NCN multiplier any further as it'd lead to fairly distorted results - but it still has this behaviour of popping on and off the route now and then.

I guess this is essentially the same issue as #592 and #477?

[emiltin]

ok i see

[emiltin]

you could also try to turn up the general turn penalty?

[karme]

Richard Fairhurst [email protected] writes:

I'm pretty much doing that already - I currently have a profile where
cycleway=default_1.3, unclassified=default_1.2, trunk=default_0.4,
then NCN adds a multiplier of 1.3 and so on (so a cycleway on an NCN
route would be default_1.69). As a result I don't use the
OSRM-generated time values at all (they're fairly arbitrary for
cycling, anyway, as people's cycling speed varies so much and because
there's no elevation support yet).

I'm loth to increase the NCN multiplier any further as it'd lead to
fairly distorted results - but it still has this behaviour of popping
on and off the route now and then.

if you are only looking for a hack:
factors above are too small
you can roughly think of it like this:
if there is a prefered way (cycle route) and a normal way - how much
more do you want to travel before taking the non-prefered way

the problem you likely see: the popping happens for relatively small
parts / cutting edges - to "solve" that problem you can add (+) a not
to huge penalty to all non-prefered ways

and yes that's not ideal

[DennisOSRM]

Duplicate to #482