Unidirectional traffic signal segments are currently not compressed.
This means traffic signals which are not on turns can be missed and
not applied the correct penalty.
This commit changes this behaviour to correctly handle the graph
compression. Additional tests are added to ensure there is no
regression for other cases (turns, restrictions).
Co-authored-by: Michael Bell <michael@mjjbell.com>
This change takes the existing typedefs for weight, duration and
distance, and makes them proper types, using the existing Alias
functionality.
Primarily this is to prevent bugs where the metrics are switched,
but it also adds additional documentation. For example, it now
makes it clear (despite the naming of variables) that most of the
trip algorithm is running on the duration metric.
I've not made any changes to the casts performed between metrics
and numeric types, they now just more explicit.
Weight and duration penalties are flipped in the lambda function
that applies penalties from traffic signals.
Duration is in deciseconds, whilst weight is multipled by
10^weight_precision, with weight_precision being 1 by default.
Therefore, for default routability profile, the penalties end up
being the same, hence why no tests picked this up.
If distance weight is used however, it will incorrectly apply an
additional penalty to the weight, and not add the traffic signal
delay to the duration in the routing graph.
To confuse things further, in some API responses the values are
correct because they use geometry data instead, but it's still
possible that a sub-optimal route was selected.
However, given the distance weight is in meters, and the additional
penalty per traffic light would be 20, it's unlikely this would
have changed the routing results.
In any case, we correct the function to apply the arguments correctly.
Currently OSRM parses traffic signal nodes without consideration
for the direction in which the signal applies. This can lead
to duplicated routing penalties, especially when a forward and backward
signal are in close proximity on a way.
This commit adds support for directed signals to the extraction and
graph creation. Signal penalties are only applied in the direction
specified by the OSM tag.
We add the assignment of traffic directions to the lua scripts,
maintaining backwards compatibility with the existing boolean
traffic states.
As part of the changes to the internal structures used for tracking
traffic signals during extraction, we stop serialising/deserialising
signals to the `.osrm` file. The traffic signals are only used by
`osrm-extract` so whilst this is a data format change, it will not
break any existing user processes.
This change unblocks the osrm-extract debug build, which is
currently failing on a maneuver override assertion.
The processing of maneuver overrides currently has three issues
- It assumes the via node(s) can't be compressed (the failing assertion)
- It can't handle via-paths containing incompressible nodes
- It doesn't interop with turn restriction on the same path
Turn restrictions and maneuver overrides both use the same
from-via-to path representation.
Therefore, we can fix these issues by consolidating their
structures and reusing the path representation for
turn restrictions, which already is robust to the above
issues.
This also simplifies some of the codebase by removing maneuver
override specific path processing.
There are ~100 maneuver overrides in the OSM database, so the
impact on processing and routing will be minimal.
Currently OSRM only supports turn restrictions with a single via-node or one
via-way. OSM allows for multiple via-ways to represent longer and more
complex restrictions.
This PR extends the use of duplicate nodes for representng via-way turn
restrictions to also support multi via-way restrictions. Effectively, this
increases the edge-based graph size by the number of edges in multi via-way
restrictions. However, given the low number of these restrictions it
has little effect on total graph size.
In addition, we add a new step in the extraction phase that constructs
a restriction graph to support more complex relationships between restrictions,
such as nested restrictions and overlapping restrictions.
* set and store highway and access classification for the turn function
* expose highway turn classification and access turn classification and speed to the lua profile turn function
* expose whether connection road at turn is incoming or outgoing
* add lua tests for exposed information to turn function
* update docs about attributes in process_turn
* add turn_classification info to docs
* adding warning if uturn and intersection dont match
* handle u turns that do not turn into intersection[0]
* split OSM link generation in an accessible coordinate function
- separates node-based graph creation and compression from edge-based graph creation
- moves usage of edge-based node data-container to pre-processing as well, unifying access to node-based data
- single struct instead of separate vectors for annotation data in engine (single place of modification)
- refactor conditional restriction handling to not use external data (first OSM nodes on ways)
- BREAKING: changes internal file format of osrm.restrictions
- add support for general conditional penalties based on edge-based nodes (requires unique edges between nodes)
Makes turn restrictions into dedicated structures and diferentiates between them via a variant.
Ensures that we do not accidentally mess up ID types within our application.
In addition this improves the restriction performance by only parsing all edges
once at the cost of (at the time of writing) 22MB in terms of main memory usage.
