Proposal:Direction

From OpenStreetMap Wiki
(Redirected from Proposed features/direction)
Jump to navigation Jump to search
The Feature Page for the approved proposal direction is located at Key:direction
direction
Proposal status: Approved (active)
Proposed by: davidsv; Zverik
Tagging: direction=0-360 or N/E/S/W
Applies to: node, area
Definition: Gives the compass direction of an asymmetric area or point feature
Rendered as: rotated icon or texture
Draft started:
Proposed on: 2009-08-22
RFC start: 2011-08-10
Vote start: 2011-08-26
Vote end: 2011-09-11
A sample compass

For asymmetric areas or point features, this gives the compass direction of the asymmetry or which direction the node object points towards. The direction could be measured by a compass or determined visually. North on the map means top side, the direction of increasing latitude, or y coordinate in google projection.

For nodes, examples are the direction of the opening of a cave, cliffs (with small extensions), the direction of a view, the facing of a bench or a sign.

For areas, examples are the direction of planting in a vineyard or planted forests only runnable in one direction.

What is a direction

Point features

Imagine a point right in the geometric center of a feature: inside a metal pole for a road sign, at the center of a bench or a painting, inside the entrance to a cave or a telephone booth. Now determine a point where an observer should stand to see the most important side of the point feature: a sign contents, an entrance or a door, a painting, a face of a man sitting on a bench. The angle between the direction to the Grid North and the direction to that point where the observer should be located is the needed value for the direction tag.

A bench facing SE and a stop sign facing 300 degrees (roughly NWW)

Areas

For areas with flow or implicit single direction it is that direction. For example, for river bodies the direction is that of the water flow.

If the area has a anisotropic structure (for example, a farmland), the direction is along the visible lines. Any of two or more directions can be chosen.

Here are a lot of anisotropic fields with different directions

When the lines in the area resemble an orthogonal or hexagonal (or any other) grid, the angle for direction can be chosen along any of 4, 6 or more ways, if the priority direction cannot be established.

Values

There are three ways to tag a direction.

Angles.svg

Cardinal

An upper-case latin characters of [NWSE] meaning one of the cardinal directions.

Example: direction=NE, meaning an object faces north-east direction.

In English

A simple cardinal direction can also be stated as a single English word in lower case: direction=north/east/south/west. It should be treated the same as the usual cardinal direction, looking only at the first letter of the word. No complex directions (north-east and such) are allowed in this form.

Degrees

A number, preferably integer, between 0 and 360, which means a number of degrees from the North clockwise.

Example: direction=45, meaning an object faces north-east direction.

Other Values

The direction tag is already used for other features.

  • node direction=clockwise/counterclockwise/anticlockwise for highway=mini_roundabout. Roundabouts are not POIs, and do not have an angular direction, so this proposal does not affect them.
  • way direction=up/down for highway=steps (has been superseded by incline=up/down). This proposal is not applicable to ways, only to areas and nodes.
  • way direction=forward/backward. This usage is not documented in wiki, but it must be related to highways (probably used together with oneway=yes), so again, this proposal does not affect it.

Discussion

Please use the Talk page for discussion.

Voting

Please add {{Vote|yes/no}} [your comment] --~~~~

  • I approve this proposal I approve this proposal. --KaChing_Cacher 00:39, 08 September 2011 (BST)
  • I approve this proposal I approve this proposal. --Zverik 07:39, 26 August 2011 (BST)
  • I approve this proposal I approve this proposal. --Tordanik 08:04, 26 August 2011 (BST)
  • I approve this proposal I approve this proposal. with the exception of the "In English" values. (I think that the set of 16 cardinal points and numerical values are enough for data-users to parse, and allowing "east" etc will inevitably lead to some mappers using "north-east" which data-users might not have allowed for.) -- Rjw62 08:21, 26 August 2011 (BST)
  • I approve this proposal I approve this proposal. with the exception of the "In English" values. -- ErshKUS 09:46, 26 August 2011 (BST)
  • I approve this proposal I approve this proposal. --Dieterdreist 10:29, 26 August 2011 (BST)
  • I oppose this proposal I oppose this proposal. Draw an OSM line and you have a direction. We don't need tags for that. --Pieren 11:55, 26 August 2011 (BST)
  • I am not sure with this proposal. The Relations/Proposed/Directional_node is better. If the relation proposal will be accepted, then I vote no for this proposal. And I vote yes for this, if the relation will be declined. Because of this proposal is better than nothing. --Surly 11:17, 27 August 2011 (BST)
  • I approve this proposal I approve this proposal. Relations/Proposed/Directional_node is better, but may not be usable in all cases. Since the two shemes do not conflict significantly, I vote for 'freedom of choice'
  • I oppose this proposal I oppose this proposal. This is a totally different concept than already implemented in all applications. We should stick to vector data and have an arrow by a start and a destination node. --Lulu-Ann 14:40, 2 September 2011 (BST)
  • I approve this proposal I approve this proposal. with the exception of the "In English" values. Note that there's a mistake in the compass card (Angles.svg): NWW/SWW/NEE/SEE should be WNW/WSW/ENE/ESE. --Fkv 19:49, 2 September 2011 (BST)
  • I oppose this proposal I oppose this proposal. as Pieren and Lulu-Ann --wiso 16:24, 6 September 2011 (BST)
  • I oppose this proposal I oppose this proposal. Additional values to the already existing key "direction" would be o.k., but it's not necessary to build a new key for it. I think this proposal will be unnecessary.--R-michael 07:40, 8 September 2011 (BST)
  • I oppose this proposal I oppose this proposal. why do we need to tag this? A sign usually is 90° to the nearby road. And the facing of a bench is just unneccessary. --Ngt 11:23, 8 September 2011 (BST)
  • I approve this proposal I approve this proposal. very helpfull at viewpoints with particular sight --Noframe 12:21, 8 September 2011 (BST)
  • I approve this proposal I approve this proposal. [Usefull for many types of objects like views, cameras, roads, etc. Directional_node would add to much clutter, although it could be useful to also have a relation describing an object looking at another object] --Webmind 14:02, 20 February 2012 (UTC)

See Also