This proposal basically aims to answer this question: how to tag advisory restriction ideograms such as the ones on these signs (for license/attribution, the proposal):
First of all, this is a thorough and well-presented proposal. You’ve clearly thought through a lot of cases in the last 3½ years. It’s pretty long, but hopefully everyone will be able to follow along.
How soon?
We established in the poll thread that some countries use a “restriction ideogram” as a disclaimer about the destination city on the destination sign. I’m unsure which countries follow this practice. The Vienna Convention appears to be silent on this whole category of directional signs. Most of the examples and explanations come from France, which could be representative of continental Europe and French-influenced countries around the world.
By contrast, in the United Kingdom, if a regulatory or warning sign is embedded in a directional sign, the restriction or warning applies immediately at the junction unless a distance appears underneath. It doesn’t necessarily have anything to do with the named destination. The embedded signs are designed to be difficult to miss, and perhaps also to save space. UK-influenced countries like Ireland, South Africa, and Australia might take a similar approach.
This is also the case in the United States. In the following example, the ramp for Exit 142 is off-limits to hazmats, even though the Cleveland city limit is some 23 miles away (38 km), past several smaller cities, and to get there you have to turn onto two more routes that aren’t listed here:
Since a mapper looking at street-level imagery may not have context about the exact location of the restriction without putting their pencil down and hunting for it, do you think we should try to accommodate both approaches in the same tagging scheme? Fortunately, the proposal has a caveat that destination:hazmat=* and the other subkeys aren’t to be taken so literally:
In the end, destination restriction ideograms should be treated by mappers and data consumers as mere symbols: even if a by-passer would treat them as restriction advance warning or detour route recommendations, they may be used for other meanings and data users must not treat them for anything else than destination sign displays.
In that case, it shouldn’t matter that the symbol is more immediately relevant in one country than in another. I think this holistic approach would be less confusing to mappers and not much of a problem to sign renderers either.
Designated routes
The “Differing operators” section explains at length that the blue pictogram of a hazmat vehicle is ignorable as a mere recommendation due to specific municipal laws and budgetary considerations in France. Are you sure this generalizes globally?
In the U.S., a hazmat route sign (meaning hazmat=designated) can be just as prominent as a hazmat prohibition sign. I would see no reason to keep that information from a truck driver consulting a rendered sign. The following example has hazmat route signs for Exit 108 but no hazmat prohibition sign continuing straight toward Dublin. This is because a hazmat driver may legally continue straight, but taking Exit 108 is how they’d get around a hazmat restriction that they already encountered somewhere else. (In that sense, it’s akin to a detour route, but we can’t map a route relation since it isn’t a well-defined linear feature.)
Text equivalents
The “Destination comments” section addresses a situation that happens very often in North America and apparently also in Europe. Some restrictions or recommendations don’t have well-established symbols, so the sign includes a text legend instead.
Relegating this information to destination:comment=* means a data consumer will be unable to do anything with this information except display it verbatim. This is probably fine if the only intended audience is a photorealistic sign renderer, but I could also imagine a navigation application striving to present the same information in the user’s preferred language. Should we look harder for a more structured, more easily queryable representation?
In the U.S., the text and symbol signs are interchangeable. Sometimes both appear simultaneously for emphasis. Should we choose between destination:hgv=* and destination:comment=* depending on the presentation?
(This is another example of an immediate restriction. A truck can’t enter the parkway even if it wants to exit before the airport.)
Granted, I can see how some text legends may be difficult to shoehorn into a structured representation. We probably do need a freeform destination:comment=* as a last resort.
Heh, I meant something more automated. I’m imagining that drivers in France aren’t required to be fluent in French, since most signs are language-neutral. They might benefit from something displayed – or read aloud – in their native language, even offline without access to a machine translator. We probably can’t structure every possible message, but some like “recommended for HGVs” in Britain might have common enough analogues worldwide to put into a more structured format. We took a similar approach with parking:restriction:reason=* in the street parking scheme.
As I understand the UK law, such signs merely indicate that a restriction will immediately (or further away, if there is a distance plate) occur, but the destination sign does not enforce it. If I’m right, that means that the regulatory sign on the destination sign is a mere advice: please note that, if you turn right to reach Milldale, you will encounter a maxwidth=2.6 restriction immediately after junction.
All OTG examples of such signs I found in the UK had regulatory signs just after the junction, so I assume that my interpretation about the non-prescriptive nature of such regulatory signs on destination signs is correct.
Besides, your example is a pre-warning destination sign, i.e. a sign which is not at the junction, but before, to allow drivers to prepare to turn right at the next junction; the signs at the junction are used for destination tagging, not such advance signs.
Was just a quick answer; I must take some time to analyse the examples you gave for the US. I just woke up; I’m not fully mentally available to give you a sound answer on that point… Seems you’re mentioning very relevant things, though; that at least has reached my brain.
Sure, this is no different than in the U.S., but I think this is an argument in favor of tagging destination:maxwidth=* on the cross street instead of tagging maxwidth=* on the same street as the sign. I think everyone already agrees on that point! In the end, I’m not sure what difference it makes to a sign renderer whether the roundel refers to an immediate restriction or one somewhere down the road. It’s prominent enough to be included on the sign, so we’d tag it alongside any other destination sign contents, regardless of the location it refers to. This would have the benefit of clarifying the purpose of the sign, so that another mapper looking at automated sign detections in Mapillary won’t inadvertently map an actual restriction in the forward direction.
I didn’t get that impression from the DfT manuals that I linked. The guidance seems to apply to both junction and pre-junction signs. But this is fairly unfamiliar territory for me, so I’ll defer to someone with more local knowledge.
As said in last, I will reject destination:*:conditional=, asking for destination:access:*:conditional=
There are condition-based destinations rotating prism signs that I want to properly use destination:conditional=
Strong winds
Connecting closed bridges: destination=Somewhere Across; Somewhere Before + destination:conditional=Somewhere Before @ (wind_speed > * AND height > *) + destination:motorcycle=Somewhere Before @ wind_speed > * )
I don’t see the purpose of square bracket in destination:access:conditional= either. Eg destination=Castres;Albi;Toulouse can be destination:access:conditional=(designated;designated;designated) @ (weightrating > 3.5) if the square bracket means applying to all?
The proposal seems to be entirely focused on the case illustrated in that section. What I’m suggesting is that it should also cover the signs in the UK, U.S., and possibly elsewhere that appear in the same context and look identical to a driver but apply immediately at the same junction as the sign – the opposite of what the section describes. If the proposal does cover that situation, that isn’t clear at all.
About destination restrictions enforced immediately after the junction
Basically, a destination restriction ideogram warn of some restriction which can be at any distance of the junction: it can be immediately (in the UK, it is expected to be so if there is no distance plate) or further away (general case in France: the restriction is rarely enforced immediately), but the important part is that it does not enforce anything, so this does not prevent UK/US/other signs to be mapped, even if the restriction is enforced immediately after the junction.
I may have not made explicit enough that the advised incoming restriction may occur immediately after the junction because:
I wanted so much to differentiate these ideograms with restriction signs themselves, and
being French, I’m not accustomed to have such ideograms when the restriction is placed immediately after the junction: it’s rarely so in France; in most cases, the restriction is further away.
I could explain it so:
It is important to note that such ideograms are not restriction signs by themselves: though the advised restriction may occur immediately after the junction (depending on local customs and regulations), they do not enforce it, they merely advise drivers of the impending restriction if they follow the signed route.
Does that sound good to you? @trial, your opinion?
Stack-type signs
You were actually right, your sign example may be at the junction, as explained in the 4.1.1 of the DfT manual:
Stack‑type signs are intended for use only at simple junctions and should not indicate more than three directions as the sign would then become difficult to read.
Never mind!
About destination comments
The thing is that the subject of destination comments is uncharted territory to me. I know:
comments about differing conditions on two routes to the same destination (by pass, by tunnel);
comments about alternative routes for vehicles forbidden on another (route for goods vehicles)
Are there other types of destination comments in other countries? Maybe, but to be sure, we would need an exhaustive listing of such comments for many countries, then an ordering to see if more comment types appear… Sounds like a rather long work.
Honestly, I think that can be set apart for now: we can refine destination:comment=* later; the proposal is already complex enough to prevent lengthening it again for that point, I assume. If it was a core tag of the proposed scheme, I would probably probe the matter, but I think this point can go through approval as is, for now, even if it is refined later. Oma always said: Better is the enemy of good.
About designated routes
Nope, I’m absolutely not sure, merely assumes it is so elsewhere. This subsection is only there to explain why destination restriction ideograms are no enforcement of the restriction: the restriction may often be circumvented later. That is an example of why this circumvention may be possible, without designing the sign with this possibility in mind.
That being said, this subsection about differing operators may simply be overkill: these ideograms are mere advises and don’t enforce anything, period. Sounds a bit harsh to me, but…
OK, I have trouble understanding these signs; as France is more Vienna convention than MUTCD, these signs could be extraterrestrial to me, when it comes to understand them… But I think you already gave me this examples some years ago, at the beginning of drafting, isn’t it?
If I understand you, you mean that these signs actually mean hazmat vehicles are advised to exit at this junction, whatever their destination, because staying on the motorway will lead them to a restriction forbidding them to continue. Is this correct?
If so, this is not related to destinations, and would not qualify for the proposed tagging scheme, as it is all about adding informations on destinations as they are displayed on the ground, but here, there is no display of any destination, just a to all hazmat drivers: please leave the motorway. Isn’t it?
About the Exit 142 example
Do you mean that the yellow sign is a prewarn for a hazmat=no restriction that all drivers wanting to reach Cleveland using this exit will likely encounter? If so, under the proposed tagging scheme, the ramp would be tagged so:
destination=Cleveland
destination:hazmat=no
Did I get it right? Those MUTCD signs are so confusing for an European…
I don’t understand the point of having always the :access: part. For conditional restrictions whose enforcement would be tagged with a access:conditional=*, OK, I get it, but if a restriction would be enforced with, say, hgv:conditional=*, why would it be a problem to tag the ideogram destination:hgv:conditional=* instead of destination:access:hgv:conditional=*?
I mean, the whole design is aimed at reusing existing access restriction tagging, to keep the overall tagging scheme as user-friendly as possible, and if existing restriction enforcement is tagged with hgv:conditional=*, it goes against this goal to add :access: when it comes to destination signs. I know you already explained it, but I’m sorry, I still miss the advantage of your suggestion or the drawback with mine.
Or does someone get what @Kovoschiz’s point is, and could reword it to me? We already tried to understand us the last time, but failed. @Minh_Nguyen@trial: do you understand what @Kovoschiz is trying to explain me?
About your destination sign tagging example
Could you please give me an example of the sign you want to be able to tag, with your suggested tagging for it? I’m already a bit lost with speaking with several persons at the same time, and not having an example to help me to understand your point makes it only harder to me.
About brackets in conditional syntax for destinations
Basically, conditional restrictions may contain ;, but if you already use ; to distinguish between destinations, how do you tell that a ; separates conditional restrictions for the different destinations, instead of separating different element of a restriction for a single destination? Having the conditional restriction for a destination between brackets removes this possible confusion, as explained here. I admittedly never found a destination restriction ideogram that would necessitate the use of ; to model the ideogram, but if so, what?
Your tagging example is on a rather simple case, but I’m unsure how it would be on a more complicated example; would you mind testing it? Say the following example:
It means often “just” that following the destination sign you will at some point encounter this (for instant one part will use the motorway, or a bridge will be low).
Sometimes, it may mean immediately, then you have to put it in the next road part.
This subsection is only there to explain why destination restriction ideograms are no enforcement of the restriction: the restriction may often be circumvented later.
Keep the proposal short, move long explanations to the discussion page.
we can refine destination:comment=* later;
+1
About designated routes
Move that part elsewhere (in the discussion page?), it makes the proposal harder to read.
Do you mean that the yellow sign is a prewarn
The yellow sign means if you exit here you can’t come back on this road. You missed the strikeout HM, so destination:hazmat=no but for another reason!
@trial: do you understand what @Kovoschiz is trying to explain me?
Nope, don’t feel alone .
Could you please give me an example of the sign you want to be able to tag
In France, this kind of restriction is rather a dynamic message, something like “Pont de l’Iroise fermé à partir de 21 h, Pour Brest, passer par Landerneau”. I was looking for the usal message and in the press I read: Dans un communiqué, la préfecture précise : « Afin de garantir la sécurité des usagers de la route, la vitesse de circulation (sur le pont de l’Iroise) pourrait faire l’objet d’une limitation de vitesse complémentaire, annoncée par panneaux à message variable ».
So the speed on the bridge may be reduced due to weather conditions, and drivers will be informed on dynamic displays.
So in that case, the usual “90” (on bar metal ) will be overriden by “Vent, vitesse limitée à 70 km/h” (an educated guess: Wind, reduced speed: 70 kph).
I’m aware of such “hard written” restrictions in France, but not on destination sign, like “no access to the pier at Beaufort scale 9 or above”.
This is a step in the right direction, but I’d suggest wording it so that it’s less confident about local norms. In a country that puts caveats on destination signs, of course they’ll be reinforced by real prohibitory signs at the actual prohibition locations. On the other hand, in a country that doesn’t treat these as caveats, we have no guarantee of another sign reinforcing the one on the destination sign or diagrammatic sign. Here, the moment a trucker goes in the direction of a No Trucks sign with an arrow, they’ve violated the law, even if that sign hung off a destination sign, so an independent No Trucks sign would be redundant. The only possible exception might be a nonstandard map board for truckers.
I understand your need to emphasize that these caveat signs don’t themselves constitute restrictions. You don’t want people to reject the proposal as redundant to tags like maxheight=* and hazard=* somewhere else. The risk I see is that we end up making rules for signmakers that the signmakers aren’t bound by. If we focus on what seems to be your core concern, then something like this might suffice:
These subkeys of destination:*=* merely indicate that the destination sign board includes a message about a restriction or hazard, wherever that restriction or hazard occurs. They do not replace tags such as maxheight=*, hgv=*, or hazard=*, which should continue to be applied to the affected section of roadway. Depending on local norms, the restriction or hazard may coincide with the junction or it may occur farther away. Only use the destination:*=* subkeys for messages that accompany the destination sign.
Then you could add some examples from countries like the UK or U.S. that aren’t just caveats.
Comments
In the January 2022 street parking proposal, we said parking:condition:reason=* (later parking:restriction:reason=*) would be set to keyword-like values, giving examples such as bus_stop and street_cleaning without attempting to catalogue all the possible values everywhere. We expected that common values would gradually percolate up to the top of the taginfo listing. The advantage is that software will be able to do more with these values than an inscription=*- or strapline=*-like value, but the downside is that they do have to transform them into human-readable values.
I think a similar approach could work for these legends. We could start with destination:for=goods/hgv/through_traffic as examples, then allow the community to any-tag-you-like the rest. However, if you think this would overburden the already long proposal, maybe we can omit the section on comments until we can consider the topic more fully.
Designated routes
It’s more complicated than that. This particular exit is for a beltway (ring road) going around a city. Hazmats are prohibited from traveling through Columbus. The recommended route follows the beltway around the city. However, hazmats are allowed to enter or exit Columbus without traveling through. This makes the whole city a big giant hazmat=destination. Complicating matters, a hazmat driver can continue straight on State Route 161 into Dublin as long as they find some other way back to the beltway before entering Columbus. That’s legal but a waste of time, so the Hazmat Permitted sign is there for their convenience, similar to the blue hazmat pictogram in your proposal.
Exit 142
Sorry for the confusion. I was referring to the prohibition sign hanging off the top of the destination sign. It means no hazmat driver may take the exit. We’d already tag the ramp as hazmat=no, but I’m suggesting that if destination:hazmat=* is a thing, then we could tag destination:hazmat=no here too. It would be redundant but harmless.
(The yellow warning banner is unrelated. It says “No Reentry Eastbound”. The sign informs the driver that they have to pay a toll when exiting the freeway, so they won’t be able to exit and reenter the freeway without paying a toll again. This kind of warning only appears on toll roads. A much more common type of warning banner would say Exit Only, but we already encode that as turn:lanes=* and change:lanes=*.)
There’s no sense in analyzing whether the No Hazmats sign has anything to do with Cleveland. The sign appears in the same location that motorist service signs would appear. We’d have no qualms about tagging Exit 119A below as destination:symbol=airport;hospital, even though Wheeling is hundreds of miles away. Every city has an airport and a hospital. This hospital sign means a hospital is near the exit and is a reason why you might choose the exit. This information is used in navigation systems today, even in the U.S.
access:
I guess it’s because destination:*=* already has so many subkeys about so many different things. @Kovoschiz appears to be suggesting that we avoid proliferating destination:*=* subkeys related to prohibitions by consolidating them into a single destination:access:conditional=*. While there’s something to be said for the elegance of that approach, in practice, it makes it even less likely that any software will ever use such a complicated syntax. And that’s if the value stays under the character limit.
Conditional restrictions
We already have this problem in spades with turn:lanes:conditional=*. Some mappers surround the value in parentheses, while others expect parsers to bind semicolons more strongly than the @ sign. If you can stay under the character limit, it’s better to distribute the condition among each of the values anyways.
I don’t think this proposal should be the one to introduce a change to the conditional restriction tagging scheme. It would come as a surprise to any editor, query, renderer, or router that’s already going through so much trouble to parse the existing conditional restriction format.
It would be less confusing if you have studied the syntax before proposal Conditional restrictions - OpenStreetMap Wiki
Invalid syntax: destination:access:conditional=;;;;[designated @ (height > 3.8)];[designated @ (height > 3.8)]
The logic: attribute1:conditional= must be =result1 @ condition1 , where attribute1 evaluates to result1 for condition1
Counterexample: motor_vehicle:lanes:conditional=no @ (condition1)|yes is wrong, which should be motor_vehicle:lanes:conditional=no|yes @ (condition1)
Correct use: destination:access:conditional=(;;;;designated;designated) @ (height > 3.8)
Interpretation: destination:access is (;;;;designated;designated) for (height > 3.8)
My disagreement and intended use is what I have explained destination:hgv:conditional=designated @ (weightrating > 7.5) : destination:hgv is designated for (weightrating > 7.5)
But destination:hgv= is the per-mode destination for hgv
Therefore it means destination is designated for hgv (that are (weightrating > 7.5) )
That’s wrong. The destination should be Ballaison
This has been documented implicitly Key:destination - OpenStreetMap Wiki
“If a destination is only posted for a certain type of vehicle (hgv or bicycle are common), one could use destination:hgv:…,” User:Mueschel/DestinationTagging - OpenStreetMap Wiki
This is the same as turn:bus= , which means the turn for bus mode , not the bus sub-attribute in turn
As a result, to avoid the per-mode interpretation, the proper syntax should be destination:access:hgv:conditional=designated @ (weightrating > 7.5) , to be parsed as the access:hgv in the destination
These ideograms, placed on destination signs, advise about incoming restrictions on the signed route to the destination. These restrictions are placed sometimes immediately after the junction, sometimes further away.
Sorry but I like crystal-clear sentences…
Could you elaborate? I lost the context of your sentence: which part of the proposal would you like to move to the Talk page?
I’m unsure about the hazard part: at first, I wanted to include hazard signs as in the UK, but there does not seem to be any established hazard=* tagging for many of them, like these:
Including in the proposal parts for hazard signs I don’t tag or know well seemed risky, so I dropped hazard support; that being said, the proposed tagging scheme could be further expanded to add this support later.
I’m OK with the rest of your paragraph, though!
I’m more supportive of the drop-it-for-now. On one hand, this comment part was more for, say, UK mappers, as such comments are used in their country (like route for goods vehicles), where in France we use an ideogram for that. On the other hand, I’m uneasy with expanding this part in the proposal, which is already rather complex stuff, and setting aside comments for later does not seem to make the current proposal, nor the eventual next one, inconsistent. @trial, an opinion about this?
So, you mean basically that, in your example, the first and third lane’s HM signs are basically destination:hazmat=designated, because these lanes are marked as “hazmat-friendly” by the green HM?
Oh, it was about the HM sign? Then yes, this would certainly qualify as destination:hazmat=no!
BTW, do you have other US signs which could be used as examples in the proposal? For instance, destination signs warning about hgv=no or maxheight=*, that sort of stuff?
No offense, but I’m working on this proposal for weeks, and I couldn’t even tell how many webpages I read for it, so yes, I may have missed parts of this page, being in addition no expert in conditional restrictions.
That being said, there is no point being callous; I sincerely try to understand you and not get uselessly angry because I don’t understand people, and I hope that you have the same open-mindedness. We’re all here to improve things by arguments and good will!
OK, I’m getting your point here: so written, there is no need of square brackets. That being said, there may be cases of signs needing several different conditionals. Take for instance this one:
Both ideograms are only about goods vehicles (this truck picto means goods vehicles in France):
the first one tells that this route for Nancy and Lunéville is designated for goods vehicles whose allowed weight is more than 5.5t;
the second one tells that this route for Blâmont and Sarrebourg is designated for goods vehicles longer than 10m.
How would you tag it? Just to be sure I understand you now?
Oh, OK: you mean that writing destination:hgv:conditional means implicitly that the destination is only for HGVs, right? As destination:bicycle, for instance?
OK, understood; that’ll make the key a bit longer, but you’re right here, that could create confusion with existing tagging.
I don’t merge your suggestions in the proposal for now:
I’m too busy following the intertwined conversations to correctly update the proposal for now;
I want to be sure I understand all the details of your suggestions (particularly those of @Kovoschiz) before merging them in the proposal;
I hope that @Minh_Nguyen can provide me some others US signs to discuss
I hope to be able to merge them before the comment rush that could follow the WeeklyOSM announcing this RFC, though!
Edit: I just realized that what @Kovoschiz explained about destination:hgv, destination:hazmat and so on actually means… that these keys should be destination:access:hgv, destination:access:hazmat and so on… Isn’t it?
That’s a very nicely written proposal, clearly explaining all decisions.
I also found the conflict with transportation modes Kovoschiz noted as destination:foot usually is a destination signed for pedestrians (or e.g. cyclists) with more than 5000 uses combined.
Apart from this I think the scheme will work out as planned (although I can’t estimate how long it will take the linked “destination sign renderer” to fully support the scheme )
Yes, exactly. And in principle one could also tag the ramp and any following ways as hgv=designated, but it gets weird because you’d never know quite where the “friendliness” ends based on the signs alone. So destination:hgv=designated is a nice fallback for when we haven’t done that analysis.
Here are some examples of hgv=no messages:
hgv=no and hgv=designated:
A rare difference between a “No Trucks” message on the destination sign and a more nuanced clarification about the ramp:
access=nohov=designated:
maxweight:hgv=7 st:
The U.S. generally posts height restriction signs as warning signs, not regulatory signs, so it’s similar to advisory speed signs. Here’s maxheight=13'6":
maxheight=13'6" and maxheight=13'2":
As in many countries, guide signs are less standardized than other kinds of signs. I tried to find some examples that give a sense for how diverse these signs can be. Feel free to pick the ones that best illustrate your vision for the tagging scheme.
Yeah, now that we discussed it some more, that makes sense to me. It’s pretty similar to how we have to tag destination:lang:fr=* instead of just destination:fr=*. Otherwise, destination:to=* (for Tongan) would conflict with destination:to=* for a “to” destination.
Personally don't like destination:lang:*= though. destination:street:lang:*= can be destination:street:name:*= . destination:lang:*= is basically a destination:inscription:*=?
Fundamentally, the destination:*:to= order can be rectified as destination:to:*= to avoid most problems. destination:to= could be destination:to:place= (aforementioned) / destination:to:name= .
Seems you’re mentioning very relevant things, though; that at least has reached my brain. 
But I think you already gave me this examples some years ago, at the beginning of drafting, isn’t it? 
_-_light_rush_hour_traffic_during_COVID-19_pandemic.jpg){kind=link}