Proposal talk:Snow chains

From OpenStreetMap Wiki
Jump to navigation Jump to search

For reference, please read Proposed features/Snow chains/Additional information and contribute your country's signs if absent.

No Chains

Resolved: Values are extended, scope is clarified --Trapicki (talk) 23:52, 9 December 2021 (UTC)

I can think of at least one roadway where chains are banned: the Arlberg (road) Tunnel (e.g., way 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)

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)
Included tunnels as examples in Version 2.--Trapicki (talk) 23:43, 11 November 2021 (UTC)
https://www.obelink.de/beratung/wo-und-wann-sind-schneeketten-pflicht.html lists examples for banned snow chains in tunnels: Selisbergs, St. Gotthard, San Bernardino. No chains allowed for example in the Netherlands. --Trapicki (talk) 00:16, 12 November 2021 (UTC)
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)
@Kovposch: Are the bans on metal chains specifically about lugs or metal treads, perhaps? United States/Tags#Access restrictions casually suggests grousers=no and metal_treads=no, respectively. But there it's phrased as a standalone access restriction, rather than a variable for a conditional restriction. – Minh Nguyễn 💬 09:03, 11 November 2021 (UTC)
It's a non-standard text-only sign at a few of Japan's longest tunnels, directing metallic chain vehicles to take them off at a designated place before entering the tunnel. https://twitter.com/expwy_sign/status/928969696254164992 ---- Kovposch (talk) 11:54, 12 November 2021 (UTC)
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)
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)
In the U.S., No Vehicles With Lugs 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)
Actually, I take that back: Alaska has signs prohibiting, sometimes prohibiting, or requiring studs. No Studded Tires No Studded Tires (Dates) Studs or Chains Required Next 3 Miles 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)
@SK53:@Kovposch:@Minh Nguyen: Are we covered for the time being with required=*, recommended=*, carried=*, prohibited=* and default=* (just for snow_chains:conditional=*? —Preceding unsigned comment added by Trapicki (talk • contribs) 00:18, 7 December 2021 (UTC)
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)

Studs, Lugs etc.

Resolved: Out of scope, clarified in proposalTrapicki (talk) 23:11, 6 December 2021 (UTC)

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)

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)

Value

For equipment and accessory use, which are not vehicle modes, using the set of restrictions from headlight=* may be favorable.

-- Kovposch (talk) 08:23, 11 November 2021 (UTC)

Point taken. *=required and *=prohibited work fine for me; *=allowed would be legislation, and *=recommended pointless. --Trapicki (talk) 22:41, 11 November 2021 (UTC)
Included in Version 2. *=allowed is not that wrong, needed instead of "no" in conditions. One would not prohibit snow chains for some vehicles while others are required to have them --Trapicki (talk) 23:46, 11 November 2021 (UTC)
Alaska and Idaho have warning signs "recommending" snow chains. [1][2] show_chains=recommended would be reasonable for this case. The alternative would be something involving hazard=* that would be less obvious. – Minh Nguyễn 💬 20:08, 13 November 2021 (UTC)
Right, *=recommended is really a reaseonable case. Needs to be clarified that this is not a default value, but for actual road signage. --Trapicki (talk) 13:39, 14 November 2021 (UTC)
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)
Added in Version 3. --21:14, 16 November 2021 (UTC)
Are we covered for the time being with required=*, carried=*, recommended=*, default=* (just for snow_chains:conditional=*, and prohibited=*? --Trapicki (talk) 23:52, 9 December 2021 (UTC)
Moved here from #No Chains --Trapicki (talk) 16:21, 19 December 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, R79 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)
Yes, was intended to ask for closing #Value and #Carrying required, see there. It seems like recommended=* is really a thing, weak as it may seem, still a traffic sign, and for me valuable information worth being available on a map/routing system. --Trapicki (talk) 23:52, 9 December 2021 (UTC)
@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)
@Minh Nguyen: Sorry, misunderstood. Without forking of another hierachy for "carrying", I think of: *=required, *=carrying_required, *=recommended, *=carrying_recommended, *=default (just for snow_chains:conditional=*), and *=prohibited.
Continued here from #Recommended_carried_variant?
@Minh Nguyen:@Breno-au: added *=carrying_required and *=carrying_recommended via [4]. Wanted to do that earlier, now included. --Trapicki (talk) 21:13, 11 December 2022 (UTC)

"On demand"

Resolved: Version 3 --Trapicki (talk) 21:14, 16 November 2021 (UTC)

crossing:on_demand=* is requested from the road user, not authorities. This is not the same as them demanding (actually ordering) you to do something. snow_chains:variable=* is better. ---- Kovposch (talk) 08:23, 11 November 2021 (UTC)

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)
@Kovposch:@Minh Nguyen: Please have a look at Version 1 with new explanation. I have my pains with both "on_demand" (collides with meaning of crossing:on_demand=*) and "variable" (maxspeed:variable=* ususally means there is some defined max speed, that may change). More opinions highly welcome. Regarding flashing: looks fine to me, will add. --Trapicki (talk) 18:53, 11 November 2021 (UTC)
Key:maxspeed:variable#Examples has maxspeed=none + maxspeed:variable=yes. ---- Kovposch (talk) 12:02, 12 November 2021 (UTC)
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)
Changed to snow_chains:variable=* in combination with snow_chains=default in Version 3. --21:14, 16 November 2021 (UTC)
Why do we need a dedicated tag here at all? Is there any case where snow_chains=on_demand would cause tagging problems? --Mueschel (talk) 14:32, 13 November 2021 (UTC)
@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)

Chain area

Relation to Rest area

Resolved: Version 3 --Trapicki (talk) 21:14, 16 November 2021 (UTC)

Could you use highway=rest_area + rest_area=chain_up? If they are "very similar". We may add other purpose-use rest_area=*, viz rest_area=brake_check. Dozens of similar https://taginfo.openstreetmap.org/search?q=brake check#values. To show there's no other facilities, this may be assumed, or add a minimal toilets=no. If they allow you to stop for any reason, they may already qualify as a highway=rest_area.-- Kovposch (talk) 08:23, 11 November 2021 (UTC) --Trapicki (talk) 18:26, 11 November 2021 (UTC) Subsections

@Kovposch: Reworked Proposed_features/Snow_chains#Value_highway.3Dchain_up_area in Version 1.
Some may be similar, but others aren't. This one, for example, is just a wide spot in the road with a few additional lights. --Carnildo (talk) 05:48, 12 November 2021 (UTC)
Perfect example of a long chain bay, for sure not a rest_area. --Trapicki (talk) 19:14, 12 November 2021 (UTC)
More detailed tagging instructions in Version 3 --21:14, 16 November 2021 (UTC)
The counterpart on I-90 is separated spaceous by road marking, bridging the gap from a "chain-up bay" to a physical separated "chain-up-area".

Chain down area

Resolved: settled to 'chain_change_area'

You need add *=chain_off* for removal.-- Kovposch (talk) 08:23, 11 November 2021 (UTC) --Trapicki (talk) 18:26, 11 November 2021 (UTC) Subsections

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)
Included in Version 2. --Trapicki (talk) 23:47, 11 November 2021 (UTC)
https://pixta.jp/photo/48819500 They exist in Japan. Of course, may not be as common. ---- Kovposch (talk) 11:44, 12 November 2021 (UTC)
Nice example for signs in Japan! Would love to get a picture with compatible license for the Wiki. --Trapicki (talk) 19:28, 12 November 2021 (UTC)
Some are labeled as chain up & down area uniformly, but show a chain down sign. ---- Kovposch (talk) 11:58, 12 November 2021 (UTC)
@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)
@Kovposch: More explanations in Version 4 --Trapicki (talk) 21:23, 23 December 2021 (UTC)
moved here from #Value_name As stated under Proposed_features/Snow_chains#Chain_down_area Chain down area (edit: that is, here) there is usually no restriction between chain up or down and the proposal is for both. Now I wonder if the more general highway=chain_area or highway=chain_change_area might be better to leave all speculations beside and room for a subkey defining areas only for chain up or down. like chain_up=only/designated/yes/no resp. chain_down=*. --Skyper (talk) 17:44, 22 December 2021 (UTC) moved from #Value_name --Trapicki (talk) 22:37, 23 December 2021 (UTC)
@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)
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)
To make it flexible but not extend it further, I think *=chain_change_area* is proper. If anyone wants to add more information it can as always be done by sensible ad-hoc tagging. --Trapicki (talk) 22:05, 30 November 2022 (UTC)
@Trapicki: The proposal currently refers to amenity=chain_down_area in one place. Is that a typo, or do we still intend to distinguish between chain-up and chain-down areas? – Minh Nguyễn 💬 21:37, 2 December 2022 (UTC)
@Trapicki: Typo. Fixed. --Trapicki (talk) 22:27, 2 December 2022 (UTC)

Chain area Name

Resolved: Version 2 --Trapicki (talk) 21:14, 16 November 2021 (UTC)

Don't use improper name=chain-up area descriptor labels.-- Kovposch (talk) 08:23, 11 November 2021 (UTC) --Trapicki (talk) 18:26, 11 November 2021 (UTC) Subsections

Point taken, Good_practice#Don.27t_use_name_tag_to_describe_things--Trapicki (talk) 22:52, 11 November 2021 (UTC)
Included in Version 2. --Trapicki (talk) 23:47, 11 November 2021 (UTC)

Object type to use

Resolved: Settled to 'amenity' --Trapicki (talk) 21:40, 30 November 2022 (UTC)

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)

snow_chains=*: see Proposed_features/Snow_chains#Key_snow_chains.3D.2A 1st sentence: "Applies to highway=whatever applies to motorized vehicles, ways only.". Not sure what you meand by open ways. Area: Do you have any example usage in mind? I'd like to include the "way" symbol properly, do not know how. --Trapicki (talk) 16:30, 23 November 2021 (UTC)
highway=chain_up_area has a section for how to tag after the table. Symbols would point it out. I was not aware of bus_bay=*, seems to be richer (left, right, both, :left=* etc.) than emergency_bay=*. I'll add that as reference, and maybe convert to a table and add a column Object Type--Trapicki (talk) 16:30, 23 November 2021 (UTC)
Yes, a table for the different object types would be helpful. --Skyper (talk) 16:55, 25 November 2021 (UTC)
Sorry, I read to fast. Yes, node node and way way would help a lot. "Open way" is the opposite of "closed way", i.e. area area. --Skyper (talk) 17:18, 23 November 2021 (UTC)
Added. Much nicer now :-). And yes, no "closed ways" here, thanks for the precise term. --Trapicki (talk) 23:33, 24 November 2021 (UTC)
+1, thanks --Skyper (talk) 16:55, 25 November 2021 (UTC)
a) I would not accept another highway=chain_up_area next to the main road without physical barrier in between. Bays or shoulder lanes should be added as additional tag to the main `highway=*`, like snow_chain_bay=left;right;both. --Skyper (talk) 17:18, 23 November 2021 (UTC)
b) How about areas? Is it appropriate to tag chain areas similar to highway=service + area=yes or amenity=parking? --Skyper (talk) 17:18, 23 November 2021 (UTC)
Hard for me to understand how highway=service can work with area=yes, see Key:area#Highway_areas. That's why highway=rest_area suggests highway=service for dedicated roads. If the word area is misleading in the value/tag, let's find something neutral; snow_chain_bay has the same problem. --Trapicki (talk) 23:33, 24 November 2021 (UTC)
highway=service (without trailing s) and highway=pedestrian are allowed as route-able areas, the rest not. As far as I get it, you consider it more like "amenity" and not route-able but with another linear highway=* for routing more like highway=rest_area or highway=services and not like highway=emergency_bay. The last is only valid on node node and way way while the other are valid on node node and area area. Defining it for all object types makes it really tricky. Is it possible to map some examples? Thanks in advance. --Skyper (talk) 16:55, 25 November 2021 (UTC)
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)
Maybe, I got you completely wrong and you want to keep it simpler than I had in mind. By chance, do you want to exclude it from routing completely and consider the parallel way way more like public_transport=platform is used? --Skyper (talk) 16:55, 25 November 2021 (UTC)
1) Is the difficult case. If highway=chain_up_area is allowed as route-able way way it needs to be the primary purpose. Most of the software needs to be adjusted. As we need a solution for secondary or temporary purpose which needs to work together with highway=emergency_bay or highway=service on a linear way way and together with highway=rest_area on an area area, I am not sure about highway=*. Do we need it? chain_area=up, chain_area=down and chain_area=both would work all the time. :left, :right and :lanes could be used and chain_area:type=* for the purpose or better for the type like shoulder or exclusive area. --Skyper (talk) 16:55, 25 November 2021 (UTC)
2) does not work in my eyes, but we might be not on the same page. --Skyper (talk) 16:55, 25 November 2021 (UTC)
3) No problem with that, I can help in finding the correct syntax. --Skyper (talk) 16:55, 25 November 2021 (UTC)
@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)
@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)
@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)
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)
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)

Value name

Moved to Talk:Proposed_features/Snow_chains#Chain_down_area--Trapicki (talk) 22:37, 23 December 2021 (UTC)

AWD

Disregard: out of scope --Trapicki (talk) 18:35, 2 December 2022 (UTC)

There's already 4wd_only=* for all-wheel drive. No "recommended" yet. Perhaps you can use *:conditional=* @ (incline=up) for your example. ---- Kovposch (talk) 08:29, 11 November 2021 (UTC)

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)
I'm really unhappy with 4wd_only=* actually meaning "offroad vehicle", like defined in https://wiki.openstreetmap.org/w/index.php?oldid=436611#Definition_of_a_4WD. There is actually a legal definition for offroad vehicles in Europe https://en.wikipedia.org/wiki/Vehicle_category#UNECE_categories and the USA https://www.ecfr.gov/current/title-43/subtitle-B/chapter-II/subchapter-H/part-8340 that name the exact same thing "offroad". At least in Austria we have regulations that distinguish offroad vehicles from more-than-one-axle-drive and all-wheel-drive vehicles (like what is call SUV in Europe). I do want to be able to distinguish those, but I do not want to redefine 4wd_only=*. Thus my distinction of awd and offroad. I'm open to more specific things like additionally axles=2, but let's not overdo this here, maybe wait for ad-hoc mapping examples. --Trapicki (talk) 19:14, 11 November 2021 (UTC)
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)
@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

Referring to Talk:Proposed_features/Snow_chains#United_States below, it may be more comprehensive to add winter wheel tagging to complement. ---- Kovposch (talk) 08:42, 11 November 2021 (UTC)

In particular, some of these signs allow either snow chains or snow tires. I'm not sure how that could be tagged if snow_chains=* is a key. Would we relegate the presence of snow tires to a conditional variable too, like snow_chains:conditional=allowed @ snow_tyres? – Minh Nguyễn 💬 09:14, 11 November 2021 (UTC)
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)
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)
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)
In France there are (will be) road signs for that: French road signs B58 and B59. Source French government web site. The French version of the page also includes the above image. It's similar to a zone:maxspeed=* which is not mapped as an area, but rather on each road. --Gonéo (talk) 08:56, 12 November 2021 (UTC)
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)
Added example for snow tires. --Trapicki (talk) 23:46, 6 December 2021 (UTC)

Carrying required

Resolved: Version 3 --Trapicki (talk) 21:14, 16 November 2021 (UTC)

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)

(Update: Point taken, see below) If his is legislation, should not be tagged, see Good_practice#Don.27t_map_your_local_legislation.2C_if_not_bound_to_objects_in_reality --Trapicki (talk) 22:14, 11 November 2021 (UTC) --Trapicki (talk) 20:27, 14 November 2021 (UTC)
As with anything, this is a matter of legislation, but it doesn't apply uniformly everywhere in the jurisdiction. In California, wherever Autos & Pickups Snow Tires OK; Carry Chains 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)
Would it be wrong to assume that any road with snow_chains:conditional=required implies that you must carry chains so that when conditions change you can comply with the requirement? When would this not be the case? --Aharvey (talk) 08:03, 14 November 2021 (UTC)
@Aharvey I think it starts getting confusing around required to fit vs required to carry. --Breno-au (talk) 08:09, 14 November 2021 (UTC)
@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)
Victoria Australia chains must be carried sign
"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)
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)
Added in Version 3. --Trapicki (talk) 21:14, 16 November 2021 (UTC)

Whole area with chains/winter tyres mandatory: how to map?

Disregard: --Trapicki (talk) 21:14, 16 November 2021 (UTC)

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 Section

This is legislation, should not be tagged, see Good_practice#Don.27t_map_your_local_legislation.2C_if_not_bound_to_objects_in_reality. I do not want to cover that in the proposal, as this is nothing to be decided upon - your local legislation institution take that burden from us. Nevertheless, independent of the proposal information can be gathered like Key:maxspeed#Implicit_maxspeed_values and/or Default_speed_limits (volunteers? I'm bussy proposing...). A very good start would be https://de.wikipedia.org/wiki/Winterausr%C3%BCstung_(Stra%C3%9Fenverkehr) which is unfortunately German only. --Trapicki (talk) 22:14, 11 November 2021 (UTC)
Included in v2.--Trapicki (talk) 23:48, 11 November 2021 (UTC)
This should be be documented in the wiki maybe at OSM_tags_for_routing, like pointed out in [9] --Trapicki (talk) 19:53, 21 November 2021 (UTC)

For trucks only

Resolved: Version 3 --Trapicki (talk) 21:14, 16 November 2021 (UTC)

Example of tagging where it applies only to some vehicle classes would be a good idea. https://glos24.pl/w-gory-tylko---na-zimowkach- has https://cdn.glos24.pl/images/bhgfhbg.png showing case where it applies to buses and trucks only (snow_chains:hgv=* and snow_chains:bus=*?) Mateusz Konieczny (talk) 09:26, 12 November 2021 (UTC)

@Mateusz Konieczny: Great example, with incline=*. I'd love to include a picture with a OSM-wiki compliant license. Can you take provide one?--Trapicki (talk) 19:17, 12 November 2021 (UTC)
I will try, but I live in city far away from mountains, so it is unlikely to succeed :( Mateusz Konieczny (talk) 23:52, 13 November 2021 (UTC)
I added a truck-only example from British Columbia to the page. – Minh Nguyễn 💬 22:18, 12 November 2021 (UTC)

snow_chains:conditional and "snow_chains:conditional @ *"

Resolved: --Trapicki (talk) 21:14, 16 November 2021 (UTC)

Don't really see a use for ":conditional @ snow/ice" when ":on_demand". Emilius123 (talk) 10:34, 12 November 2021 (UTC)

@Emilius123: snow_chains:conditional=* and snow_chains:variable=*/snow_chains:on_demand=* are completely independent and reasonable each alone. They may and do occur together, like a variable "snow chains for trucks" sign. Can you explain your objection little more in detail? --Trapicki (talk) 19:22, 12 November 2021 (UTC) -- Uhh, you're pronbably right, sorry for bothering @Trapicki: --Emilius123 (talk) 00:30, 13 November 2021 (UTC)

Ref

Resolved: Version 3 --Trapicki (talk) 21:14, 16 November 2021 (UTC)

Key:ref goes well with highway=chain_up_area proposal as a related tag. In Australia, chain bays are numbered 1 as the highest elevation chain bay on that road, with the subsequent chain bays going up in reference number heading down the hill. Eg. https://www.openstreetmap.org/way/255766084 --Breno-au (talk) 08:16, 14 November 2021 (UTC)

Added in Version 3 --Trapicki (talk) 21:14, 16 November 2021 (UTC)

Variable Sign

Resolved: removed from proposal, out of scope. Trapicki (talk) 23:08, 6 December 2021 (UTC)

Let's not use *:type=*. I suggest the following:

-- Kovposch (talk) 09:45, 17 November 2021 (UTC)

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.
  • snow_chains:variable:type=flashing --> snow_chains:conditional=* @ (flashing_lights): perfectly right, will point that out and add example.
  • 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.
  • Researching/asking for traffic_sign=variable_message, more to come. --Trapicki (talk) 22:54, 21 November 2021 (UTC)
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)
  • 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.
I removed the section about snow_chains:variable:type, archived in User:Trapicki/Variable_traffic_signs along with the comments. I'd like to discuss this further a little more, is out of scope here. --Trapicki (talk) 23:08, 6 December 2021 (UTC)

Variable Sign reasons

Is there any other reason than "weather" to install a snow chain sign? If no, wouldnt snow_chains:variable=yes be better than =weather Nielkrokodil (talk) 14:32, 14 December 2022 (UTC)

@Nielkrokodil: No and no, because of consistency and specific information. Did you read maxspeed:variable=*? Trapicki (talk) 16:05, 14 December 2022 (UTC)
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)
I improved the wording, hope that helps. --Trapicki (talk) 22:59, 15 December 2022 (UTC)

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? 

Nielkrokodil (talk) 11:34, 17 December 2022 (UTC)

flashing_lights

@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)

@Trapicki: Do you think it'll be a problem if flashing_lights means something different in snow_chains:conditional=* than flashing_light does in hazmat:conditional=*, where it already seems to be in use? [12] Consider clarifying the difference between "light", singular, and "lights", plural. – Minh Nguyễn 💬 21:35, 2 December 2022 (UTC)
@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)
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)
@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

Resolved: fixed in Version 4 --Trapicki (talk) 17:47, 2 December 2022 (UTC)

"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)

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)

Ready for voting?

Looks like there's been great discussion. Is the proposal ready to progress to a vote? --Breno-au (talk) 04:31, 26 March 2022 (UTC)

There are still open questions regarding Chain area. As a native English speaker, you might want to comment on proper key and value names. --Skyper (talk) 12:41, 28 March 2022 (UTC)
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)

Examples

motorcar

I haven't read all. One mistake I see: You should use snow_chains:motorcar:conditional=*. motor_vehicle AND awd is redundant, when awd is enough. --- Kovposch (talk) 14:03, 3 December 2022 (UTC)

@Kovposch: Fixed. --

uphill vs. incline

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 (talk) 14:03, 3 December 2022 (UTC)

@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)

Legal Requirements?

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)

@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)

Recommended carried variant?

Moved to #Valuewas requested a second time before --Trapicki (talk) 21:17, 11 December 2022 (UTC)

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?

In New South Wales, Australia, 2WD vehicles must carry snow chains by law. However, 4WD/AWD vehicles there is a recommendation to carry for these vehicle types. https://www.nationalparks.nsw.gov.au/safety/alpine-safety/snow-driving

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)

Austrian sign example

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)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Snow_chains&oldid=2771488"