Currently we don't route over the Golden Gate bridge by default.
This sets the value to false by default. To test the behavior for
tolls when ignored, we would need issue #2781 implemented.
Roundabout Intersections are roundabouts with up to four ways and turn
angles which makes the turns obvious, e.g. as in:
```
*
*
* * * *
*
*
```
but not
```
*
*
* * *
* *
* *
```
For Roundabout Intersections we issue instructions such as
"turn <direction>" instead of "take the <nth> exit".
At the moment we have a limit on the radius for these Roundabout
Intersections of 5 meters. Which fails to classify a wide range of
Roundabout Intersections in the US (with the US-wide streets).
This changeset removes the Roundabout Intersection radius limit:
- if the roundabout is larger than a threshold and is named we classify
it as a rotary
- if the roundabout matches our criteria for Roundabout Intersections
we classify it as a Roundabout Intersection
- else fallback to plain old Roundabout
There is a second issue with determining a roundabout's radius.
But that's for another pull request (tracking in #2716).
References:
- https://github.com/Project-OSRM/osrm-backend/issues/2716
- Clarifying guarantees between patch/minor/major versions
- Consolidating version release flow into one flow for patch/minor/major versions
- Add constraint that all minor/major released code needs to have had a release candidate before
Staggered intersection are very short zig-zags of only a few meters.
They are common in rural and exurban areas, especially in the US.
(In addition, these cases could as well be tagging issues)
We do not want to announce these short left-rights or right-lefts:
* -> b a -> *
| or | becomes a -> b
a -> * * -> b
Here is one example:
- https://www.openstreetmap.org/edit#map=20/39.26017/-84.25182
And here are two edge-cases that we don't handle at the moment:
- http://www.openstreetmap.org/edit#map=20/38.87900/-76.98519
- http://www.openstreetmap.org/edit#map=19/45.51056/-122.63462
and probably should not handle since the distance in between is
quite long (roughly 7-15 meters). For these we want to announce
two turns to not confuse the user.
Thanks to @1ec5 for raising this issue and @karenzshea for
providing additional US examples and cultural insights.
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
