Lane Anticipation currently triggers on quick steps with lanes. This
changeset makes the "quick" part more dynamic by taking lanes left and
right of the turn into account. The reasoning for this is as follows.
The user can drive on the leftmost or rightmost lane and has to cross
all lanes left or right of the turn, respecitvely.
We scale our threshold appropriately, which now means the threshold
describes the duration the user needs for crossing _a single lane_.
Note: this is a heuristic and assumes the worst case. Which in my
opinion is fine to do since triggering Lane Anticipation in complex
scenarios is desirable.
adjust to generalFindMaximum function
moved parallel detection to ratio/absolute based regression testing
considerably improved detection quality using normalised regression lines
only follow initial direction/narrow turns for parallel detection
instead of artificially removing lanes from a roundabout, we don't assing them in the first place.
this also prevents a problem where we would end up collapsing turns with lanes in a roundabout
These kind of roundabouts came up during Lane Handling for roundabouts.
They're called Turbo-roundabouts or Turbine-roundabouts and are very
popular e.g. in Germany and the UK.
Seems like our roundabout handler sometimes is getting confused.
Trying to figure out why, and codifying some scenarios for cucumber.
References:
- https://github.com/Project-OSRM/osrm-backend/pull/2693
Changes the processing order in the edge based graph factory.
Instead of iterating over all outgoing edges in order, we compute the edge
expanded graph in the order of intersections.
This allows to remember intersection shapes and re-use them for all possible ingoing edges.
Also: use low accuracry mode for intersections degree 2 intersections
We can use lower accuracy here, since the `bearing`
after the turn is not as relevant for off-route detection.
Getting lost is near impossible here.
