Ok. What are we disagreeing about?
destination=Harcourt avoiding low bridge;Elmsford can be argued to be used for replicating the signage depending on destination= definition, and compatibility. Cf the aforementioned destination:via=Something could be used with destination=Somewhere (via Something) if that’s exact the text. Again, it depends how destination= should be used.
On the other hand, obviously destination=Harcourt avoiding low bridge;Elmsford B 481 is not used literally, but destination:ref= / destination:ref:to= =B 481
I do prefer adding a destination:*=avoiding low bridge , however it can be independent of deciding what should be in destination=
Not disagreeing, misunderstanding; it’s precisely to try to make this misunderstanding disappear that I asked you some questions on this message. 
@trial: I’m considering adding some kind of destination:comment=avoiding low bridge for that; the problem with, for instance, destination:via=*, is that it assumes that the comment after the destination is something like Dest. via something, but the comment may be something very different, and language-dependent, whereas destination:comment=* is generic enough to serve all kind of text comments for a destination. Yep, I like the idea of destination:comment=*… 
I won’t consider detour routes for the proposal, I think. On the one hand, I don’t know enough on detour routes, both in France and elsewhere, to make a sound proposal on this subject; on the other hand, I prefer to not make a too long, too complex proposal. It will likely be already long and complex enough without trying to manage detour routes; better is the enemy of good.
Besides, the signage of detour routes in France is rather chaotic: there are Bis routes, Sn routes… and the Sn routes SU1 symbol may be anywhere on destination signs: on the same register as exit numbers, with destination refs, with destination items, separated from destination items, at the top of the sign, at the bottom, on a separate signpost… Nope, I’ll not risk blowing the proposal with something so tricky; maybe letter, but not yet.
@Kovoschiz Did I it get it right this time?
Besides, you also talked about a destination:via tag; does it already exist, or did you forged it yesterday, for your point? 'cause I feel that a more generic tag like destination:comment would fit better.
It’s documented in user pages destination:via | Keys | OpenStreetMap Taginfo
User:Mueschel/DestinationTagging - OpenStreetMap Wiki
As I said, you can have destination= + destination:via= + destination:comment= together. destination:comment= can be for the sign. destination:via= is more convenient for application to use when they need to transform it, especially for instructions. It contrasts destination:street= / destination:street:to= , so actually it may be discussed to split into destination:street:via= roads, and destination:via= locations.
Furthermore, Commonwealth has another special sign Follow Something For Somewhere, which may be discussed for using destination*:via= and destination= somehow Direction signs on all-purpose roads - GOV.UK
Here avoiding low bridge is the opposite of via ;-).
@Penegal not sure detour routes are easier to map in UK with 
!
1 Like
I don’t feel I can endorse destination:via=* in the proposal:
- the proposal is about destination tagged on highways, not about
destination_signrelations; according to TagInfo,destination:via=*is almost only used on relations, which are out of the scope of the proposal; maybe will the people use the proposed tags, if approved, ondestination:sign=*, but I don’t intend them so; destination:via=*is almost only used in Italy, and is almost undocumented (I don’t believe that a two-liner on @Mueschel personal wiki pages is a correct documentation, despite his personal experience on this matter);- I also consider suspect that, according to TagInfo,
destination:viaknew a sudden surge of use in 2017, and was, before as after that, virtually in disarray; - via can mean by passing through, but it also the italian word for street, path, way, and thus seems way to polysemous to me: it could very well have a very different meaning than the one looked for here;
- as said, destination comments can be anything, without necessarily meaning by passing through; in your example, avoiding low bridge is hardly an answer to the question by passing through what?. Using
destination:viaas the tag for such mentions would be misleading; key names should be self-descriptive, and I can’t say it’s the case here without distorting the truth at least a bit.
All in all, that’s too many uncentainties for a tag that I could propose, particularly when it’s not the core of the proposal: that would risk getting a negative vote for a minor point. The proposal will already be tricky enough without looking for trouble on a minor point.
And, err… I’m sorry to insist, but you didn’t answer me:
Sorry to ask one more time, but this looks important.
What? I mentioned destination:via= as a case study of how to use destination= , not about using it here. Both of you misunderstood it.
1 Like
In such tag “table” logic, the usual separator is | instead of ; which could be kept to provide a country sign reference as well as a corresponding generic meaning like:
destination:symbol=motorway;hazmat:water;FR:SI11|motorway;hazmat:water;FR:SI11||
Isn’t the job of an OSM based satnav to work that out?
Feel free to make a proposal for those detour routes, but it’s not the subject of this poll. We already map those routes, not the symbol they’re using I think (I’m not mapping in UK).
destination:symbol=detour_route is given only for France, and only for FR:SU2 
.
But that’s also the whole subject of this poll:
- should we map the intention (here mentioning a detour) in OSM terms or
- should we map the actual sign (here FR:SU2).
For the first, that’s enough. For the second we would need 9 keys for UK. They don’t seem to have a code but a description, Off-Network Tactical Diversion Route - Wikipedia.
1 Like
Unless that, in highway-related feaures, | is a separator for different lanes, and destinations are also often tagged per lane, i.e. using |.
Besides, your example uses both human-readable values (hazmat:water) and sign IDs (FR:SI11), which is basically duplicating data.
I prefer using traffic IDs to tag traffic signs because they are country specific.
In Germany meanings access:hgv=no ist different from access:hgv=no in France. Same to related traffic signs. There are other examples as well. Also design of traffic signs may have major differences, especially for destination signs in EU countries. But keep the US or Australia signs in mind which are very different from EU states. See Wikipedia for further information.
Using words as traffic sign description is just a first acceptable step which should be replaced by country specific IDs as soon as applicable. However, those descriptions will appear in applied traffic rules anyway such as slippery way as an example:
Legal rule for way: hazard=slippery
Design description for traffic sign node: traffic_sign=DE:114
By using traffic sign IDs there is a fixed reference to legal, country specific documentation. I found that this is major advantage.
Additionally, legal rules applied to ways, junctions etc. should be strictly separated from traffic sign descriptions. A traffic is no rule but sets a rule into force. It is not required that a rule requires a traffic sign to be applied. For this a hard preference of traffic sign IDs over description by words might be helpful.
Agreed, (hazmat:water) is a rule applied to a way as (FR:SI11) is a description of a traffic sign applied to a node.
Keep in mind that there are some destination symbols in the field currently with no applicable traffic sign IDs, such as museum, airport. Additionally, symbols of same meaning and naming do have different designs. The user needs to be free to choose a traffic sign ID to be very specific on the traffic sign design, or a description by words where a traffic sign ID is not applicable.
Graphic elements used on arrow shaped destination signs should be handled same way, either if they are traffic signs or general symbols. They all share the same place and size on a destination arrow sign.
This is different from destination signs which shows lanes or presented as tables with an destination arrow inside a destination box. On this signs general destination symbols like industry area share the place with destination names, as restrictive traffic signs will be found inline of the destination arrow shaft.
Frankly I am not convinced that this is important. If I find a maxspeed sign in Italy, I can be pretty sure it is an Italian one and not a German one (I admit I recall one curious case, where a German sign was found in France, a stonethrow away from the border, but these handfull of curiosities are IMHO not a good enough reason to force incomprehensible codes for millions of objects that can be described just fine with a natural word). On top of that, if I were a traffic sign nerd, I would expect the scheme to cover more properties, e.g. there is no current suggestion how to deal with the size (the same sign can come in different sizes).
1 Like
Wrong, at least in France: we have destination symbols for that.
Then the code managing their display would have to wonder about the country where you are… as it would if it was a sign ID, and as it should if it tries to render the sign, as fonts, colours, layout… change with the country.
Besides, what if the symbol is an unofficial one, i.e. without ID? Or has a non-standard modification? Reality principle: road operators should follow the rules, but they must adapt to reality, because it’s harder to ignore. If a non-standard sign is required, you can bet they will likely use a non-standard one, and rules be damned. One more pro for human-readable: you can adapt the tagging to non-standard signs.
Why should a software developer bother with two ways to map the same thing, when we (the community) can in advance choose only one, even if it has drawbacks?
Regarding traffic sign IDs, yes, the management of these by softwares would be easier, but you can mitigate the drawbacks of human-readable tagging (I already have ideas about this, which I’ll detail in proposal). Besides, IDs have the great drawback that… you must learn the sign IDs, or use a correspondence table sign/ID, or have dedicated software for that. What if the user uses iD or JOSM, who basically treat key-value pairs as text?
The great pro of using human-readable values, particularly with restriction tags which are already widely used, is that they are very intuitive, the users (and software developers and their code, BTW) are already accustomed to it, have habits for it, and follow the principle of least astonishment; traffic sign IDs are more for “traffic sign nerds”. Do you imagine novice users trying to use them? What would be the point of using such IDs, very cryptic for most users? It has advantages for softwares, yes, but are users softwares?
You seem to talk with a German point of view, as German signs are the only ones I saw which were designed so. In France, restriction ideograms are used as plain destination symbols (airport, harbour, museum, historic…), displayed at the same place on the signs (according to what I read in UK documentation, it would be also so there). Besides, just for the record, these ideograms about which I launched this poll are no restriction sign per se: they don’t enforce anything, but warn you that you likely will encounter one further away.
Going through the whole proposal process, letting a new tagging scheme spread… just to change it later and break the tagging habits of everybody? Without me: I won’t be part of it. I’m willing to participate to OSM, but not if it means working for weeks only to trash it later and break the habits of all. Thanks, but no, thanks.
2 Likes
FR:ID2 for airport in France. 
We don’t have symbols for museums, except for major ones, for which we have an ID
FR:ID16d 
and a symbol reference FR:museum_of_france.
For sure, some mappers have dreamt of encoding enough details to be able to reconstruct the actual sign. That’s how some countries wound up with layout and presentational details like destination:lower_panel:upper=* and destination:colour:text:to:lanes:forward=*. But at a certain point, this micromapping is actually at cross purposes with encoding the details necessary for guidance instructions in turn-by-turn navigation, which benefit from semantic tagging even when the semantics aren’t explicit on the sign.
Micromapping traffic signs is first and foremost the purpose of mapping traffic_sign=* nodes. This is how you can document the physical reality. Once we figure out the right syntax for the sign assembly as a whole, then any details that are important enough for navigation can also go in destination tags. It’s an important distinction: very often there are multiple advance destination signs ahead of a junction, all with different layouts and presentation. Besides, there are plenty of destination signs that have layouts we could never shoehorn into tags on roadways, like this word salad in the middle:
destination:colour=* is about a message conveyed through color alone, about color-coded destinations. On the other hand, if a destination sign happens to be a different color for stylistic reasons, it should be encoded as colour=* on the traffic sign node, not destination:colour=* on the roadway.
I can’t comment on how destination:via=* is being used in Italy, but common sense says it should have similar semantics as destination:to=*: to be used when the sign uses that preposition in the local language or the symbolic equivalent.
I’m confused about this point. Does the sign indicate that a hazmat truck is allowed to enter the motorway but they won’t be able to go all the way to Nancy or Lunéville due to an intervening hazmat restriction? If so, any destination tagging about this restriction should probably be explicit about the fact that it’s specific to the terminus rather than the immediate adjoining section of motorway.
The motorway symbol and the hazmat:water symbol both tell you that, if you use this route to Nancy and Lunéville, you will, at any point along the route:
- use a motorway;
- encounter a
hazmat:water=norestriction.
The hazmat:water=no may be on the motorway, maybe not; the sign doesn’t tell you that, only that you will encounter a restriction and a motorway if you use the pointed route to go to Nancy and Lunéville.
Remember what destination signs are: they basically say If you want to reach this destination, the recommended route is this way… but they don’t tell you that this route is mandatory nor the only one existing. In this example, you could turn right, then later choose a totally different route which bypasses the motorway or the hazmat:water=no restriction, and still reach Nancy or Lunéville.
Basically, the example destination sign tells you:
- if you want to reach Nancy or Lunéville, you are advised to drive this way;
- if you choose to use the advised route to reach Nancy or Lunéville, you are advised that you will arrive on a motorway, and that you will encounter a
hazmat:water=norestriction; if this is a problem for you, you should choose another route, whether by not turning right now, or by turning right and later choose another route; - if you want to reach Blâmont or Sarrebourg, you are advised to turn right; if so, no motorway nor
hazmat:water=norestriction is expected.
Oh, I would certainly never try to push destination tagging so far. IMO, as long as it is reasonably usable by mappers, and allows to render a destination sign close enough of reality, it’s good, else it’s simply overkill/unrealistic. Your examples perfectly demonstrate that point.
Well, I wouldn’t say that this limit is crossed here: would I try to map the style of the arrows or the font of the sign, I would agree with you! I mean: destination symbol tagging already exists; all I’m trying to to here is to allow tagging slightly different symbols.