Key:direction
 direction
|
 |
| Description |
|---|
Specifies the direction of a feature. 
|
| Group: properties |
| Used on these elements |
    |
Status: approved
|
| 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.
| Value | Element | Description |
|---|---|---|
| <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. |
| <abbreviation> |
|
One of the cardinal directions, ordinal directions, or secondary intercardinal directions, specified as its abbreviation using uppercase characters [NWSE], e.g. NE means north-east. See the image below for all possible values and their meaning.
|
| <cardinal> |
|
One of the four cardinal directions, spelled out in lowercase. That is, north, east, south, or west.
|
This image shows all possible values for direction abbreviations together with the corresponding degrees.
Synonyms for N/S/E/W
The values north/south/east/west are used as synonyms for N/S/E/W and should be treated the same way. Ordinal directions such as north-east should not however be specified in that form.
Spelled-out cardinal directions are used for specifying the posted direction of travel along route relations in Canada, New Zealand, and the United States. As of August 2021, spelled-out cardinal directions were 13 times more common than abbreviations on route=road relations and 9½ times more common than abbreviations on route relations overall.
In general, however, the abbreviations are much more common – see Taginfo comparisons: N/north and S/south, E/east and W/west.
Examples
Bench facing east:
amenity=bench direction=E (or direction=90)
Cave entrance facing north-north-west:
natural=cave_entrance direction=NNW
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.
It can also be used with relations 
type=route:
north / south / east / west
In Canada, New Zealand, and the United States, the official cardinal direction along the route when both directions are mapped as separate relations within a superrelation.
Field of view of a tourism viewpoint or observation tower
For a tourism=viewpoint or observation tower with tower:type=observation, it may be appropriate to tag the field of view with the following pattern:
<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
There is a discussion at the German Forum and at the tagging mailinglist, how the 360° panorama view should be tagged. Tendency would be "0-360".
Simple value
It is the responsibility of the application or rather renderer, how it parses and draws simple values (e.g. 270 or S).
Maps
- 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
Usage
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
On highway=mini_roundabout nodes, a different variant of the direction key is used.
| Value | Element | Description |
|---|---|---|
| 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).
Example
Mini-roundabout running clockwise:
highway=mini_roundabout direction=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.
| Key | Value | Element | Description |
| 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. This problem does not affect iD, JOSM, or Go Map!!, all of which are able to detect and reverse the direction. [1][2] |
For traffic_sign=* there is traffic_sign:direction=forward/backward but unlike for traffic signals also this tag, direction=* is still used quite often.
Parking direction for street parking
The key direction=* can be used to specify special rules on parking directions for back-in and head-in parking. These rules determine the direction of parking/driving into a diagonal or perpendicular parking space. These include back-in angle parking (reversed/back-in diagonal parking - a traffic engineering technique intended to improve the safety of on-street parking) and rules for head in or back in perpendicular parking (e.g. to prevent car exhausts from reaching the roadside). When such rules apply, they are usually signposted with a special sign or are indicated by markings.
If the parking spaces along the road are mapped as attributes of the street, use this key with the street parking prefix (e.g. parking:right:direction=* or parking:both:direction=*). If the parking spaces are mapped separately (tagged with amenity=parking), just use direction=* without prefix. Use one of the following values:
| Value | Illustration | Description | |
|---|---|---|---|
back_in
|
|
|
The vehicle must be parked with the rear facing the side of the road (i.e. with the front facing the middle of the road). In combination with parking:side:orientation=diagonal, this means Reversed/back-in diagonal parking (parking space direction is inverted in this case).
|
head_in
|
|
The vehicle must be parked with the front facing the side of the road (i.e. with the rear facing the middle of the road). Note: Usually only exists in combination with parking:side:orientation=perpendicular, as head in parking is the standard for diagonal parking and does not need to be explicitly tagged. For back-in diagonal parking, see back_in above.
| |
Editor Tools
JOSM
When drawing a line segment, JOSM will display the compass bearing in the bottom toolbar on the left, values reported here can be used directly as a direction=* value.
Other uses
Manoeuvres
In a manoeuvre relation, direction=* is set to a relative direction, such as left or right.
Steps (obsolete)
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.
Transport route directions
Public transport systems around the world use a variety of relative rail directions, some of which have been tagged on route relations. These directions are also commonly used on other modes, such as bus routes. For example:
See also
incline=*highway=mini_roundaboutroof:direction=*for the direction a roof is facingtraffic_signals:direction=forward/backwardfor use withhighway=traffic_signalsthat are part of the waytraffic_sign:direction=forward/backwardfor use withtraffic_sign=*that are part of the waysigned_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=*withdestination=*. - Relations/Proposed/Segmented Tag, proposes usage of "direction" with the values "both", "positive", and "negative" for a specific kind of relation.