When executing the car.lua profile in generates warnings

[victxr-dev]

When you create a docker image of the recent version and run the car.lua profile is when it generates the following warning shown below, the other profiles do not generate it, use the docker image that was uploaded 3 years ago and does not generate the warning.

Note: the car.lua works and gives results but the question is, if these warnings are future problems with the expected results in certain locations?

[[info] Collecting traffic signal information on 705 signals... [warn] OSM node 381645432 has a unidirectional traffic signal ambiguously applied to multiple ways

[warn] Level 1 unreachable boundary nodes per cell: 0.00070404 sources, 0.00011616 destinations

[warn] Level 1 unreachable boundary nodes per cell: 0.004101 sources, 0.002548888 destinations
[warn] Level 2 unreachable boundary nodes per cell: 0.017027 sources, 0.0143243 destinations

[warn] Level 1 unreachable boundary nodes per cell: 0.00428484 sources, 0.00428484 destinations
[warn] Level 2 unreachable boundary nodes per cell: 0.0462162 sources, 0.0262182 destinations
[warn] Level 3 unreachable boundary nodes per cell: 0.16 sources, 0.08 destinations
Unreachable nodes statistics per level
[warn] Level 1 unreachable boundary nodes per cell: 0.00071616 sources, 0.00983636 destinations
[warn] Level 2 unreachable boundary nodes per cell: 0.0097027 sources, 0.0047027 destinations
[warn] Level 3 unreachable boundary nodes per cell: 0.09 sources, 0.049 destinations](url)

[shinomontaz]

Hi!

It seems there is no big problem in the log due to fact, that new OSRM versions are more strict and verbose about data issues, and emit warnings that older versions just ignored.

There is 2 problems reported in your log: one for traffic signals, second for unreachable nodes.
Second one is could be a real problem, but not in tihs case: numbers in warnings are tiny fractions. Until we see large percentages (e.g., 10–50% of boundary nodes unreachable) - all is ok, otherwise it would indicate serious data or extraction issues, and routing to some areas would fail.
Also good rule is if we are not seeing routing failures or “no route found” errors,
We can ignore these warnings.

As fof traffic signals - it seems the root problem is OSM data itself for this traffic signal.
OSRM found a traffic signal node (in OSM) that asociated with more than one way, and those ways are going in different directions.
“Unidirectional” means the signal is tagged as affecting only one direction ( highway=traffic_signals on a node that's part of two or more ways).
Ambiguously applied means OSRM can’t determine which way/direction the signal is supposed to affect.

This definetely can affect routing, but not ruin it.
OSRM will make routes, but the effect of this signal (on turn penalties or waiting times) may be ignored or mis applied at that intersection.