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.
Each leg of a via-route supporting u-turns does not need to consider
force-loops. Negative weight checks are sufficient to prevent
incorrect results when waypoints are on the same edge.
* 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>
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.
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.
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.
Currently route results are annotated with additional path information,
such as geometries, turn-by-turn steps and other metadata.
These annotations are generated if they are not requested or returned
in the response.
Datasets needed to generate these annotations are loaded and available
to the OSRM process even when unused.
This commit is a first step towards making the loading of these datasets
optional. We refactor the code so that route annotations are only
generated if explicitly requested and needed in the response.
Specifically, we change the following annotations to be lazily generated:
- Turn-by-turn steps
- Route Overview geometry
- Route segment metadata
For example. a /route/v1 request with
steps=false&overview=false&annotations=false
would no longer call the following data facade methods:
- GetOSMNodeIDOfNode
- GetTurnInstructionForEdgeID
- GetNameIndex
- GetNameForID
- GetRefForID
- GetTurnInstructionForEdgeID
- GetClassData
- IsLeftHandDriving
- GetTravelMode
- IsSegregated
- PreTurnBearing
- PostTurnBearing
- HasLaneData
- GetLaneData
- GetEntryClass
Requests that include segment metadata and/or overview geometry
but not turn-by-turn instructions will also benefit from this,
although there is some interdependency with the step instructions
- a call to GetTurnInstructionForEdgeID is still required.
Requests for OSM annotations will understandably still need to
call GetOSMNodeIDOfNode.
Making these changes unlocks the optional loading of data contained in
the following OSRM files:
- osrm.names
- osrm.icd
- osrm.nbg_nodes (partial)
- osrm.ebg_nodes (partial)
- osrm.edges
The data facade interface contains numerous methods for looking up
datapoints by identifiers.
Many of the parameters use the NodeID or EdgeID types. However, these two
identifier types are used for representing three different contexts:
1. Node-based graph edges and nodes
2. Edge-based graph edges and nodes
3. Packed geometries
Consider the use of identifier parameters in these examples:
---
GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge
GetUncompressedForwardWeights(const EdgeID id) <- packed geometry
IsLeftHandDriving(const NodeID id) <- edge-based node
GetBearingClass(const NodeID node) <- node-based node
---
This mixing of contexts within the same interface makes it
difficult to understand the relationships and dependencies between
the OSRM datasets.
For 1. and 2. we continue to use the NodeID and EdgeID types, but
change the interface parameter names to identify them as
edge-based or node-based graph properties.
For 3. we define a new type definition, PackedGeometryID.
These changes are to aid with readability. A next step would be
to strongly type these definitions, leveraging the Alias template
already used for OSM identifiers.
When using non-default constructors for the API parameter classes,
vector arguments like coordinates and hints are copied at least once
(twice when passed as lvalue arguments).
Enable perfect forwarding of BaseParameter arguments and
pass-by-value in the constructor that uses the argument. This
ensures we copy at most once (zero for rvalue arguments).
