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.

Rationale

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.

Enter the manoeuvre relation

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 tags 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.

---

Tag details

manoeuvre=XXX

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

direction=XXX

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

Examples

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:

(Mapillary link)