https://github.com/Project-OSRM/osrm-backend/pull/2685/files
fixes an issue where we did
elongate(fstStep, sndStep);
instead of
newStep = elongate(fstStep, sndStep);
we didn't get any warnings.
The only way to trigger a warning here is to use
```cpp
__attribute__((warn_unused_result))
```
This changeset does exactly that: for the new guidance code prone to
these kind of issue we add such an attribute to the declaration.
Why only `hov=designated` and not all access tags, such as `hov:yes`,
`hov=no` and so on? From the Wiki:
- designated: The way is designated to high occupancy vehicles.
- yes: High occupancy vehicles are allowed. This by itself does not imply that other vehicles are restricted from using the way.
- no: High occupancy vehicles are not allowed on the way. This by itself does not imply that other vehicle types are allowed to use it.
The primary use-case is conditionally filtering ways such as:
http://www.openstreetmap.org/way/11198593#map=19/37.82571/-122.30521&layers=D
In addition there is a notion of HOV lanes for lane handling:
http://wiki.openstreetmap.org/wiki/Key:hov#hov:lanes.3D.2A
This changeset does not handle lanes at all, only designated HOV ways.
For HOV lane support, a logic similar to the lane access handling needs
to be implemented. This needs to go hand in hand with the existing lane
handling introduced in:
7d076e9344
References:
- #2711
- http://wiki.openstreetmap.org/wiki/Key:access
- http://wiki.openstreetmap.org/wiki/Key:hov#Values
After half a day of looking at the tagging and the data came to the
following conclusion:
We can't keep the user to the innermost / outermost lanes depending on
the exit the route takes: we found situations where both heuristics were
wrong.
Even on popular roundabouts the tagging is often wrong or in the best
case not present at all.
There are at least two different ways to interpret roundabout
indications: 1/ where e.g. a right arrow on the lane indicates turn
restrictions for the roundabout and the need to take this lane to exit
the roundabout to the right (possibly skipping multiple exits) and 2/
where a right arrow just means this is a lane in a immediate right turn.
Example: Australia marks lanes with arrows that seem to indicate
"angles you can exit the roundabout from", for example, these two ways:
- http://www.openstreetmap.org/way/320941710
- http://www.openstreetmap.org/way/42918021
Whereas Germany marks lanes with "directions you can travel in these
lanes immediately after entering the roundabout":
- http://www.openstreetmap.org/way/52578338
These two different interpretations of how to draw the arrows on the
roads mean we have conflicting solutions to "which lanes can you use to
take exit B from entry A" based on locality.
Continuing to tag ways based on lane markings is no problem, but
unfortunately, we can't reliably resolve good advice for navigation
system users (like "use the inside lane to take the second exit at the
roundabout"), there are too many situations that would generate bad
instructions (instructions that tell users to go into a lane they
shouldn't use).
Before we asserted on unique lane indications per lane. Turns out the
OSM data contains lane strings such as:
left;left|right
Which represents two lanes as in:
<< >
|| |
The two left indications _on a single lane_ look like data issue.
And we can't represent this with our enum-approach at the moment.
We don't want to crash there, so silently swallow this and
generate a single left|right for it.
