-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Manoeuvre override tag
As of OSRM 5.16, OSRM supports a data-driven way to set the turn instructions returned by the routing engine.
This page describes an OSM relation that allows encoding "routing instruction hints" in OSM as additional metadata on top of the existing network topology.
OSM mapping isn't always consistent, and there can be several "valid" ways to model a single intersection. The shape of the modeling doesn't always really match the road surface (which is what humans see when they're traveling), particularly for complex, and condensed intersections, even though the connectivity is correct and valid. Consider the following alternative ways of mapping an SPUI:
All of these have valid network topology - you can only transition across this intersection in legal ways.
However, from the perspective of the routing engine, the "internal ways" for the intersection are hard to decode. Do they represent real drivable ways that need turn annoucements, or are they "virtual" ways that are simply there to provide network connectivity?
Another good example of the disconnect between network modeling and the shape of the pavement:
The circled section here is somewhat of a modeling artefact, and the routing engine needs to ask the question "Do I announce a turn onto this section, or not?"
This is not always an easy decision to make - there are many ways of drawing complicated intersections, all of them valid from a topology point of view, but each can be interpreted differently when it comes to announcing guidance.
Instead of violating OSM's Rule 2 - Don't tag for the renderer router to work around various routing engines differences in heuristics, we can be explicit about what kind of navigation should be emitted through complex intersections.
The purpose of the manoeuvre relation is to describe the "human interpretation" of a manoeuvre through a complicated intersection. It's a hint to a routing engine that "if a route follows this path, here's what you should announce", bypassing heuristics to interpret the way OSM is drawn here.
In XML form, a manoeuvre
relation looks like this:
<relation>
<tag k="type" v="manoeuvre"/>
<member type="way" ref="1234" role="from"/>
<member type="way" ref="4567" role="to"/>
<member type="node" ref="999" role="via"/>
<tag k="manoeuvre" v="uturn"/>
<tag k="direction" v="slight_left"/>
</relation>
The important tag
s on the relation are:
tag | description |
---|---|
type=manoeuvre |
This marks the relation as a manoeuvre relation that OSRM will use. The American spelling of maneuver is also acceptable. |
manoeuvre=XXX |
This tells OSRM what manoeuvre to emit instead of the internally calculated value. The american spelling of maneuver will also work. |
direction=XXX |
This tells OSRM what direction the manoeuvre is in. |
Both manoeuvre=
and direction=
are optional. If neither is supplied, the relation will have no effect.
The member
values are as follows:
role |
type |
Description |
---|---|---|
from |
way |
Required, only one member. The first way that describes the manoeuvre. |
to |
way |
Required, only one member. The last way that describes the manoeuvre. |
via |
way |
Optional, zero or more members. Any ways that connect the from and to ways to form a complete path. |
via |
node |
Required, only one member. The point at which the override will be applied. |
The members
identify the actual manoeuvre itself. If a route is calculated that traverses the from
, via
, and to
members, then the override matches, and the manoeuvre=
and direction=
overrides will be applied at the via
node.
The manoeuvre=
tag allows you to modify the type of instruction emitted by OSRM at a location. The main use
here is to emit the instruction type that a human would expect, when OSRM's understanding of the OSM model
falls down. Many intersections in OSM have complex "internal edges" that don't match anything you can see on the road, and it can be difficult to emit instructions that match what a human would expect. The manoeuvre=
tag can be used to override values that OSRM comes up with on its own.
Both British (manoeuvre
) and American (maneuver
) spellings will work. If both are supplied, British spelling is preferred.
The manoeuvre=
tag may contain the following values:
Value | Description |
---|---|
uturn |
OSRM should emit a uturn instruction at the via location |
continue |
OSRM should emit a continue instruction at the via location |
turn |
OSRM should emit a turn instruction at the via location |
fork |
OSRM should emit a fork instruction at the via location |
suppress |
OSRM should emit no instruction at the via location |
OSRM makes a best-guess at turn angles based on the shape of the drawn OSM geometry. For complex intersections, sometimes this guess is wrong, and a human on the ground will perceive a different angle than what is drawn in OSM. Overriding the direction=XXX
value allows you to set a "human perceived" angle for a manoeuvre.
The direction=XXX
tag may contain the following values:
Value | Description |
---|---|
left |
The manoeuvre at the via location is a left
|
slight_left |
The manoeuvre at the via location is a slight_left
|
sharp_left |
The manoeuvre at the via location is a sharp_left
|
sharp_right |
The manoeuvre at the via location is a sharp_right
|
slight_right |
The manoeuvre at the via location is a slight_right
|
right |
The manoeuvre at the via location is a right
|
straight |
The manoeuvre at the via location is a straight
|
The left turn from New York Avenue in Washington DC onto I-395 South (Center Leg Freeway) involves turning left onto a way that joins the divided road, then turning left again onto the I-395 highway itself.
Without additional hints, OSRM emits the following instructions:
However, from the drivers point of view, this should just be a simple left turn. For better or worse, the cross-road has been modelled as a highway=motorway_link
(4th street to the north is highway=tertiary
, and to the south it'ss highway=primary
).
which triggers the "Take the ramp" part of the instruction. (Side note: the choice of highway=motorway_link
here seems likely to be a workaround mapped for a different routing engine's heuristics for generating turn-by-turn instructions).
The satellite view shows the difference between the real roads and how OSM is modelled here:
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