Slip road should be preferred

[freenerd]

http://map.project-osrm.org/?z=18&center=39.094067%2C-76.842510&loc=39.093948%2C-76.842906&loc=39.095093%2C-76.840750&hl=en&alt=0

I think this should prefer the slip road instead of the primary turn. Couple of things at play here:

• The slip road is ["primary_link"] = 30, whereas the taken turn is ["primary"] = 65,. I think we are hitting a point where the slip road is long enough that together with turn penalty, the primary turn is preferred.
• There is no turn restriction on the primary road turn. There likely should be though, since I'm certain a right turn would not be allowed.

So this smells like a data issue, but just want to make sure it is.

[daniel-j-h]

Yep,

http://map.project-osrm.org/debug/#18/39.09459/-76.84185

Tagging: http://wiki.openstreetmap.org/wiki/Highway_link

Here's something interesting, though: highway=primary_link in Berlin: http://geojson.io/#id=gist:anonymous/472ccacb38784ac041f36cfa5c07b278&map=13/52.5175/13.3812

Check the Table here for some values in combination with the maxspeed tag - almost all of them have a maxspeed 50 tag attached to them. Makes me wonder if our profile default of 35 is way too slow.

[freenerd]

yeah, my gut feeling is that primary_link should be slower than primary, but 65 vs 30 seems a little low. Maybe we should raise to 45 or 50?

[freenerd]

Unintended side effect of upping the primary_link speed could be that more frontage roads will be preferred in routing, so we should be careful here.

[daniel-j-h]

cc @lily-chai just fyi

[MoKob]

Technically we could define this as something to handle in OSRM (e.g. implicit turn restrictions if there is a sliproad). But that would make turn processing way more complicated.

I'd define it as a data issue, since the turn should be not allowed in that situation and/or the speed should not be as bad for the turn to make the sliproad unattractive to begin with.

Might be that this get fixed with an improved turn function (since we need to slow down considerably for the turn on 90 degrees compared to the two slight turns) - see https://github.com/Project-OSRM/osrm-backend/pull/2912.

[daniel-j-h]

cc @jakepruitt maybe something to play with in the speed / weight split.

[daniel-j-h]

This just came up again in the context of the fossgis workshop. We now have the turn type available in the turn function, so we can up the weight for sliproad turns:

-- Makes turns onto detected Sliproads preferable over their non-sliproad counterparts.
-- We can not detect the turn off of the sliproad here, but this is a good first step.
if turn.turn_type == turn_type.sliproad then
    local sliproad_bias = 0.7;
    turn.weight = turn.weight * sliproad_bias
end

I quickly tested it locally but it needs further investigation, especially since we don't want to screw with the weights too much so that we allow detours via sliproads. Also we can not detect the turn off of the sliproad.

[emiltin]

would it be possible to have access to the way type you come from, as well as the way you turn onto?

[daniel-j-h]

At the moment we iterate over all intersections and call the Lua function (via ProcessTurn) on each turn

https://github.com/Project-OSRM/osrm-backend/blob/78a199e2fb94974ab350ac94a409c0ac56ed7a11/src/extractor/edge_based_graph_factory.cpp#L470

https://github.com/Project-OSRM/osrm-backend/blob/78a199e2fb94974ab350ac94a409c0ac56ed7a11/src/extractor/edge_based_graph_factory.cpp#L530

What you propose would be to call ProcessTurn with onto / off turn. cc @MoKob who re-wrote that code.