Vehicle-Types for signs
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)
a relation for each direction
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 destinatio_sign should be used. --aleene (talk) 13:01, 3 August 2016 (UTC)
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:
|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
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.