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?
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)
- 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)
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 on the compass with 0 to the North, growing positively in clockwise direction (traditional measurement system used in navigation).
- 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 lower than the second angle
- the first angle being in range [0..360)
- the second angle 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" could also be confusive (if interpreted only modulo 360, it would actually NOT mean the same as the octant "45-90" from NE to N clockwise, but would mean its complement "90-405" passing clockwise through E, SE, S, SW, W, NW, N, NE)
- 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)