I can think of at least one roadway where chains are banned: the Arlberg (road) Tunnel (e.g., 8959621489596214. As it is nearly 13 km long driving through with chains would impede trafiic flows & likely damage the tarmac. In very snowy conditions access to the tunnel is limited because of ventilation issues if the exit roads are congested – also likely as drivers put on & take off chains. However, this may not be explicitly signed as driving on snow or ice free roads with chains is not allowed. SK53 (talk) 19:55, 10 November 2021 (UTC)Reply
Snow chains are often banned in long tunnels. There are some banning metallic chains, allowing only non-metallic chains. This reduces accidents from chain breaking inside, and avoids the low speed. Not sure how to put material=* here, except *:conditional=* @ (material=metal) ---- Kovposch (talk) 08:12, 11 November 2021 (UTC)Reply
I've talked to the road operator for Arlbergtunnel, ASFINAG. They show a sign at the tunnel entrance that snow chains are not allowed, to prevent slow vehicles in the tunnel first, and second to prevent damage. Actually it's not a separate local rule, but result of national legislation and practice. The signage could be a text. Text is common in some areas like in the USA, reason enough to keep prohibted. --Trapicki (talk) 18:47, 12 November 2021 (UTC)Reply
Not sure I've seen either of these in regular use in Europe, grousers, in particular, look to be devices to damage road surfaces. Most drivers in alpine areas will fit winter tyres around now, which will be fine for the vast majority of road conditions encountered, although a sudden drop in temperature caused chaos in Zurich about 20 years ago because it hit before people are changed over. Much of the time most roads will be clear of snow: slush is often a bigger issue, especially on motorways. Metal chains are what I've seen in use, although I did once see a Belgian car with plastic fittings struggling up the same hill for a week in a ski resort. Studded tyres will, I presume, be standard in Scandinavia, but I think regulation in the Alpine region (speed restrictions etc) pretty much restricts their use to people with particular applications. [This https://www.continental-tyres.co.uk/truck/knowhow/european-winter-regulations] seems a useful overview of current regulations. SK53 (talk) 14:32, 11 November 2021 (UTC)Reply
Studed tires became uncommon in Austria, but are legally allowed (funnily called "tyres with spikes"). I could not find any road signage legislation or usage. If there are such in other parts of the world, and significant demand, I will consider adding them to the proposal. --Trapicki (talk) 23:43, 11 November 2021 (UTC)Reply
In the U.S., signs ban lugs/studs/grousers/cleats. However, I've never seen a sign allowing or requiring them. It may be just a reminder about state law prohibiting lugs on all roads. – Minh Nguyễn💬03:18, 12 November 2021 (UTC)Reply
Actually, I take that back: Alaska has signs prohibiting, sometimes prohibiting, or requiring studs. I assume studded tires are only allowed on unpaved or graded roads. Even some of Alaska's major highway routes are unpaved. – Minh Nguyễn💬06:03, 12 November 2021 (UTC)Reply
Is there a strong need for other types of winter equipment like tires with lugs/studs/grousers/cleats? I do not want to add this to the proposal if we suffice with the current state (Version 3) for the time being. Still, being able to add that later maybe needs a bit of clever thinking now to not make things complicated later. What needs to be observed for that? --Trapicki (talk) 21:14, 16 November 2021 (UTC)Reply
As with the winter_tires conditional variable you've added to the proposal, it should be possible to cover some of the exceptional signs about lugs and studs using additional conditional variables that don't have to be proposed yet. But unfortunately, we've already turned up standard signs that are mainly about studs or winter tires and only secondarily about snow chains. If we use separate keys for those requirements, with snow_chains as a conditional variable, then these details don't have to be part of the initial proposal either. But then the proposal should probably be clear that it doesn't address every snow chain–related restriction out there. – Minh Nguyễn💬08:47, 17 November 2021 (UTC)Reply
Value
Latest comment: 3 years ago12 comments3 people in discussion
For equipment and accessory use, which are not vehicle modes, using the set of restrictions from headlight=* may be favorable.
Added in Version 3. --21:14, 16 November 2021 (UTC)
I'm pondering about value for "whatever is the default legal situation". snow_chains:conditional=* should have a default restriction if it does not apply according to Conditional_restrictions#Default_restrictions, and taginfo shows that this is actually for maxspeed established practice (55 201/56 977).The default depends on the area, but also situation, for example trucks may have implicit requirement for snow chains, where *=allowed would misslead. Encoding the full legal background is not sensible and needs local knowledge, let's not got down that road. I think of *=default. Comments? --Trapicki (talk) 13:39, 14 November 2021 (UTC)Reply
Added in Version 3. --21:14, 16 November 2021 (UTC)
@Trapicki: Is this in response to #Value and #Carrying required? I guess it's enough. It feels odd to have "carried" be a level of permissiveness alongside "recommended" and "required". Is the assumption that carrying chains is only ever required, as opposed to recommended? That seems to be the case in the U.S. as far as I can tell. For example, in California, means vehicles with snow tires are still required to carry chains, but that happens to be a uniform requirement under state law, unlike some of the other states' signs about carrying. [3] – Minh Nguyễn💬07:13, 9 December 2021 (UTC)Reply
@Trapicki: I was doubting the carrying value, not the recommended value. Both are on signs and useful information, but it seems like the assumption is that signs only ever say "Carrying Required", not "Carrying Recommended". Is that a correct assumption? If not, something more specific like carrying_required might be necessary. – Minh Nguyễn💬06:09, 11 December 2021 (UTC)Reply
Agreed, that would match the terminology in maxspeed:variable=*. Apparently some roads in Nevada indicate an active snow chain requirement by activating flashing lights instead of unfolding a sign, but I don't know if we need to make that distinction here. – Minh Nguyễn💬09:05, 11 November 2021 (UTC)Reply
In this logic, one would have to tag snow_chains=none + snow_chains:variable=weather. Contrary to maxspeed=*, snow_chains=* may be shown not just in that very weather situation, but in a certain time of year (for months) or if weather forecast expects heavy snowfall. In most cases it's not remote controlled signs, but manually actuated, allowing the signs to not show in summer, or when road operators are out to remove snow anyway. --Trapicki (talk) 18:59, 12 November 2021 (UTC)Reply
@Mueschel: I think the issue here is avoiding a term which has a different meaning elsewhere in OSM ("principle of least surprise"), but particularly one which is used on highway objects. I practice this is neither the weather or variable, it is when it is signed (i.e., the sign is activated): no doubt sometimes the signs are not removed after the snow has gone. SK53 (talk) 17:08, 13 November 2021 (UTC)Reply
Chain area
Latest comment: 3 years ago44 comments5 people in discussion
I know only one place that is a "chain-down area", oposite to a "chain-up area". I do not see any gain in distinguishing them. Will add note in proposal.--Trapicki (talk) 22:52, 11 November 2021 (UTC)Reply
@Kovposch: If you find enough examples, explain why it's important to distinguish them and use/render them, and provide a tagging proposal that folds in with the current proposal, I will add it. --Trapicki (talk) 19:28, 12 November 2021 (UTC)Reply
@Skyper:@Kovposch: This would make much sense, thanks for the ideas. Let's keep it unabiguous with highway=chain_change_area, highway=chain_area may be misinterpreted (prison? harbor? super market chain?). I do not want to get too detailed with subkeys, so maybe define additionally an optinal chain_change_area=chain_up/chain_down. I think purpose and restriction should not be mixed here: A chain-change area may be built for that special purpose, still be used to take a break, or reserved for that special purpose with a parking restriction, but that restriction would have to be tagged separately. I think we can keep the the wording "chain-up area", it seems to be the usual US and Australian term - any British examples? never the less I'll mention "chain change area". The naming instrutions need to be changed as well. --Trapicki (talk) 22:37, 23 December 2021 (UTC)Reply
Sorry, I am neither a native speaker and I am even not sure if it is chain "off" or "down". @tagging or the forum might be places to ask for the proper British words and an unambiguous term. --Skyper(talk)
I do not find any indication, for which kind of objects the tags are suggested. I guess, only open ways with highway=* are valid for snow_chains=* but how about the areas? Additionally, I wonder how I should map a bay for changing. Fine, I could use a node, but I rather like to have a key similar to bus_bay=* which I could add to a segment of the road. --Skyper(talk)14:26, 23 November 2021 (UTC)Reply
Regarding a) and b), my considerations where: - Keep it simple, only one key/value. Complicated tagging rules get ignored or missinterpreted; - It's not an amenity for me, rather operational road infrastructure (think highway=emergency_bay, highway=escape); - Only used on certain conditions, otherwise may be used as: rest area, shoulder, driving lane etc. - Allow different forms: I) dedicated area, with a dedicated lane to stop the vehicle and chain up, a road to allow vehicles to pass other vehicles, and a physical barrier or marked not-to-drive-on area (not line!) next to the main road. ; II) a section of shoulder that is marked as chain-up area; III) (just found recently) a section where the first lane can be blocked off to act as chain-up area (maybe not so common, but legal and practice on some motorways in Austria). What about something like or similar to 1)highway=chain_up_area + chain_up_area=dedicated, 2)highway=* + chain_up_area=shoulder, 3)highway=* + lanes=3 + chain_up_area:lanes=no|no|variable - all of course again with :conditional=*. Tricky! --Trapicki (talk) 23:33, 24 November 2021 (UTC) (Changed numbering of first enumeration to Roman numbers for clarity) --Trapicki (talk) 22:06, 9 December 2021 (UTC)Reply
@Skyper: I will ignore the special case III from above, so it's more or less separated areas and special use wider shoulders left over. New idea by KaiRo: highway=chain_up_area for all types, and highway=service only it is separated from the main road and has something that is intendet to be driven on except for chaining up. In case I it's handled like highway=rest_area, and may contain a routable highway=service. In case II it is an area that extends from the center line of the roadto the outer border of the shoulder that is dual used as chain-up area (if the road is mapped as an area, you do the obvious). As shoulders and chain-up areas are not meant to be driven on, they should not be routable. In both cases, :conditional=* can be uses. If there is a permanent usage of the area as rest area, there is no need to tag it, because you may chain up everywhere you are allowed to stop for a few minutes anyway. --Trapicki (talk) 22:06, 9 December 2021 (UTC)Reply
@Trapicki: Thanks for the clean-up, much better now. I still have one minor problem with bays and connecting/drawing the area to the centre line. With parking=street_side` we have a nice example how it can work preserving the geometry and without connection. E.g. chain_up_area=street_side or chain_up_area=bay could be used. I can understand, that you dropped the lanes extension, though, I am a little unsatisfied, as I thought chain_area=both/left/right and chain_area:lanes=no|no|designated would have a chance. --Skyper(talk)17:20, 22 December 2021 (UTC)Reply
@Skyper: I rethought and discussed (outside the wiki) this aspect, but I came to no perfect solution. chain_up_area=street_side would only make sense to ways, and enforce splitting the way (minor problem, but avoidable). Additionally we would have an way that is tagged ..._area, confusing, no better idea here. In any case a chain-up area always needs extra space to savely work at your tires, even on a motorway, which makes it even wider than a regular lane anyway, and is pefectly mapable this way. And it solves the direction problem for the way case. At the same time a chain-up bay is not intended to be driven on regularily, so no separate road. In rendering the road will overlap the area to the middle of the highway anyway (think 3-lane motorway). At the same time a separated chain-up area is easy to do with the same tagging and nearly same style. I would like to keep it as simple and easy to map, and going with area as default, and node for simple tagging seems a good compromise. --Trapicki (talk) 22:37, 23 December 2021 (UTC)Reply
With chain_change_area=street_side, chain_change_area=bay and chain_change_area=rest_area, I think about refining the type of area as subtag. "street_side" is the example, that an area does not have to be glued together with the road center way but you can name it "bay" or something else. One nice side effect would be that we could use it together with highway=rest_area in case where chaining chains is not the primary designation of the area. I just read that I now have posted to different use cases for the simple subtag with the value as key, chain_change_area=*. What kind of type is more important, the location (next to street or bay vs. separate area with own service way) or the common/restricted purpose (chain up and off)? Anyway, all that is only topping and the only reason I mention it, is to show examples how it can work without gluing areas and linear ways together. --Skyper(talk)23:26, 23 December 2021 (UTC)Reply
To get this to an end, I will change it to amenity=*. highway=* collides with existing usage, and insisting on that key leads to problems. Moreover, for the time being, let's just tag that simple, and if best practice shows better ways, let's write it down later. --Trapicki (talk) 21:40, 30 November 2022 (UTC)Reply
Is it safe to conflate all-wheel drive with four-wheel drive, considering that many of these restrictions target trucks? One California sign also makes a distinction for "single-axle drive" vehicles, that is, two-wheel drive vehicles. Maybe we need a conditional variable similar to axles, which is common in truck restrictions (e.g., axles=2)? – Minh Nguyễn💬09:10, 11 November 2021 (UTC)Reply
To prevent another misunderstanding: There is usage of offroad in some legislation to distinguish vehicles on the one hand that is intended to drive on roads, like cars and trucks, that still can drive in rough terrain, and on the otherhand vehicles (end equipment) that is intended not to drive on roads, like mine trucks, excavators, dumpers (and for equipment: chain saw, leaf blower). I'm quite sure we do not need provisions to cover the second one in OSM for quite some time. --Trapicki (talk) 19:44, 21 November 2021 (UTC)Reply
@Kovposch: Thanks for the note. I do not want to burden and confuse this proposal with use and problems of 4wd_only=*, which is not usefull as a condition predicate anyway. By Any tag you like and Just_Map I will keep it as and document it on my wiki pages.
Snow tyres
Latest comment: 4 years ago8 comments5 people in discussion
Totally agree with this remark; here in France, most "chains required" signs come with a text saying that winter tyres are accepted instead. The proposal does not clearly (enough) state how to tag such cases, IMO. --Penegal (talk) 20:30, 11 November 2021 (UTC)Reply
winter tyres, because Britsh English Effectively you could state this as "Either winter tyres or snow chains", that is "Snow chains if no winter tyres AND winter tyres if no snow chains". I can think of a parallel scheme for winter_tyres=*, where the conditions would refer to each other: winter_tyres:conditional=no @ snow_chains and snow_chains:conditional=no @ winter_tyres. Or (I do not prefer that one) switch to something like winter_equipment:conditional=snow_chains @ ice; snow_chains @ snow; winter_tyres @ ice; winter_tyres @ snow, but take care: Last condition in value to match wins; :conditional=* syntax does not have OR (see Conditional_restrictions#Combined_conditions:_AND, which make more complex conditions painfull. This scheme would end in redoing the proposal, not willing to do this without very good reason and help. --Trapicki (talk) 22:38, 11 November 2021 (UTC)Reply
I wouldn't think it's necessary to add a reciprocal winter_tyres:conditional=* if there's already a snow_chains:conditional=* that somehow refers to winter tires as a fallback. We can keep it simple with one or the other. In the U.S., the restriction is mainly about snow chains, with winter tires being an alternative. What about other places? – Minh Nguyễn💬03:28, 12 November 2021 (UTC)Reply
The map in the announcement [5], shows that 9 departments are affected in the whole of their area, and more than 20 in parts. Even if there are signs reminding you of the rules, this is not regulation on road level, but wide area level, actually legislation. You would have to tag every single road in the areas, that would be gazillions. --Trapicki (talk) 19:36, 12 November 2021 (UTC)Reply
There are some places in the western US where *carrying* chains is required even when installing them may not be. I'm not sure if this also happens in other areas.Maybe snow_chains=carried or something similar would be appropriate for such roadways? —Preceding unsigned comment added by Kbroderick (talk • contribs) 20:55, 11 November 2021 (UTC)Reply
As with anything, this is a matter of legislation, but it doesn't apply uniformly everywhere in the jurisdiction. In California, wherever is posted, cars may use snow tires instead of chains but must still carry chains in case. [6][7] Some roads in Washington State require all vehicles to carry chains but not necessarily install them. [8] I had been incorrectly assuming that this requirement meant snow_chains=recommended, but now I'm unsure how to distinguish the requirement to carry chains from no requirement at all. – Minh Nguyễn💬03:38, 12 November 2021 (UTC)Reply
@Aharvey: Yes, this is the case, and one of my motivations for the proposal: If you plan a tour it would be nice if you need to carry chains in your vehicle, and/or if you can expect you have to put them on/fit them. --Trapicki (talk) 20:27, 14 November 2021 (UTC)Reply
"Snow chains required" sign in Australia
In Australia there are also signposted roads that during the declared snow season, chains must be carried, from the start sign to the end sign, and fit where the "Fit chains here" sign is flipped open. --Breno-au (talk) 08:07, 14 November 2021 (UTC)Reply
Point taken. If it is a separate sign for a road specific requirement, carried is the obvious choice. I will add it with a clear note how to distinguish it from required etc, and that the later has to be tagged where it actually occurs. --Trapicki (talk) 20:27, 14 November 2021 (UTC)Reply
The French law has been recently amended: now, winter tyres are mandatory in some areas for a specific period of the year, whatever the weather. How do you propose to take such a situation (common in Europe) in account in your proposal? If you want to? --Penegal (talk) 20:32, 11 November 2021 (UTC) --Trapicki (talk) 21:54, 11 November 2021 (UTC) moved to Discussion SectionReply
Thanks for your comprehensive suggestions and references.
It's clear that this information is relevant to the traffic sign, not the road restriction itself (see Key:traffic_sign#How_to_map). Traffic signs is the rabbit hole that I do not want to go down. For the actual sign contents, one can easily encode the local ID or description, no need to define this here in the proposal. Still I find it important to note that information how a variable sign is shown consistently, whatever it may be in your area. Mayby a note would do for the time being.
While recherching for snow chains, I found surprisingly many variable signs for snow chains, and becomming vigilant to that aspect, found not many other variable traffic signs except Dynamic Traffic Control. This means there is probably not much to draw analogies to, so let's be carefull with reusing other tags that have similar, but subtle different meanings, and let's be brave and define something that fits the topic here.
installation=removable has a different semantic for barriers compared to this thing here. installation=foldable would more like bollard=foldable rather something like the foldable sign at chain-up area "Kettenanlegeplatz Eiberg", see [10]
For prism, sides=* would be the wrong tag, as explained in advertising=*, rather faces, but actually it's very hard to distinguish and irrelevant. Looking at animated=* suggests trivision_blades (brand? trademark?), but I'd prefer a more descriptive prismatic_display.
display:analog=* & display:digital=* is sensible with a clock, because very specific. Here it would be too general. Any of the identified values could be tagged either analog or digital, so no gain here, only information lost.
I'll wait but first: Mainly this info is irrelevant to the restriction's functioning, except for flashing=* affecting the validity of a visible sign. Doesn't make sense to avoid traffic_sign=*, only to squeeze these info dangling in a convoluted tag. ---- Kovposch (talk) 11:30, 22 November 2021 (UTC)Reply
traffic_sign=* seems the right thing to me. One can encode the local ID or description easily, no need to define in this proposal. traffic_sign=variable_message seems nice, but mixes and confuses what to show (the actual traffic sign) with how to show (fixed, variable one out of n, variable whatever you like (screen)). It has a high usage number, but that mainly stems from two usages/users, one heavy usage arround London on the M25, with every single display on a gantry (up to 10!) mapped [11], one arround Paris, and some strange entries in Quito. The value is also not voted for or documented beyond the traffic_sign=* value explanation. We could improve on that, for sure in a compatible ways to existing tagging. The next thing would be to decide how to split what/the contents and the how/way it is shown variable.
Thank you. I didn't read it properly and misunderstood. I now prefer yout proposed tagging.
For better understanding, I would add one sentence to the explanation in the table about the variable sign: snow_chains:variable=weather --> Traffic sign is known to be not permanent" Nielkrokodil (talk) 19:38, 14 December 2022 (UTC)Reply
Ich antworte in Deutsch, weil da kann ich mich exakter Ausdrücken.
Den Text über der Tabelle finde ich jetzt gut. In der Rabelle selbst finde ich es nach wie vor verwirrend.
Das "variable" bedeut ja nur, dass das Schild nicht immer sichtbar ist, unabhängig was dann genau am Schild steht.
Derzeit steht in der Tabelle: "snow chains non permanent required", was zB auch auf ein permanentes Schild mit der Zusatztafel "Schneeflocke" zutrifft (und was nicht mit "variable" einzutragen ist.
Im zweiten Halbsatz wird das meiner Meinung zwar nach korrigiert, aber man muss es schon sehr genau lesen. Spricht etwas dagegen, den Satz "traffic sign is known to be not permanent" voranzustellen?
Latest comment: 3 years ago4 comments2 people in discussion
@Trapicki: I wonder if the documentation for the flashing_lights conditional variable might need to be more specific. It is already in use for maxspeed:variable=*; however, a very similar variable flashing_light is documented for hazmat=*. There, it means that the value applies when a flashing light is mounted on the vehicle, not when the restriction sign has flashing lights activated. Maybe we can get those hazmat=* values retagged to avoid misunderstandings. – Minh Nguyễn💬06:57, 9 December 2021 (UTC)Reply
@Minh Nguyen: For hazmat:conditional=yes @ (flashing_light) it is unclear if the flashing light are required on the vehicle (which is the case) or on the sign. For snow chains, flashing lights on vehicles would not make much difference, so this would be unambiguous. Nevada has regulations for "snow chains (or snow tires on awd/4wd) on flashing light" with obviously two altenating flashing lights, see [13]. Reason enough for me to use plural. hazmat:conditional=yes @ (flashing_light) is currently used 19 times, could be fixed. I do not see urgent need for fixing this and it is out of scope for me, but maybe you feel motivated? Will add a comment in the proposal, though. --Trapicki (talk) 23:17, 2 December 2022 (UTC)Reply
Flashing light atop a vehicle@Trapicki: I think Key:hazmat#Specific_restrictions is clear that it's for the case where the driver has to mount a light (more likely a rotating light than a flashing one) atop the vehicle. I'm not necessarily asking for you to select a different variable; just recommending to add some language to the proposal to clarify that this refers to the sign rather than the vehicle, because conditional variables can be about either. – Minh Nguyễn💬07:35, 3 December 2022 (UTC)Reply
@Minh Nguyen: I reworked it, see version from today. If you find it still easy to miss or misunderstand, I trust you to change the description accordingly. If you find it ok, please add a Resolved mark to this topic.
Examples - Default condition
Latest comment: 3 years ago3 comments2 people in discussion
"Probably one of the default conditions." can be dangerous - it can be interpreted as meaning "this applies to all roads everywhere, if situation is different then it should be tagged". What exactly you wanted to express here? "Probably one of the typical conditions."? Mateusz Konieczny (talk) 13:31, 10 April 2022 (UTC)Reply
You are referring to the Examples, first entry snow_chains:conditional=required @ snow; required @ ice where I (trapicki) noted: "Probably one of the default conditions." You are very right, thank you for reading carefully and critically. I know that in Austria most "Snow chains required" signs have that condition as an additional sign, but of course it's not a default in the sense you can rely on it and goes without saying. Fixed. (Renamed section and moved to "Discussion") --Trapicki (talk) 17:23, 10 April 2022 (UTC)Reply
Ready for voting?
Latest comment: 2 years ago3 comments3 people in discussion
I think the Chain area-topic is solved now? So is there still anything left to be solved before the start of "Ready for voting"? --Ppete2 (talk) 14:07, 16 October 2023 (UTC)Reply
Examples
Latest comment: 3 years ago3 comments2 people in discussion
incline=up doesn't fit as a condition. incline=* is for the road, depends solely on the drawing direction. A two-way road always have both up and down driving direction. What if mtb:scale:uphill=* is adapted to be snow_chains:uphill=*? This *:uphill=* and alongside *:downhill=* suffix needs more discussion.
@Kovposch: Totally right: incline=* describes the road relative to the drawing direction. This here is an absolute driving direction. Using relative direction here seems wrong to me because first, it's specified as absolute direction in the signs, both when comming from the lower area and from the upper area. Second the road could be flat or inclined in the other direction in the restricted section; the mapper would have to know that, and mapping incline is not always to do. Two ways here: Either as part of the key like with direction in Conditional Restrictions, or as Condition like Vehicle usage. As this is very common in Austria where I intend to map some snow chain restrictions, I want that solved satisfacorily. --Trapicki (talk) 19:24, 4 December 2022 (UTC)Reply
Legal Requirements?
Latest comment: 3 years ago2 comments2 people in discussion
I don't understand the comments like "legal requirements shall not be tagged " and "Don't map your local legislations". Isn't the whole point of this to tag the legal requirements for snow chains? When would snow_chains=required NOT be a legal requirement? --Bradrh (talk) 21:07, 5 December 2022 (UTC)Reply
@Bradrh: There is a distinction between some object bound property like snow chain requirements on a specific road at a specific time and an aread bound general legislative requirement like to carry them with you during winter. This proposal is about the first one. Some roads are particular slippery and snowy and have traffic signs that state the specific snow chains requirement. Very similar to general speed limits that are overridden by specific speed limits on sections of roads. Otherwise you would have to tag every single driving rule on every road. See Good_practice#Don't_map_local_legislation_if_not_bound_to_specific_objects. I updated the section to make this easier understandable. --Trapicki (talk) 06:44, 6 December 2022 (UTC)Reply
Recommended carried variant?
Latest comment: 3 years ago2 comments2 people in discussion
The proposal currently has snow_chains=carried, where you must carry chains in the vehicle (this is a compulsory carry for all vehicles in Victoria, Australia). We also have snow_chains=recommended, stating "Snow chains are recommended to be put on". Can another variant be considered where it is a recommendation from officials that chains be carried?
There are also lesser-affected highways such as the Snowy Mountains Highway in NSW, where there is no requirement for any vehicle type to carry, however it is recommended to carry during the winter months. --Breno-au (talk) 01:45, 11 December 2022 (UTC)Reply
Austrian sign example
Latest comment: 1 year ago1 comment1 person in discussion
In the last example for snow_chains:conditional=*, is the tonne value given on the plate with the snowflake symbol really referring to weight, or is it rather the weightrating? The use of the value of specifically 3.5 t seems to suggest the latter, but it may be just a coincidence, and I'm no expert on Austrian traffic regulations :) --Dzamper (talk) 07:51, 30 October 2024 (UTC)Reply
Resolved: Values are extended, scope is clarified --Trapicki (talk) 23:52, 9 December 2021 (UTC)
89596214. As it is nearly 13 km long driving through with chains would impede trafiic flows & likely damage the tarmac. In very snowy conditions access to the tunnel is limited because of ventilation issues if the exit roads are congested – also likely as drivers put on & take off chains. However, this may not be explicitly signed as driving on snow or ice free roads with chains is not allowed. SK53 (talk) 19:55, 10 November 2021 (UTC)
signs ban lugs/studs/grousers/cleats. However, I've never seen a sign allowing or requiring them. It may be just a reminder about state law prohibiting lugs on all roads. – Minh Nguyễn 💬 03:18, 12 November 2021 (UTC)
I assume studded tires are only allowed on unpaved or graded roads. Even some of Alaska's major highway routes are unpaved. – Minh Nguyễn 💬 06:03, 12 November 2021 (UTC)
.svg){kind=small}
Moved to Talk:Proposed_features/Snow_chains#ValueThis question was targeting the discussion of values, not "No Chains".--Trapicki (talk) 16:21, 19 December 2021 (UTC)
means vehicles with snow tires are still required to carry chains, but that happens to be a uniform requirement under state law, unlike some of the other states' signs about carrying. [3] – Minh Nguyễn 💬 07:13, 9 December 2021 (UTC)
and way 
. --Skyper (talk) 17:18, 23 November 2021 (UTC)
Disregard: out of scope --Trapicki (talk) 18:35, 2 December 2022 (UTC)
is posted, cars may use snow tires instead of chains but must still carry chains in case. [6][7] Some roads in Washington State require all vehicles to carry chains but not necessarily install them. [8] I had been incorrectly assuming that this requirement meant 
