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).
This changeset implements Lane Anticipation on roundabouts, delimited
by enter / leave step pairs. It does not handle lane anticipation
within a roundabout.
Lane anticipation happens on the granularity of a valid roundbaout:
We discard partial roundabout (enter without exit or exit without
enter) or data issues (no roundabout, exit before enter).
Related:
- https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes
within a roundabout
- https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling
going straight in lane anticipation
From
> [warn} oops
to
> [assert] /tmp/osrm-backend/src/extractor/extractor.cpp:79
> in: int osrm::extractor::Extractor::run(): false
> terminate called without an active exception
Aligned blocks prevent bus errors in NEON/VFP instructions.
Block pointers are aligned to 4 bytes, that is guaranteed
by aligned mmaped-pointers, the 4 bytes size of the CANARY block and
aligned sizes of blocks.
Patrick Niklaus
Moritz Kobitzsch
Daniel J. Hofmann
Konstantin Käfer
Patrick Niklaus
Surya Suluh
Michael Krasnyk
Daniel Patterson
Lauren Budorick