|Specifies the direction of a feature.|
|Used on these elements|
|Tools for this tag|
The key direction is used in a variety of situations to specify the direction of a feature.
Angles and cardinal directions
Angles and cardinal directions can be used for features which are mapped as either an independent node or an area. It allows to specify directions that are not related to any existing way. For nodes, examples are the direction of a cave entrance, cliff, view, bench, or hunting stand. For areas, examples are the direction of planting in a vineyard or planted forests.
|<number>||The given number specifies the degrees from 0 to 359 in which the feature faces, where 0 is equal to northward, using clockwise rotation.|
|<cardinal>||One of the cardinal directions, specified using uppercase characters [NWSE], e.g. |
This image shows all possible values for cardinal directions together with the corresponding degrees.
The values direction=north/south/east/west are used as synonyms for direction=N/S/E/W and should be treated the same way. Combinations like e.g.
north-east should not however be specified in that form.
Bench facing east:
amenity=bench direction=E (or direction=90)
Cave entrance facing north-north-west:
Note that traffic signs traffic_sign=* are tagged the way the sign faces, i.e., against the direction of travel. For example, when travelling west, signs are facing east, so you tag them with direction=90 or direction=E.
Field of view of a tourism viewpoint
<number>-<number> // e.g. 90-270 <cardinal>-<cardinal> //e.g. E-W
Please note that the sense of rotation is always clockwise. 90-270 or E-W means, for instance, the field of view reaches from East via South to West.
360° Panorama view
It is the responsibility of the application or rather renderer, how it parses and draws simple values (e.g. 270 or S).
- OpenTopoMap renders the viewpoint icon along their rules
- https://osmtools.github.io/direction/ draws direction values as circles or semicircles
- Historic.Place draws direction, Example (dead link?)
Some printed maps for tourists (not based on OSM data) show direction of viewpoint, it gives some info on what is visible from a given place (sometimes view is restricted, in mountains typically by forest). direction tag allows doing the same with OSM data.
Clockwise and anticlockwise
|anticlockwise||The mini-roundabout runs anti-clockwise.|
|clockwise||The mini-roundabout runs clockwise.|
Note that the default value for roundabouts and mini-roundabouts is anti-clockwise in most countries (or territories) driving on the right side of bidirectional highways, and clockwise in other countries (or territories) driving on the left side (e.g. United Kingdom or Hong Kong SAR).
Roundabouts and mini-roundabouts are themselves not bidirectional so their direction is almost always implicit (given the applicable national or territorial default rules), and cases where the effective direction is reversed (needing this tag explicitly) are extremely rare everywhere (they exist only when a small roundabout, for example in a service/industrial/harbour way, is just aside another major bidirectional street and its normal rotation direction would require vehicles to go in opposite direction of the major street without enough space left for another lane separation: collisions would be unavoidable).
Mini-roundabout running clockwise:
Forward and backward
The directions forward and backward can be used to specify the direction of a feature relative to an existing way. This only applies to features which are tagged on a node that is part of a way. Examples may include directed traffic signs.
|direction||forward||(part of )||The direction is forward, relative to how the associated way was drawn in the editor.|
|direction||backward||(part of )||The direction is backward, relative to how the associated way was drawn in the editor.|
Note that this tagging is ambiguous in cases where the node belongs to more than one way! For this reason, use the forward and backward directions only on nodes which are part of exactly one way (or, depending on context, highway=*). Avoid junction nodes and nodes between two ways as well (where they have been split, but are connected by a node). If in doubt, better simply to insert a new node into the way which can be freshly tagged.
Do not use the direction tag for highway=traffic_signals that are part of a way, instead use traffic_signals:direction=forward/backward.
For traffic signal nodes placed at their real position next to the road, the direction tag as described here with cardinal directions or angles as the value should be used.
|Some editors don't recognize this tag. When reversing the direction of the way, the direction on the nodes of that way might not be changed, and you won't be notified of possible mistakes. So be careful when changing the direction of a way. JOSM is one editor which is able to detect and reverse the direction.|
The tags direction=up and direction=down have been used on highway=steps to specify if the stairs lead up or down in the direction of the way. This has since been obsoleted by incline=up and incline=down.
- roof:direction=* for the direction a roof is facing
- traffic_signals:direction=forward/backward for use with highway=traffic_signals that are part of the way
- signed_direction=* where signs face a particular diection.
- Proposal about the (compass) direction of an asymmetric area or point feature
- Forward & backward, left & right for determining the overall geographic direction of a way (compare first node to last node)
- Do not confuse direction=* with destination=*.
- Relations/Proposed/Segmented Tag, proposes usage of "direction" with the values "both", "positive", and "negative" for a specific kind of relation.