Relations/Proposed/Destination Signs

destination_sign
Status:	Approved (active)
Proposed by:	Cohan
Tagging:	*=*
Applies to:
Definition:	*
Rendered as:	n/a
Draft start:	2008-11-19
RFC start:	2008-12-05
Vote start:	2009-06-21
Vote end:	2009-07-31

Proposal

An example from Sweden. Instead of just saying "Turn left in 200m" a routing software also could say "Follow the sign to Österstad".

This proposal is to allow information about destination signs at crossroads to be entered into OSM.

Rationale

When using a routing software as navigational aid, it is very helpful to be shown the signs to follow. E.g. instead of just saying "Turn left in 200m" a routing software also could say "Follow the sign to Österstad".

Note: The originally intended purpose is rendering on navigators (like this - in the next intersection follow the sign "E4 Malmö") or in turn-by-turn descriptions when following an already made route - in the original intent this is not for aiding the creation of routes.

Tagging

Tags

Colours should default to some (preferably national standard) presets if omitted. This is handled by the routing/map showing software. Since shades of yellow are probably not interesting I don't see a need to specify an RGB-colour. Colours could (should?) be choosed from a set list e.g. black, white, red, blue, green, brown, and yellow.

Members

Way or Node	Role	Recurrence?	Comment
	sign	exactly one	The point where the sign is. This could be an intersection or a point before it. In the example this is [Node B].
	to	exactly one	[Node C/Way W] A (the first) way/node on the way after the junction.
	from	one or many - optional	[Node A/Way Q] A (the last) node/way before coming to the junction. Unnecessary when destination signs are the same from all "non-to" directions. (D-B-C = A-B-C)
	intersection	one - optional	[Node B] The node of the intersection. Required if the sign member is not the intersection node. If no intersection node is present in the relation the sign counts as both.

Example

Lets say I'm approacing the crossing in the photo on the top of this page and the routing software says that I should turn left. It would be an additional aid to know that I want to follow the sign to Österstad. This aid becomes increasingly helpful when following a larger road with many exits or crossing ways.

The relations for the signs in the picture: (Assuming that the signs are not visible from the Åsmestad road.)

<relation id="??">
  <tag k="type" v="destination_sign" />
  <tag k="destination" v="ÖSTERSTAD" />
  <tag k="colour:back" v="blue" />
  <tag k="colour:arrow" v="white" />
  <tag k="colour:text" v="white" />
  <member type="node" ref="B" role="sign" />
  <member type="way" ref="W" role="to" />
  <member type="way" ref="Q" role="from" />
</relation>
 
<relation id="??">
  <tag k="type" v="destination_sign" />
  <tag k="destination" v="Åsmestad" />
  <tag k="colour:back" v="yellow" />
  <tag k="colour:arrow" v="red" />
  <tag k="colour:text" v="black" />
  <member type="node" ref="B" role="sign" />
  <member type="node" ref="D" role="to" />
  <member type="way" ref="Q" role="from" />
</relation>

Questions to be ironed out

• How to do when more than one sign is pointing in the same direction. One relation for each sign (destination) or can this be managed within one relation? Only entering one (the topmost) sign?
  • One relation for each sign.
• Should caps be used if used on sign? In Sweden, as the example photo shows, destinations along major roads are written in caps while destinations along minor roads are not.
• Sometimes an icon is used as destination, especially for airports. How to handle this? Special strings like {AP} and let the routing software show a proper icon instead?
• Signs specifying a destination and a road number, e.g. E4 Umeå. The road number might have different colours than the rest of the sign.
• Signs not specifying a destination, only a road number.
  • Just enter the road number as the destination.

See also

• Proposed_features/Guidepost

Discussion

Discussion on the Talk page

Voting

Type "{{vote|yes/no}} --~~~~" to approve/oppose this proposal and sign with your user name & date.

• I approve this proposal. --Cohan 07:51, 21 June 2009 (UTC)
• I approve this proposal. --Skippern 13:11, 23 June 2009 (UTC) Regardless of minor adjustments in the proposal --Skippern 03:42, 19 July 2009 (UTC)

• I oppose this proposal. To match the usual OSM tag syntax, type=destinationSign should be replaced with type=destination_sign (compare man_made, place_of_worship and other existing tags). I do not oppose the idea itself. --Tordanik 13:00, 17 July 2009 (UTC) Issue has been addressed --Tordanik 11:19, 19 July 2009 (UTC)
• I don't like this proposal. Same reason as Tordanik. -- Pieren 13:27, 17 July 2009 (UTC)
• I oppose this proposal. 1. CamelCase normally not used. 2. key:destination should be key:label. The label and the destination can be different. 3. A member as role:destination should point to the destination. 4. I prefer type=sign instead of type=destination_sign. If a role:destination role is given, it's automatically a destination sign. --ck3d 16:41, 17 July 2009 (UTC)

I have to agree with you in your reasoning. Shame it didn't come up during RFC. A little too big change to make during ongoing voting. I'll make a note of it on the discussion though. --Cohan 16:57, 18 July 2009 (UTC)

• I oppose this proposal. I follow the line of argumentation from ck3d. One should emphasize that for the purpose of

of a routing aid the destination should point to a physical location (role:destination). The information held in the relations should not be restricted to "rendering only". Moreover I don't the like the color tags. This is not useful for good rendering. --Mkowa 22:06, 21 July 2009 (UTC)

• i liked ck3d's idea. make the doing easier and still it could make routing much more intuitive (e.g. also for motorway_junction)--Cbm 18:40, 17 July 2009 (UTC)
• I don't like this proposal. Agree with Tordanik. Gustavf 19:59, 17 July 2009 (UTC)
• I oppose this proposal. Nice thought, but not very realistic to ever be finished to the level that it useful for routing janrikard 17:14 18 July 2009 UTC

Are you talking about using the relation for finding routes or following an already made route? --Cohan 08:32, 22 July 2009 (UTC)

• I oppose this proposal. Good in theory, impossible in practice. Also, this routing guidance can probably be accomplished by guiding people towards the closest place=. /Grillo 15:31, 18 July 2009 (UTC)

Are you talking about using the relation for finding routes or following an already made route? --Cohan 08:32, 22 July 2009 (UTC)

• I approve this proposal. Good idea! Great for future navigation aids. And very easy to gather the data too. AxelM 17:29 18 July 2009 UTC
• I approve this proposal. The color isn't a good thing I believe that they actually have a meaning e.g. yellow private property, blue bigger place, white local place, or something like that. Also adding a "distance" key would be nice because you haven't always (never in my case) mapped the destination.Erik Johansson 06:45, 20 July 2009 (UTC)
• I approve this proposal. But I'd prefer key:label to key:destination also colors should be hexa coded and an official list of colors for each country decided so that we don't end up with a unique color for each and every sign. At least define an explicit list of named colors with hexa equivalent and also accept hexa colors. pov 13:10, 20 July 2009 (UTC)

Grrrr, please don't map colors!. Map the function that the sign has Erik Johansson 07:28, 21 July 2009 (UTC)

Note: Syntax changed from type=destinationSign to type=destination_sign. Please update your votes accordingly.

• I approve this proposal. I approve as long as color stays optional. --MarcusWolschon 09:53, 21 July 2009 (UTC)
• I approve this proposal. --Leojth 21:52, 21 July 2009 (UTC)
• I approve this proposal. Nice idea. --Nighto 17:00, 26 July 2009 (UTC)
• I oppose this proposal. -- I my opinion one relation per direction is not a good idea. There will be too much relations und too much redundancy of the data. One relation per roadcrossing may be a better idea. Adjuva 20:58, 30 July 2009 (UTC)

Results

I count 15 votes and 1 opinion that doesn't clearly vote in any direction. Of the 15 votes 8 are approvals and 3 opposes only because the name was destinationSign and not destination_sign. Since that is now corrected I count them as approvals as well which gives a total 11 approvals out of 15 votes.