The Map Matching plugin currently has issues with:
- high frequency traces and (performance)
- blobs, think noise at traffic signals (correctness)
This changeset implements trace-tidying transparently for the user.
We hopefully will see both performance gains as well as better matches!
This graph enables efficient boundary edge scans at each level.
Currenly this needs about |V|*|L| bytes of storage.
We can optimize this when the highest boundary nodes ID is << |V|.
- moves collapse into a dedicated set of functions / files
- make collapse scenarios distinct (slight performance cost)
- reduce verbosity for short name segments (now actually working, was supposed to do so before)
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
rename intersection (engine version) to IntermediateIntersection
follow coding convention for existing functions, move invalidate into routeStep
moved elongate into route step
move forward-step-signage into route step
replace post-processings `forwardInto` with `RouteStep` functionality. Don't change maneuver in step
separete declaration and implementation
Adds an `generate_hints=false` option which lets us skip generating and
emitting hints for Waypoints. This can be used to decrease the response
size when the user does not need hints anyway.
We should think about making `false` the default here in v6.
This change fixes two bugs:
1. A dead-lock that occurs between osrm-datastore and libosrm when an
old dataset is free during a data update. This happened because the
mutexes where acquired in a different order.
2. A region is deleted eventhough it is still in use. This happens when
libosrm gets overtaken by osrm-datastore, so the new dataset is in
the same region the old one was.
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
removes duplicated includes
removes unused includes
eliminates dedicated toolkits that resulted in circular dependencies
moves functionality close to data, where possible
Removes CompressedEdges from the extractor and shared data format by
directly serializing vectors of node ID's, forward weights and reverse
weights for each node-based-edge
Refs #2575
This PR adds more advanced coordinate extraction, analysing the road
to detect offsets due to OSM way modelling.
In addition it improves the handling of bearings. Right now OSM reports
bearings simply based on the very first coordinate along a way.
With this PR, we store the bearings for a turn correctly, making the
bearings for turns correct.
This switchtes the data even if there are requests still running on the
old data. osrm-datastore then waits until all of these old requests have
finished before freeing the old regions.
This also means that osrm-datastore will return with an error if there
is a data update currenlty in progress.
Changes the internal representation of compressed geometries to be a
single array shared between forward and reverse geometries that can be
read in either direction. Includes a change on
extractor::OriginalEdgeData to store via_geometry ids that indicate
which direction to read the geometry for that edge based edge.
Closes#2592
Technically speaking we're changing the `libosrm` API.
But since we're only lifting restrictions by marking the API threadsafe,
we should be fine here.
With @karenzshea's name / ref split (ref. #2857) in master we want to
make use of it and reduce `NewName` instructions when ever possible.
This is a first step towards #2744 by using the already existing name
change heuristic from the extractor now in post-processing as well.
Limitations: at the moment we don't have the `SuffixTable` in
post-processing; this would require us serializing and subsequently
deserializing the table, passing it through from the profiles to the
API.
Before we only worked on subsequent quick turns, as in:
`right, right` keeps the user on the rightmost lanes.
This changeset modifies the logic to work on any subsequent steps
that are "quick" and have lane information we can constrain later.
Because we do not have a from-lane => to-lanes mapping we take the
lanes left and right of the turn lanes into account when heuristically
assigning the leftmost / rightmost lanes.
There are some edge cases where this still does not give us the optimal
solution but it gets close to what is actually possible at the moment
without having a lane mapping in post-processing.
References:
- https://github.com/Project-OSRM/osrm-backend/issues/2625
fix rebase
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.
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
