Direction of point features on ways

Feature: Direction of point features on ways

Description

Specifying which direction of a way is affected by a point feature on one of its nodes.

Group

properties

Tags

direction=forward direction=backward direction=both *:direction=forward *:direction=backward *:direction=both Used on these elements Status: in use

If a point feature is mapped as a node that is part of a way, and that point feature can have a direction-specific effect, then special values are used for the direction key on the node.

Possible values

See also: Forward & backward, left & right

The value of the direction key on the node indicates which direction of the way is affected by the point feature. This can be the forward and/or backward direction of the way.

Value for direction	Description	Taginfo
forward	The point feature affects only the forward direction of the way, i.e. the direction in which the way is drawn in OpenStreetMap.	More details at taginfo More details at taginfo
backward	The point feature affects only the backward direction of the way, i.e. the opposite of the direction in which the way is drawn in OpenStreetMap.	More details at taginfo More details at taginfo
both	The point feature affects both the forward direction and the backward direction of the way.	More details at taginfo More details at taginfo

Possible point features

There are various point features for which this tagging can be used. Most of these are features along highways that affect only one direction of traffic. Some affect other modes of transportation.

Common examples include:

Point feature	Description
highway=traffic_signals	A stopping position along a highway for traffic signals. The direction indicates which direction of travel has to stop here when the light is red.
highway=give_way	A stopping position along a highway for giving way to another highway. The direction indicates which direction of travel has to stop here if needed for giving way.
highway=stop	A stopping position along a highway for stopping and giving way to another highway. The direction indicates which direction of travel has to stop here.
traffic_sign=*	A position along a highway where a traffic sign takes effect. The direction indicates which direction of travel sees the sign.
traffic_sign=city_limit city_limit=both	A position along a highway where you enter or leave city limits, both indicated by traffic signs. The direction indicates which direction of travel enters the city.
highway=emergency_bay	A position along a highway where an emergency bay is present. The direction indicates which direction of travel can access the emergency bay.
railway=signal	A position along a railway where a signal takes effect. The direction indicates which direction of travel is shown the signal.
railway=stop	A stopping position along a railway for boarding or alighting passengers. The direction indicates which direction of travel can stop here.
public_transport=stop_position	A stopping position along a public transport route for boarding or alighting passengers. The direction indicates which direction of travel can stop here.

Namespaced direction keys

Some mappers use a feature-specific namespace for the direction key. In these cases, the key is different, but the values (forward, backward, and both) and their meaning remain the same.

For example, the following direction key variations for the point features mentioned above are in (varying) use:

Point feature	Possible namespaced direction key	Taginfo
highway=traffic_signals	traffic_signals:direction instead of direction	More details at taginfo More details at taginfo
highway=give_way	give_way:direction instead of direction	More details at taginfo More details at taginfo
highway=stop	stop:direction instead of direction	More details at taginfo More details at taginfo
traffic_sign=*	traffic_sign:direction instead of direction	More details at taginfo More details at taginfo
highway=emergency_bay	emergency_bay:direction instead of direction	More details at taginfo More details at taginfo
railway=signal	railway:signal:direction instead of direction	More details at taginfo More details at taginfo
public_transport=stop_position	stop_position:direction instead of direction	More details at taginfo More details at taginfo

It is not clear whether/when/why such prefixes to the direction key are considered desirable and whether this should be encouraged or discouraged.

Possible arguments in favour of prefixes:

• It allows for multiple point features on the same node with different directions.
• The direction proposal reserved the unprefixed direction key for cardinal directions, although that proposal was aware of its co-existence with forward/backward values and there do not seem to be reasons for tagging both a cardinal direction and a forward/backward direction on the same node.
• Prefixes make it easier to track tagging and software support per feature in Taginfo.

Possible arguments against prefixes:

• It unnecessarily complicates the key in an unusual way.
• It is difficult to keep track of which prefix needs to be used for which feature.

Whether a prefix is commonly present or commonly omitted in practice, varies a lot between these features, with no apparent logical pattern, probably due to information about tagging directions being historically scattered across wiki pages and editor presets. For data consumers, if possible, it is advisable to make sure that your software can read the direction of features both with and without the relevant key prefix.

Interpretation if nodes are part of multiple ways

If the node belongs only to a single way, then the interpretation of forward and backward is always straightforward and unambiguous.

If the node belongs to more than one way, even more so with more than two ways, then you have to be careful to avoid ambiguity. In this case, it is important to make sure that all ways have the same orientation. In other words, people travelling along the ways should not switch between travelling forwards and travelling backwards at the node you are tagging. Otherwise, it becomes ambiguous whether a point feature with direction=forward or backward applies to them.

There are some common cases where the point feature is tagged on a node that is the last node of one way and also the first node of another way, for example:

• when a traffic sign tagged as traffic_sign=* results in different traffic rules before and after the sign, e.g. a different speed limit tagged as maxspeed=*;
• when a feature like highway=give_way is marked at the transition between different road surfaces tagged as surface=*.

This is good, as long as ambiguity is avoided by using the same orientation for both ways.

Be careful when reversing ways

Be careful when changing the direction of a way. If you reverse a way, you have to flip the direction tags (interchange forward and backward) on point features on its nodes, unless you also want to reverse the point features. Most editing software will help you do this, but check the result. Some editors may fail handling this tag, might not check the direction on the affected nodes, and might not warn you of possible mistakes. See below for software support.

When doing this, pay extra attention to point features on nodes that are part of multiple ways. Reversing only a single way likely breaks the consistency of the way orientation, accidentally introducing the ambiguity explained above.

Software support

Rendering support

The iD editor renders the directions by adding cones to the map. These cones are drawn as if the feature emits a light signal facing towards the affected traffic flow, i.e. you are affected by the feature if you drive into the emitted cone. iD draws these cones regardless of any namespace prefix, i.e. both the plain direction key and any prefixed *:direction keys are supported. The cones are also displayed correctly if the node is part of multiple ways.

Routing support

OSRM has merged their code for supporting nodes with highway=traffic_signals, highway=give_way, and highway=stop into a Grand Unified Obstacle Treatment. It supports direction=* for all these obstacles, and avoids penalising the route attractiveness if the obstacle's direction does not match the direction of travel. If the direction is not tagged, OSRM will attempt to guess it by looking which direction has a nearby intersection. Specifically for highway=traffic_signals, OSRM also supports traffic_signals:direction=* as a possible alternative to direction=* (if direction and traffic_signals:direction are both tagged, traffic_signals:direction takes precedence). Note that this has changed since its original implementation of traffic signal directions that only supported traffic_signals:direction and not direction.

In Valhalla, the code for supporting nodes with highway=traffic_signals is still separate from its code for supporting nodes with highway=give_way and highway=stop. The former currently supports only traffic_signals:direction=* and not direction=*, whereas the latter two currently require direction=* without namespace.

Support in presets

The presets in the iD tagging schema are currently rather unpredictable with namespace prefixes:

• It uses prefixed traffic_signals:direction in the highway=traffic_signals preset.
• It uses unprefixed direction in the highway=give_way, highway=stop, and highway=emergency_bay presets.
• It uses prefixed traffic_sign:direction in the traffic_sign=* presets.
• It uses prefixed railway:signal:direction in the railway=signal preset.

Support in editors when reversing ways

When reversing a way, current versions of iD, JOSM or Go Map!! are able to detect and check the direction. JOSM (after release 11223) gives a warning when reversing ways with direction-dependent nodes and proposes the opposite value. iD now automatically changes these values too.

Presently, the Potlatch 2 editor will break the direction tag when reversing a way, so if you still use Potlatch 2, be aware when editing.