-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Debugging
Problems with routing in general fall into one of two categories:
-
Problems with the data
-
Problems with the routing algorithm
Speaking from experience, the second case is extremely less likely. So you always want to start with examining the data. This guide is not 100% comprehensive, but should cover most of the common cases.
It should provide a link to the offending route (that is a link to the OSRM demo site) and a short description of the expected result.
The routing engine does not find a path from the start point to the end point. On the demo site this typically looks like a map with just two markers but no route in between.
Cause of such errors can be:
-
Connectivity problems
-
No street-segments are near either end of the route (e.g. if you place it in the middle of Siberia that might happen)
(2.) is expected behavior.
Varies in the severity:
-
Obviously inefficient routing, instead of taking a straight 10 meter segment the routing takes 2km detour.
-
The route looks plausible, but is longer than expected.
Causes:
-
Connectivity problems
-
The measurement of "how good is a route" differs from the user as to what is specified in the profile. For example, some profiles might add very high penalties for crossing toll booths. The resulting route will typically take detours. So it will not be the fastest route, but optimal in a sense that is less obvious to the user.
(2.) is more likely when the route looks plausible but sub-optimal.
Causes:
-
There should be a barrier in the OSM data, but it is actually not there.
-
There is a barrier in the data, but the profile OSRM uses does not consider it.
The estimations we do on routing time are rather rough. For good estimations you
need real traffic data, which is not part of OSM. This is something that highly depends on the
profile you use with OSRM.
For car speeds we usually use 85%
of the tagged maximum speed and fall back to
maximum speeds based on the highway class if there is no tag.
Crucial for this kind of problems is to locate the exact location where the breakage occurs. Just try to move one of the markers back until it finds a route again. Confirm by placing a marker shortly before and after that point.
Once the location is verified, you can open the concerting section of the map in iD or JOSM directly from the view on the demo site:
One of the starting points is in an "impasse". Examples for this are for example one-way streets that don't have an exit, or roads on parking lots that are not connected to the street.
How to resolve: Figure out exactly where the impasse starts. Check if it is actually meant to be that way. Open it in iD or JOSM and fix it.
There is a barrier node in path. This highly depends on what is considered a inaccessible in the profile. For examples stairs are fine for the foot profile but a problem in the car profile.
How to resolve: Is that barrier node actually correct? Does it make sense to consider this kind of barrier in the context of the profile? If the data is incorrect, change that in OSM. If you think the profile is incorrect, open an issue and propose a change.
Sometimes a way looks connected on the map, but actually the end points are not connected. The routing engine can not know whether they are supposed to be connected or not, even if they are placed perfectly on top of each other.
How to resolve: Open it in iD or JOSM and connect the concerning street segments.
During each data update, the network is analyzed for badly reachable portions. There's a tile layer available that visualizes identified issues on z14+: http://tools.geofabrik.de/osmi/tiles/routing_i/{z}/{x}/{y}.png
The layer can also be shown through the OSRM demo UI.
I think this page is obsolete. I add few commet since I tried to compile OSMR recently using Codeblocks 20.03 on Windows 10. What I found was that
Several extra libraries ave to be installed like BZip2, lua. I was using MSYS2 so I did, pacman -S mingw-w64-x86_64-bzip2 pacman -S mingw-w64-x86_64-lua pacman -S mingw-w64-x86_64-zlib
instal Intell tbb https://github.com/oneapi-src/oneTBB/releases Extract it to a folder (e.g., C:\tbb).
Ensure to add TBB Path to CMake Command and that the bin folder of MinGW or MSYS2 (e.g., C:\msys64\mingw64\bin) is added to your system PATH environment variable.
Then in osrm-backend\build run
cmake -G "CodeBlocks - MinGW Makefiles" .. -DCMAKE_BUILD_TYPE=Release -DTBB_INCLUDE_DIR="C:/tbb/include" -DTBB_LIBRARY="C:/tbb/lib/intel64/gcc4.8/libtbb.so"
cmake -G "CodeBlocks - MinGW Makefiles" .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-fno-lto -mconsole" -DCMAKE_EXE_LINKER_FLAGS="-Wl,-e,mainCRTStartup"
It may be enough to compile.
However for some compilation problems I add to do
- remove "-Werror # Treat all warnings like error" in a CMakeLists.txt file
- add in shared_memory.hcp in line 208: (void)lock_file; // This explicitly marks lock_file as used to avoid warning of unused variable
- to avoid an Link Time Optimization (LTO) error run cmake -G "CodeBlocks - MinGW Makefiles" .. -DCMAKE_BUILD_TYPE=Release -DIPO=OFF
- put OFF in option(ENABLE_LTO "Use Link Time Optimisation" OFF) and I add set(CMAKE_INTERPROCEDURAL_OPTIMIZATION OFF) in Cmake
I finally gave up because of Windows console incompatibility (Winmain not found) without knowing the reason even after having, In codebleocks Project properties, Built target, type put Console application