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 |
| Tags |
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
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. |
|
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. |
|
both
|
The point feature affects both the forward direction and the backward direction of the way. |
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_limitcity_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.
|
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
|
|
highway=give_way
|
give_way:direction instead of direction
|
|
highway=stop
|
stop:direction instead of direction
|
|
traffic_sign=*
|
traffic_sign:direction instead of direction
|
|
highway=emergency_bay
|
emergency_bay:direction instead of direction
|
|
railway=signal
|
railway:signal:direction instead of direction
|
|
public_transport=stop_position
|
stop_position:direction instead of direction
|
It is not clear whether/when/why such prefixes to the direction key are considered desirable and whether this should be encouraged or discouraged. Whether such a prefix is commonly present or commonly omitted in practice, varies a lot between these features. For data consumers, if possible, it is strongly 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 asmaxspeed=*; - when a feature like
highway=give_wayis marked at the transition between different road surfaces tagged assurface=*.
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. Current versions of iD, JOSM or Go Map!! are able to detect and check the direction. Other editors may fail handling this tag, might not check the direction on the affected nodes, and might not warn you of possible mistakes.
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
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.