Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stickiness for route relations (like turn penalties) #612

Closed
systemed opened this issue Apr 11, 2013 · 6 comments
Closed

Stickiness for route relations (like turn penalties) #612

systemed opened this issue Apr 11, 2013 · 6 comments

Comments

@systemed
Copy link
Member

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:

Screen Shot 2013-04-11 at 21 12 57

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
Copy link
Contributor

emiltin commented Apr 12, 2013

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://github.com/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
Copy link
Member Author

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
Copy link
Contributor

emiltin commented Apr 12, 2013

ok i see

@emiltin
Copy link
Contributor

emiltin commented Apr 12, 2013

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

@karme
Copy link

karme commented Apr 12, 2013

Richard Fairhurst notifications@github.com 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
Copy link
Collaborator

Duplicate to #482

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants