Lanes should indicate validity per indication

[freenerd]

When implementing lanes on osrm-frontend Project-OSRM/osrm-frontend#187, I noticed that valid is only given for whole lanes, but not for single indications on the lanes.

What is currently possible:

"type": "turn",
"modifier": "left",
"lanes":[
         {"indications":["left","straight"], "valid": true},
         {"indications":["straight"], "valid": false}
],

What I would like to see:

"type": "turn",
"modifier": "left",
"lanes":[
         {"indications":["left","straight"], "valid": [ true, false ]},
         {"indications":["right"], "valid": [ false ]}
]

/cc @MoKob @daniel-j-h @bsudekum @1ec5

[freenerd]

Some more motivation why this is important, here is a three-lane setup on a left-turning fork with:

"type": "fork",
"modifier": "slight left",
"lanes":[
         {"indications":["slight left"], "valid": true},
         {"indications":["slight left", "slight right"], "valid": true},
         {"indications":["slight right"], "valid": false}
],

What we want:

What we currently can do:

[daniel-j-h]

I think you're mixing the semantics of indications on a lane and turn instructions / modifier.

Take turn:lanes=none|none|through;slight_right as an example, visualized here:

http://wiki.openstreetmap.org/wiki/Key:turn#Motorway_with_links_and_destinations

If we (for simplicity) ignore the none lanes here, starting at the bottom at B and immediately leaving the highway to the right you'll get 1/ a turn instruction 2/ a right modifier 3/ the indications for the lane to take to make this maneuver as it is painted on the lane: through;slight_right.

Lanes alone are not suitable for routing or guidance: instruction and / or modifier are needed.

[freenerd]

Lanes alone are not suitable for routing or guidance: instruction and / or modifier are needed.

Agreed. I think there are three levels of how lane information can be used for routing:

1. Show which lanes are valid to take (valid flag per lane, no direction indication)
2. Show which lanes are valid to take and the indications that are painted on the road (what we have right now)
3. Show which lanes are valid to take and the valid indications for each lane (what I'm asking for here)

The displayed lane information and the turn symbol should match (e.g. in my last comment, three lanes are displayed but the turn symbol will be fork slight left). What I'm flagging here, is that we do not do that correctly, since we do not support level 3.

[MoKob]

Given that this would be an API-Change, I have to say my main question is what the main benefit would be here and if the benefit justifies such a change.

I can see that the turn symbols would be better if we have a match between the turn and the symbols.
The information on which turn to take is, as @daniel-j-h already said, is given in the direction-modifiers. So I personally don't feel that having option two would be such a drawback, as the information on which indication to follow does not necessarily help you more than the lanes themselves.
So @freenerd, do you feel that the benefit here could justify a major version bump?

Implementation-wise we would be facing a different challenge as well. Because of the indication : lane mapping, we would need to update our entry flags as well to match the indications. It's possible, but would also require some additional memory. Not too bad, though.

[1ec5]

In #2935 (comment), modifier matches lanes[0].indications[0] but not lanes[0].indications[1]. Isn’t that enough information to display instead of ? In what cases would modifier not match the indications the client would want to consider when drawing the lane icons?

[freenerd]

I can see that the turn symbols would be better if we have a match between the turn and the symbols.

Just to get vocabulary clear here:

• turn symbol are icons to communicate to users which maneuver next. They are based on type, modifier and maybe in/out/bearings/entry.
• lane symbols are icons to communicate to users which lanes are valid for their next maneuver. They are based on the lanes array.

Both are similar, but will be displayed side-by-side and not replace each other. Lanes are additional information.

So I personally don't feel that having option two would be such a drawback, as the information on which indication to follow does not necessarily help you more than the lanes themselves.

The problem for me is that with Level 2, the lane symbol might contradict the turn symbol. Sure, from a data standpoint this is correct (we only show the markings on the lane) but from a user perspective this is confusing, since not all symbols align.

So @freenerd, do you feel that the benefit here could justify a major version bump?

Yes. It's not a total blocker though, so I'm happy to punt on this and roll it up with other breaking API changes we have planned for the future. Do we track v6 somewhere?

[freenerd]

@1ec5 good point. @MoKob is there a guarantee that lane indications will match modifier? I guess there could be some ambiguity with slight right/ right / sharp right but we could likely just combine these and for the major cases of turn + straight this could provide a fix.

[1ec5]

The only problem areas would be things like merge and ramp instructions. For a typical merge to the left, the backend might give a modifier of slight right but the frontend would (hopefully) say modifier: left.

[MoKob]

@freenerd We are tracking 6.0 only in form of milestones. So we could add this issue to the 6.0 milestone.

Regarding the matching indications: Due to the nature of my current turn assignment, they should match up for the most part. They don't have to in all situations, though. For example exiting a roundabout would be a typical example where a turn can be perfectly straight but have an indication both to the left and to the right (depending on which side of the road you are driving on). Roundabouts currently don't return lane information, but I can't guarantee that all lane-indications will match their modifiers.