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.
There is a bug in the deflate compression. Therefore, we do not want
to select this in the default choice for HTTP response compression.
Instead we revert back to the previous precedence, selecting gzip as
the priority.
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 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 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.
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.
It is quite difficult to maintain current Windows CI, because it uses pre-compiled dependencies stored on wolt.com server and there is low chance to find someone who is able to update it.
* Remove highway=bicycle safety bonus
This removes a bonus for a road class that doesn't exist (cycleway would
be correct), but the code was buggy since safety_bonus is nil and caused
an arithmetic exception. We only caught this 4 (!) years later since
recently a way was tagged with highway=bicycle and made it in our OSM
data leading to preprocessing failures.
