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
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.
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
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.
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.
