Talk:Relation:destination sign

Vehicle-Types for signs

Hej,

I think it would be helpfull to have a tag that describes, what tape of vehicles the sign is meant for. E.g. in the area I live, there is a huge cycle-network with many signs. A routing-software for cars should not use this sign. A driver in a car would not be able to read them (And i think, he would not even try to). Snoopy88 09:12, 29 March 2010 (UTC)

I support this for the same reason. --Imagic 12:44, 18 January 2012 (UTC)

You could use the access-keys e.g hiking=yes, bicycle=yes, mtb=yes, horse=yes or ski=yes to limit the applicability of a destination sign. --aleene (talk) 12:56, 3 August 2016 (UTC)

Agreed, but personally I'd use bicycle=designated for bicycle specific destination signs, bicycle=yes just means the sign applies to bicycles but doesn't exclude motor vehicles, whereas bicycle=designated makes a stronger assertion and you could assume to only apply to bicycles unless otherwise stated. --Aharvey (talk) 01:18, 27 April 2020 (UTC)

a relation for each direction

hello,

I'm wondering if it is meant to create a relation for each direction. In my case I map guideposts which are regularly have more than one destination. Therefore a huge guidepost requires ten ore more relations. Furthermore the role from is not really applicable 'cause the post stands not in front of a road. This problem also occurs if there is more than one destination printed in one direction. What is the resolution for routing software that couldn't decide which destination_sign relation it has to choose?

I create a destination sign relation for each destination on a guidepost, which can be a lot of work. I am not clear about the from-relation either. I wonder if it could be sed in cases where all the signs are not visible on the from-road. With the from-relation you might specify, which destination_sign=* should be used. --aleene (talk) 13:01, 3 August 2016 (UTC)

I would also like clarity around this. One relation per physical sign (could be one relation per destination depending on implementation) on a signpost is cumbersome but probably results in the most usable data. Would be great to have the main page updated to reflect common usage. In Ireland, we have a lot of signposts like this:

Dónal (talk) 14:54, 17 July 2020 (UTC)

destination itself

Let's add a member with "destination" role, that points to the destination place. That allows to find easy not only a turn to road, but also a destination.

I often map guideposts which point to more than one route to the same destination (example: "summer path" and "winter path"), each route having a different time and distance. Is it correct to add ruote information to the text of the member with role "destination"? --Kaitu 21:17, 9 January 2012 (UTC)

Colour schemes/Type of sign

It would be great to add a tag for often used colour schemes, like motorways or rural roads. Every country use fixed schemes for their signs so it is dispensable to define every colour again and again. The routing software has to save a predefined set of country specific schemes and apply it, when a suitable tag is found.

Maybe we can introduce a tag like scheme=*. The value should be a combined string of 2 letter country code, e.g. DE for Germany, and the type of highway or a common description. So the tag scheme=DE_motorway (German motorway) implicit blue background, white text and white arrows for this relation.

Proposal for german signs:

scheme	Background	Text	Arrow	Comment
DE_motorway	blue	white	white	German motorway / Autobahn
DE_rural	yellow	black	black	All roads, except motorways
DE_local	white	black	black	Local destinations whitin cities oder villages (mostly stadium, airport, ...)
DE_historic	brown	white	white	Historic sites (often also sightseeing attractions)

--Will.i.am 12:58, 3 November 2010 (UTC)

I think the choice of tags colour:back, colour:text and colour:arrow are not ideal. It feels like the wrong type of information. It is not the colour that matters but the type of sign. E.g. a destination sign using a Motorway, primary road, cycleway, walkway, or what ever else the different colours are proxies for. -- Amm 12:44, 02 March 2010 (UTC)

In my opinion we need both information: the colors AND the type of sign. Why? Because if we only have the sign, the renderer needs the information how to display this sign for an endless number of different signs (unrealistic). And if we only have the colors and this colors change for a specific sign, all the relations have to be updated manually. If we instead know that these are specific signs, those color-updates can be automated. --Imagic 12:57, 18 January 2012 (UTC)

The Sign itself

Should the sign itself be tagged with tourism=information and information=guidepost? --Ceyockey 17:19, 28 December 2011 (UTC)

Is there any more guidance on this? My understanding right now is that information=guidepost should be used for the actual vertical post and Relation:destination_sign for the destinations on the signs. Is that accurate? Dónal (talk) 14:53, 17 July 2020 (UTC)

ref

I see that in some places destination_sign relations have been created that use the key "destination_ref". In my opinion, the applicable key should be just "ref". (Another option would be to use "destination:ref", but we can shorten that to "ref" because the destination_sign relation is already a destination object.) --Biff (talk) 12:04, 14 December 2013 (UTC)

I vote for using "destination:ref" instead of "ref". "ref" gives the reference number of a street and not the destination information. Using "ref" means that it's meaning is context sensitive which makes it more complicated for software (and pepole too). So it seems easier and more clear to use "destination:ref". --WanMil (talk) 13:42, 14 December 2013 (UTC)

Hi WanMil, thanks for your comment. When following your opinion, "ref" would be reserved e.g. for some kind of reference number for the sign itself. I know places where even trees have official numbers, so it's quite probable that somebody also numbers signs, maybe on the back or on the pole. So, this probably makes sense.

However, do you think that the tags "distance" and "time" have been chosen correctly? After all, these are not properties of a sign object but rather properties of a destination object ("destination:distance" = distance to destination, and "destination:time" = time to destination). --Biff (talk) 01:10, 15 December 2013 (UTC)

No. "ref" is for the object per se. "ref" for the destination_sign relation will describe the number of the road sign itself, not the number of the destination point.--Surly (talk) 10:43, 15 December 2013 (UTC)

We have now destination:ref=* for this. I would clarify the page with "ref is the sign ref".--Jojo4u (talk) 10:11, 28 January 2015 (UTC)

I've just removed discussion of 'ref' on the page to remove ambiguity, and added the destination:ref line item as a suggested tag. This has brought to light another problem, however: how 'destination=*' key tagging, and destination_sign relations tag symbols on signs is completely different. On destination=* key tagging, we encourage a user to use the destination details keys, that use destination:symbol=* tags. On destination_sign relations (this page), they're told to just use amenity=*, aeroway=*, etc. tags directly on the relation.

If we're going to use destination:ref on both types (which absolutely makes sense), should we also use destination:symbol=* tags on both, for consistency? Skybunny (talk) 08:57, 26 January 2016 (UTC)

Will it ever work according to the instruction?

I am wondering about if the relation would work as intended if a navigation software developer is following the instruction in the last part of the page. It states that the software should look for routes that are passing through first the sign node and then the intersection node, and then show the destination value. But let's say for example that the intersection node is a motorway exit; then the route would pass the intersection node regardless of whether it takes the exit or stays on the motorway. Subsequently, it would be impossible for the software to know which sign that should be shown. Would it not be necessary for the route to pass the sign node and the to way/node?Cmbengtsson (talk) 19:45, 7 November 2014 (UTC)

That sounds right that it has to check for the to member. I updated the page. --Cohan (talk) 21:13, 30 July 2016 (UTC)

'via' as a valid role member

Taginfo has shown that the 'via' role is fairly widespread on ways (but not nodes) for this relation type. Using this makes a certain amount of sense, in instances where a way rather than a node is used to express the member between a from and a to member. The 'via' role is already used in turn restriction relations for this exact reason, and is probably why we see hundreds of uses of it appearing organically in destination_sign relations.

This brings up two questions:

1. Should via be a valid member relation type? My vote would be 'yes', for circumstances in which a way is the best choice between a destination_sign 'from' and 'to' member.

2. If (1) is yes, should we in the long term consider 'via' to be the only valid member, deprecating 'intersection'? Done in this manner, whether a node or a way, a 'via' role still universally applies to both. It would leave the valid members as 'from' 'to' 'via' 'sign'. It also would make future editing of these relations by software easier to code.

Skybunny (talk) 20:33, 3 February 2016 (UTC)

+1 `via` should be supported. I think `via` and `intersection` should be interchangeable and can be used on either a node or way. Aharvey (talk) 22:56, 6 November 2019 (UTC)

@Skybunny and Aharvey: I also disagree with the statement on this page that via nodes are nonsensical. If they're nonsensical on nodes, why did the type=destination_sign tagging scheme adopt the same from/ via/ to scheme as other relation types that do expect via on nodes? For one thing, this limitation breaks editors that try to keep these kinds of relations tidy. [1] – Minh Nguyễn ^💬 22:34, 28 June 2022 (UTC)

Mid-road destination signs

What's the right way to map signs like this? They have the all of the roads's signed destinations and the distances to them, and are usually posted after major intersections or leaving towns, and generally feature more destinations than those posted in advance of an intersection. What's the proper way to map these? Just put a pseudo-intersection at the location of the sign and map the relation(s) as anywhere else, or is there another trick to it?

Additionally, this article talks about whether to use destination tags on ways, or this relation, but is it possible to use both, or does that break things?

-- Roadsguy ^(talk)

I create a "information:guidepost", which I place on a node of the way. I add the "direction" keyword to indicate, from which direction of the road the sign is visible. Then I can add the destination signs to the guidepost. Indeed I need to create a pseudo-intersection on the node of the guidepost, to indicate that the node must also be viewed as the intersection. And the road must be cut on the node as well, in order to have a before and after the guidepost road-section. On the after section I can then add the destination sign as a relation with the 'to' markup.

So the way has a relation to the destination sign. I do not add the destination on the way itself. That messes the way tags to much up, especially when there are a lot of desination signs for a way.

--aleene (talk) 09:23, 22 November 2016 (UTC)

Multiple distance and time values in one relation

There should be the ability to add multiple destination=* values and associated distance=* and time=* values. It is very possible that one sign shows multiple destinations in one direction with different distances. It's unnecessary and excessive to have to add multiple relations with the same members but different tags. I think you should be able to tag destination=A;B, distance=5;10 where destination A is 5 km away and destination B is 10.

• This is exactly how I interpret all tags of these relations, distance, time, symbols... and it seems to work well. There might be cases where it is not sufficient, but you are still free to use separate relations if it is needed. Mueschel (talk) 22:21, 12 April 2018 (UTC)

• I brought it up because the wiki page specifically advises agains this method in the Tags section saying: "If supplementary information must be provided, like distance or time, one destination_sign relation per destination should be created" Zlavergne (talk) 22:42, 12 April 2018 (UTC)

• I created two relations, one for each destination, but JOSM gives a warning about multiple relations with identical members. T99 (talk) 17:56, 13 October 2018 (UTC) Next I put multiple destinations in the same relation. This time JOSM complained about an unusual measure. Go figure. T99 (talk) 07:55, 14 October 2018 (UTC)
  • These are just generic warnings - neither an error, nor specific to destination sign relations. Identical relations are in almost all cases an error, for example if somebody enters the same thing twice. Likewise there are very few cases where too distance value on the same object make sense. These special cases are not yet handled by the validator, but can be ignored in this context. --Mueschel (talk) 08:33, 14 October 2018 (UTC)

Gaps in the relation

From the members table, a "to" role can be "A way/node (typically but not necessarily the first one) on the way after the junction." There is similar language for the "from" role.

This sounds like I can have a way before a roundabout as the "from" way and then a way after the roundabout as the "to" way, and not have the roundabout in the relation at all.

Is this correct, or am I not understanding the text properly?

This sounds right - the ways that form the junction are neither 'from' nor 'to'. You can (and for completness should) add the roundabout in the 'intersection' role --Mueschel (talk) 18:48, 19 June 2019 (UTC)

The wiki page indicates that only nodes should be intersections. It does not currently allow for ways (such as roundabouts) in the intersection role. Should the page be updated to allow for ways as the intersection role when it has a junction tag? --Vorpalblade77-kaart (talk) 19:45, 19 June 2019 (UTC)

Roundabouts

This needs to be addressed on the main page. Looks like the role via maybe used? However there are a number of possible 'from' roles. It would be better if the roundabout could use the 'from' role. A the moment the tag is not really usable where roundabouts occur! The propsal did not consider runabouts at all. Warin61 (talk) 22:32, 29 March 2020 (UTC)

Amenity tags

In this changeset, the idea was introduced to add "amenity" keys to signs that point towards the particular amenity, as in type=destination_sign + amenity=hospital. This idea was discussed critically on the tagging list in Oct 2019.--Polarbear w (talk) 18:28, 28 October 2019 (UTC)

destination:symbol=hospital is better than amenity=hospital Mateusz Konieczny (talk) 08:53, 14 October 2020 (UTC)

https://overpass-turbo.eu/s/Z0X can detect some of that unwanted tagging Mateusz Konieczny (talk) 09:38, 14 October 2020 (UTC)

Destination:lang tags on destination sign relations

I've noticed that in countries where more than one language is spoken some countries will add both languages to destination signs. I know the "destination:lang" tag can be used on oneway roads in conjunction with the "destination=*" tag which is in the countries primary language.

I'm wondering if the "destination:lang" tag could also be used as an additional tag on destination sign relations to add another level of detail? For example, this destination sign in Qatar has both Arabic and English destinations on it. My thought is the destination tag would be the Arabic form since that's the primary language and the English version of the destinations could be added as a destination:lang:en tag to the destination sign relation. Here is an example of how it would be used. Baconcrisp

for me, this use of destination:lang:XX is perfectly fine. I also used it in several places already. What is in the "destination" tag should follow local rules. Some communities agreed to have both languages in the main tag (and the two or more destinaton:lang:XX in addition). --Mueschel (talk) 23:33, 3 February 2022 (UTC)

That's what I was thinking. Thank you for clarifying and for the additional info! Baconcrisp

Specifying the parking capacity

One thing I've seen from time to a time is a guidepost which direct you to a parking place. Notably, they also give you how many parking spaces there exist. I've been using parking:capacity (e.g. osm:relation/18318387 because that represents IMO the best (since raw capacity is too ambiguous) but I'm also wondering if anyone is fine with this. I'm actually wondering if this could be combined with regular destination=* tagging in which case it'd be more like destination:parking:capacity, though. --ManuelB701 (talk) 16:38, 27 November 2024 (UTC)