Talk:Key:direction

Angles and cardinal directions don't replace forward and backward directions

Forward and backward directions implicitly refer to an associated way. Thus it is possible to deduce a direction along a way from a given single node, preconditioned that this node is part of exactly one way (or, depending on context, highway).

Angles and cardinal directions state a direction independent from any way. They can (and should!) thus be used on independent nodes which are part of no way. Angles and cardinal directions however can not reliably (and thus should not) be used to indicate the direction along a specific way. This is because the mapping of an angle or cardinal direction to a way can be very ambiguous, intransparent, and subjective. As an example, consider the following real-world junction, showing an area of about 10x10 meters:

How should these questions be comprehensibly answered?

• Node 1 has direction=E, does this mean way B or way C?
• Node 1 has direction=S, does this mean way C or way D, or maybe even way E?
• Node 1 has direction=325, does this mean way A or way F?
• Node 2 has direction=NW, does this mean way B or way E?
• Node 2 has direction=S, which probably means way E, but is relocated later. Will direction=S still mean way E then?
• etc.

Note that a tiny modification along the way might already cause a direction mapping change. It's furthermore complex to implement this mapping in an algorithm.

Since traffic signs and traffic signals always have a direction that is related to the direction of the road, it is much easier and less error-prone to simply use "forward" and "backward" directions for those instead of angles and cardinal directions. --Emkey08 (talk) 12:47, 26 August 2013 (UTC)

This tag isn't just for traffic signs and traffic signals though, but also for benches, billboards, vineyards, roofs (with a prefix) and whatever. These do not have inherent linear directions. So the cardinal directions work for many more feature types.

What I particularly dislike about your edit is that you moved the forward/backward to the top - despite the facts that they only work for a very limited subset of cases, and that the cardinal values are from an approved proposal. But more generally, I'm worried that documentation and editor support gets a lot harder with different value sets for the same key. So the solution I would like the most would be to split off all the binary value pairs (such as forward/backward) to a more specialised key, as has already happened with up/down. --Tordanik 15:13, 26 August 2013 (UTC)

Please feel free to insert the forward/backward section below the angles and cardinal directions section.

I agree that it's not optimal to have different value sets for the same key. On the other hand, different value sets are actually also in use by having

* an integer for a direction given by an angle,

* keywords for the cardinal directions,

* keywords for clockwise and anti-clockwise orientation.

So the problem isn't about the forward/backward values only. From a technical point of view however, those values can luckily all be well distinguished, so the issue is actually more an esthetic one IMHO. Suggestions for improvements welcome. --Emkey08 (talk) 15:53, 26 August 2013 (UTC)

Moved the forward/backward section down as you suggested. --Emkey08 (talk) 07:03, 28 August 2013 (UTC)

Thanks, I think this - along with your most recent edit - indeed improved the page. The fundamental issue with the various value sets is not as easy to solve, of course. I wish I had a good solution. --Tordanik 02:31, 30 August 2013 (UTC)

Lower Case Values

Should not the N, S, E, W etc values be in lower case to match the usual OSM practice of having values in lower case? Warin61 (talk) 09:05, 13 July 2017 (UTC)

In my opinion there's no interest to do that. All standards use these abbreviations in uppercase only. What is important however is to use the English abbreviations (except in translatable names such as streets, where they follow the language conventions). If this causes a problem, we could just say that the values are not case-significant.

They would be lowercase if they were not abbreviated, but OSM practices are for words in lowercase (in British English as much as possible), but this does not apply to abbreviations and acronyms.

As well lettercase is important for measurement units and follow the standards defining them (SI units are very strict about this, and in multiple prefixes an "m" does not mean the same as "M").

So it's best to not change anything, it reflects the most common usages and conventions — Verdy_p ^(talk) 14:14, 13 July 2017 (UTC)

viewpoint vs direction documentation

direction=* is defined as a number; tourism=viewpoint shows an example as direction=0-90, or <number>-<number>. This usage is viewspread but seems not to be documented at all. Either the documentation or the usage should be fixed. --grin ✎ 13:20, 12 May 2016 (UTC)

It seems that the alternate syntax allows specifying a single range of angles

However these precisions are not clearly documented:

• The angles should be normally measured in degrees with 0 to the North, growing positively in the clockwise direction (traditional measurement system used in navigation, as seen on a compass).
  • A good question is still the choice of the North direction: a compass directly gives the magnetic North direction, but this should be corrected to the geographic North (the North used in our coordinates).
  • Most electronic devices correct the measurement by taking into account the geographic position and some table for adjusting this North (but they may still have some errors due to local irregularities, stable or temporary, perturbations of the magnetic field; adjusmtent tables also contain data giving drift speeds over time from a reference date). These devices may not corect the measurement themselves, but may be assisted by software.
  • As we want stable measures, we should use the geographic North (even if viewpoints themselves may evolve over time due to moves of their support, new constructions such as walls, or evolutions in the terrains around including growing plantations/forests, rock falls, collapses, landslides, volcanic activities, or across seasons with tree leaves).
  • However some countries use in their survey data a "grid north" which is defined according to their own projection. Our map uses the WGS84 projection whose "grid north" matches the direction of our "North Pole". In most cases where we indicate a direction with a limited precision (e.g. touristic information, or sides of houses and exposure of windows), the difference is insignificant (only small fractions of a degree).
• With a single angle, note that these angles may be negative (e.g. 45 means North-East, -45 means North-West, -90 means West and is the same as 270): the values are interpreted modulo 360.
• With two angles in a range the notation "number-number" may be confusive if negative numbers are used. So only positive numbers should be used:
  • the first angle being in range [0..360)
  • the second angle (higher than the first one) in range (0..720) (so that an angle range can span over the North direction, with angles going from westward to eastward)
  • a range "90-45" (where the second angle is lower than the first one) would be confusive (if interpreted only modulo 360 and clockwise, it would actually NOT mean the same as the octant "45-90" from NE to N clockwise, but would actually mean its complement "90-405" passing clockwise through E, SE, S, SW, W, NW, N, NE): it's perfecly possible (and in fact frequent) to span more than 180° of viewport visibility.

Some other objects may need more than one angle ranges, separated by ";", e.g. radio emitters or maritime signalisation for their coverage.

— Verdy_p ^(talk) 15:22, 12 May 2016 (UTC)

Both ways

Mention that if a e.g., sign is two sided, e.g.,

direction=-25;155

is how to tag it, as confirmed by the in-editor (iD) rendering. Same idea for more than two too. Jidanni (talk) 17:32, 17 November 2022 (UTC)

I assume you're only referring to objects that are identical on both sides? Then the tag 'sides=2' together with your suggestion makes sense to me. Note to use positive numbers instead of -25 in your example. Famlam (talk) 08:07, 21 November 2022 (UTC)

So far, my assumption has been that these should be tagged by picking one direction as the direction=* value and adding two_sided=yes or sides=2. This is in line with the established conventions for roof:direction=* (where you also pick one of the two possible directions of a symmetrical roof), and it has the benefit that any editor tools for displaying or editing the direction don't need to give this special treatment. --Tordanik 11:06, 22 November 2022 (UTC)

@Famlam and Tordanik: Currently, 20,665 nodes have a direction=* that contains a semicolon, far more than are tagged two_sided=yes and slightly more than have sides=* values greater than 1. [1] No doubt some of this usage is influenced by the fact that iD handles it gracefully, but it also doesn't promote this usage. I think the main reason is that it's consistent with other familiar keys.

sides=* may be adequate for some kinds of objects, but it doesn't generalize to multi-sided features that don't form regular prisms, for example a wedge-shaped advertising=billboard or a street clock with a missing face. When multiple signs are stacked on a single post, I prefer to map multiple features, but if you prefer to map a single consolidated node with multiple values in traffic_sign=*, then there's no guarantee that the signs face the same directions.

• 

  Three clock faces at 90-degree angles

• 

  Three clock faces at 60-degree angles

• 

  Street name signs mounted on the same pole

 – Minh Nguyễn ^💬 00:30, 24 November 2022 (UTC)

Vertical component

In commons:File:19940720skmbnd.jpg, we observe the plaque next to the person not only has direction=180, but also a vertical component! Please be sure to mention how to specify that too. Jidanni (talk) 08:19, 13 March 2023 (UTC)

Plaques embedded flat

Say how to deal with plaques and gravestones intended to be read by a person standing directly over them. Jidanni (talk) 15:26, 3 June 2023 (UTC)