The change clarifies the conditions for forcing routing steps and
simplifies the codebase to support it.
- Makes explicity the search runtime condition for forcing a routing
step. Namely, the node is a source of the forward and reverse searches,
and it's one of the pre-identified nodes that requires a step to
be forced.
- Consolidate the two lists of force nodes into one. Not only is there
no algorithmic value in separating the nodes by geometric direction,
the improvements to via-routes with u-turns mean atleast one of these
lists will be empty for any search.
- Rename 'force loop' to 'force step'. This moves the code away
from the original CH-specific language for checking for self-loops
in the case where this condition is met. MLD does not have loops.
Additional cucumber tests are added to cover the logic related to
negative search weights and forcing routing steps on via-route
paths.
* Added approach on the opposite side of the road.
* Additional test and docs coverage for opposite approach
---------
Co-authored-by: Aleksandrs Saveljevs <Aleksandrs.Saveljevs@gmail.com>
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 adds support for disabling datasets, such that specific
files are not loaded into memory when running OSRM. This enables users
to not pay the memory cost for features they do not intend to use.
Initially, there are two options:
- ROUTE_GEOMETRY, for disabling overview, steps, annotations and waypoints.
- ROUTE_STEPS, for disabling steps only.
Attempts to query features for which the datasets are disabled will
lead to a DisabledDatasetException being returned.
Currently `npm test` runs the Cucumber suite with a matrix
configuration for selecting the algorithm (CH, MLD) and data loading
(shared-memory, mmap) options.
However, there is a third data loading option, 'load directly',
which is to directly load the datasets into the osrm-routed process memory.
The code paths for each data loading option are distinct:
Storage::Run + SharedMemoryAllocator
MMapMemoryAllocator
ProcessMemoryAllocator
This commit adds direct data loading as part of the Cucumber
configuration matrix.
This will ensure optional dataset support can be added without any
regressions.
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.
Badly constructed OSM intersections can create OSRM intersection
views that have no valid turns.
The guidance code for segregated intersections tries to look
ahead to the second intersection to ensure lanes are announced
intuitively.
Currently, OSRM assumes there are always turns at the second
intersection that we should consider. This commit corrects
this assumption so that it can now handle badly constructed
OSM intersections with no turns.
Due to some rather complex logic that tries to calculate intersection
angles by looking further up the road, it's possible to return
an intersection view that is missing a u-turn - something which
is assumed to exist in later guidance calculations.
We apply a fix here by ensuring the u-turn is always included in
the returned view.
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.
Currently there is an edge-case in the turn restriction implementation,
such that routes can not be found if the target input location snaps
to a way used in a (multi) via restriction.
With the addition of snapping input locations to multiple ways, we
can now also snap to the "duplicate" edges created for the restriction graph,
thereby fixing the problem.
This is achieved by adding the duplicate restriction edges to the
geospatial search RTree.
This does open up the possibility of multiple paths representing exactly
the same route - one using the original edge as a source, the other
using the duplicate restriction graph edge as source. This is fine,
as both edges are represented by the same geometry, so will generate
the same result.
This PR improves routing results by adding support for snapping to
multiple ways at input locations.
This means all edges at the snapped location can act as source/target
candidates for routing search, ensuring we always find the best route,
and not the one dependent on the edge selected.
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.
The internal representation of turn restrictions expects only one
`from` way and only one `to` way.
`no_entry` and `no_exit` turn restrictions can have multiple `from` and
`to` ways respectively. This means they are not fully supported by
OSRM's restriction parser.
We complete support for these turn restriction types by parsing all
ways and converting a valid restriction with multiple `from`/`to` members
into multiple internal restrictions.
Currently /trip supports finding round-trip routes where only the
start or end location is fixed. This PR extends this feature to
non-round-trip requests.
We do this by a new table manipulation that simulates non-round-trip
fixed endpoint requests as a round-trip request.
* Fix test cache to consider MLD executable changes
Currently the test cache is not invalidated if changes to
osrm-partition or osrm-customize executables. This is problematic
when these executables make breaking changes to the data format.
We fix this by including both in the list of executables that
can invalidate the test cache.
* Executables use hyphens
OSM data contains many mistakes that tag kerbs as highway barriers
when instead they are only describing highway crossings.
This PR updates the default car profile to handle these mistakes
and unblock routing on the affected highways.
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.
In situations where there is not a valid source or target phantom
node (e.g. when snapping to an edge with a zero weight), a
heap assertion will fail in the MLD alternative search code.
We fix this by checking for empty heaps before proceeding with
the search.
Fixes#5788
Table queries where source and destination are phantom nodes
on the same one-way segment can fail to find valid routes.
This is due to a bug in the MLD table generation for the
special case where the query can be simplified to a
one-to-many search.
If the destination is before the source on the one-way segment,
it will fail to find a route.
We fix this case by not marking the node as visited at the start,
so that valid paths to this node can be found later in the search.
We also remove redundant initialization for the source
node as the same actions are performed by a search step.
