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.
* Ensure required file check in osrm-routed is correctly enforced.
The storage module had a stricter check. This keeps the IOConfig
check in sync.
* Correct HTTP docs to reflect summary output dependency on steps parameter.
There is no summary parameter.
* npm audit fix
* print tracebacks and line numbers for Lua runtime errors
* revert format changes
* update changelog with lua traceback, #6564
* revert using protected_function for old GetStringListFromFunction and source_function #6564
* add unit test for line numbers in tracebacks, #6564
* apply clang-format (#6564)
* remove unused test helper function, #6564
* suppress leaksanitizer warnings in extract-tests, #6564
When the extractor encounters a lua runtime error, some osmium objects are not freed. In production this doesn't matter because these errors bring down OSRM. In the tests we catch them to ensure they occur, and the leaksanitizer flags them.
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.
In case we're not able to get access to the unscoped credentials.
Scoped packages are also the recommended approach for projects
managed by a team of developers.
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.
