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.
