Proposal talk:Direction

Exact definitions needed

This proposal should try to provide the precise meaning of "direction" for common examples, as people might intuitively interpret this differently (e.g. "facing" vs "travel direction" for signs). If I understand the intention correctly, then the tag means "facing" for every object that has a "front" or door, such as billboards, signs, benches, vending machines, telephone booths, ...? For the more exotic meanings such as planting direction, which are not at all obvious, we should maybe even consider to use a more expressive key like planting_direction. --Tordanik 12:35, 10 August 2011 (BST)

Thanks, I've added a chapter on that, with illustrations. --Zverik 14:26, 10 August 2011 (BST)

heading not direction

"heading" is a more precise term than "direction". Brycenesbitt

I agree. But direction is already widely used, I'm just documenting it to be added to the wiki. --Zverik 06:19, 25 August 2011 (BST)

Fixed angles.svg

As Fkv has noted in the voting section (thanks!), Image:angles.svg had typos for some of the compass directions. I've corrected them and uploaded a new image revision. --Tordanik 15:47, 5 September 2011 (BST)

Thanks! --Zverik 17:09, 5 September 2011 (BST)

direction=forward/backward

the proposal says that it doesn't interfere with the values forward/backward. i disagree. most of your values describe the physical orientation of an element, while forward/backward describe an access restriction. throwing those in the same pot by using the same tag is not a good idea. my suggestion, as i mentioned on a couple of other talk pages already, would be to use the access namespace. by using access.direction=forward/both/backward you could describe the access restriction, while direction (without a namespace) would describe the physical orientation of an element. --Flaimo 21:35, 8 September 2011 (BST)

"cardinal directions"

The example "NE" and the compass rose drawing make it clear that intercardinal/ordinal directions, as well as further divisions, are possible values. However, the text only mentions "cardinal directions". As far as I know, this term refers - strictly speaking - only to the 4 main directions. Can we rephrase this (either now or in the final documentation) to e.g. "An sequence of upper-case latin characters from [NWSE], meaning one of the 8 cardinal and intercardinal directions or their 8 direct subdivisions"? --Tordanik 22:15, 8 September 2011 (BST)

Yes, if it would be more correct. I copied those terms from the previous version, but don't really understand the difference between ordinal, cardinal and intercardinal (having not spent time on thoroughly studying the wiki on directions). So I'd be glad for any help clarifying the description — but in the final documentation, since it's not good to change the proposal that's been in voting for several weeks. --Zverik 07:48, 9 September 2011 (BST)

Directions possible when passing a turnstile barrier

I am thinking of turnstiles. E.g., many public parks or pools in Germany have few entrance gates (where you have to pay), but some more turnstiles so people have a shorter way out.

I propose to use "direction=out" on such turnstile barriers.

Gpermant 10:06, 17 February 2012 (UTC)

Wouldn't entrance=exit be appropriate for that situation? --Tordanik 13:02, 17 February 2012 (UTC)

No, because the entrance or exit tag is on a node, and routing does not natively check nodes. And additionally, you would have to define "inside" and "outside". The best way is to tag the way oneway.

--Lulu-Ann 15:03, 17 February 2012 (UTC)

Good routers check nodes (OSM nodes, not routing graph nodes - these shouldn't be the same thing) because they are routinely used in OSM to represent barriers. Tagging the way leading to the turnstile accordingly is a good idea anyway. --Tordanik 20:00, 17 February 2012 (UTC)