Proposal:Access restrictions

Access restrictions
Proposal status:	Canceled (inactive)
Proposed by:	Eimai
Draft started:	2008-06-26

Add things to this page as you wish, this page is in "brainstorming mode".

Rationale

The current way of creating access restrictions does not allow for more complex restrictions. Since the scheme is not easily extendable, we need to completely rethink this. A first effort was made with the access name space, however it's not good enough to tag more complex restrictions.

Applies to

• Ways
• Nodes
• Areas

Working method

I'm not writing down a proposed tagging scheme yet. We first need to investigate current problems, possible solutions and things to keep in mind.

I understand that this will not be an easy task, and I'd like to see a lot of input while creating a tagging scheme, so that at the end of this, we can have a clean and unambiguous tagging scheme that can really apply practically everywhere.

We might need to split up the proposals for new tagging schemes to keep things manageable for voting etc. I see this division: (first one being most important one, the others could be split to separate proposals).

• new tagging scheme
• vehicle types
• restriction types

Since we need to keep the last items in mind to come up with a good tagging scheme, we keep it on this page for now.

Issues

• Tags like maxspeed=*, oneway=*, maxweight=* etc. apply to all vehicle types. It could be that vehicles over a certain weight have a lower maximum speed for example. Or that bicycles are allowed in both directions in a oneway street (there is a cycleway=opposite though, but no similar rules for other vehicle types)
• Common sense says oneway=* doesn't apply to pedestrians. That's mentioned nowhere. We need to define rules like this somewhere or a computer won't be able to understand them
• Tags with vehicle types like bicycle=*, motorcar=* etc. apply to all vehicles of that kind. It's not possible to have a restriction on motorcars higher than 1m50.
• Current access restrictions always apply to vehicles on the road, while in reality the rules could be different in both directions, or even on different lanes in the same direction.
• Current access time restrictions tags like date_on=* and hour_off=* are not flexible enough
• Sometimes access is only allowed to buses of one operator. bus=yes wouldn't be correct.

Issues with proposed access namespace

• Not sufficient for restrictions on vehicles that have more than one property: e.g. access=no only for goods vehicles over 3.5 tons. Easy to do, just use access:goods:max_weight=3.5 tons
• Not sufficient for restrictions on vehicles that have more than one property: e.g. access=no only for goods vehicles over 3.5 tons except destination traffic

hgv=destination + hgv:maxweight:3.5=yes or

hgv=no + hgv:minweight:3.5=destination

• Does not solve restrictions that don't apply all the time, e.g. a road with access=destination only on Friday

access:weekday:friday=destination

Both last are IMHO a very bad solution, putting data in the keys to make it bi-dimmensionnal is suicide, we almost won't be able to compute statistics, or make research on a database. At the extrem limit, I will find something like access:hgv:minweight=friday,destination a litter better, but hardly. I'm on the talk page, time for logic (A AND B OR C) AND K Sletuffe 17:30, 22 November 2008 (UTC)

• Does not solve restrictions in different directions or different lanes.

For different directions: access=destination + access:backward=no

(For different lanes not yet.)

Problems we face

• No need to make things difficult for situations that aren't complex. We may need more than one tagging scheme.

Possible solutions we need to look into

• Relations are most likely the only option for the complex restrictions.
• Relations shouldn't be needed for easy situations.
• We should consider the possibility of adding extra ways: One way for each lane would solve the issue with differing restriction on different lanes, and also most cases of oneway-exceptions (where there's a separate lane for the opposite direction). This is similar to adding a lane-relation with specific tags for each lane, but lanes are physically different ways in a sense.

I don't see that happening. Sure, it could solve some things, but it's common to only separate roads when they're also separated in real life (i.e. dual carriageways for example). Also, not all roads have lanes, so restrictions in one way can still apply even though there are no lanes painted on the road, so different ways for each lane doesn't solve that. Different ways for each lane would also introduce more problems, like routing issues. --Eimai 14:15, 8 July 2008 (UTC)

Some thoughts on Relations

Aren't relations basicially to define (as the name says) relations between several objects, rather than just use them to group tags together logically? There would be other possibilities to do this (apart from a api change), like inventing a special syntax for the grouping of tags. For example: access[1]=destination, access[1]:maxweight=3.5 that restricts vehicles that weight more than 3.5t to enter, unless their destination is there.

But let's say we use relations. How many objects should be able to be a member of a single access-relation? Just one connected part that has the access-restriction or maybe several in the same area, to save the effort of creating more relations? Theoretically we could have one relation for all "3.5t except destination" cases, but that might not be very easy to manage.

Relations might be a solution to more complex access-restrictions since they can nicely group tags together. Though other possible solutions should also be considered. Also if relations are more widely used, editors might provide presets for certain cases to make adding relations easier than it is now. --Driver2 23:54, 22 September 2008 (UTC)

The big advantage relations have IMHO is that if the restriction applies to many ways you don't need the same list of tags on all the ways (you can easily make errors with that). However, your access[] looks alright, but I think it might have issues when it gets translated to things like OSM_Mobile_Binary_Protocol. It also adds a layer of error possibilities when you have the numbering wrong, and in effect does the same as the relation: grouping tags together, except you can't share them over more than one way without duplicating. Relations basically shouldn't be seen as "this complex thing" IMHO, as many seem to think. We just need some good editor support. --Eimai 15:15, 23 September 2008 (UTC)

I think relations are seen as complicated because of a lack of well organized documentation. It's the same with many other topics. There are lots of pages concernig the same or similiar topic, but often containing contradictory or old information. Many pages are well done, but in a whole it's not easy to find something on the wiki, even if you've seen it once before. --Driver2 19:37, 23 September 2008 (UTC)

Mixture of solutions

I don't think it is practical to change the current tag structure, since people are already used to it. So the way to go would be a mixture of solutions (as you already mentioned in some way I think):

• Keep the simple keys like access=*, foot=*, bicycle=* and so on, with the usual values like access=yes,no,destination,... Maybe add a few if needed and define them more clearly, so people actually know what to use when. Those tags should be sufficient for a great many situations.
• Define a syntax to add properties and parameters to tags, for situations where a single tag does only apply under certain situations. Much like Proposed features/Properties for Tags but probably a bit refined. Like oneway:bicycle=no (parameter) or bicycle=no, bicycle.time=Mo-Fr 08:00-18:00 (property). This could also be useful for tagging in other areas.
• Create relations for more complex situations that require more tags and maybe consist of several ways

(I hope I don't annoy you by filling your page with crap, but I find this topic pretty important.) --Driver2 23:36, 23 September 2008 (UTC)

I've always said we need to keep the tags we have (although we need to formally define them somehow as they leave way too much room for ambiguities right now). Then we may need a not-too-complicated way of doing things like my bicycle:oneway=no, and then relations for something which can't be done with simpler methods, or for when the access rule spans several ways. --Eimai 12:10, 24 September 2008 (UTC)

Your bicycle:oneway=no tag is a good idea, but we should think about how to get easy parse-able tags. A routing tool interested in access restrictions should do a simple search-request on "access" and than parse the structured results. I think some thing like access=general:horse:no; oneway:yes; oneway:bicycle:no could be a better solution. The current api would us allow to store these three values in three seperate access tags, but it is planed to remove this feature. See API v0.6#Related_database_improvements! If a user simply tags oneway=yes a database-fixbot, the api or the mapping-software could replace it by a access=oneway:yes --Phobie 04:52, 28 November 2008 (UTC)

You here speak about a broader problem, which will persist as long as we don't tag highway=cyclelane seperately from the highway=street. bicycle:oneway|no or a similar key is definitely needed as long as cyclelanes are tagged on the same polyline as other highways. The same question will come up for turning restrictions (often a bicycle user might decide to take the footwalk to cross the street, where cars are not allowed to turn left (on european, not english streets). While I can implement this into mkgmap, it is impossible to parse this with mkgmap access=general:horse:no; oneway:yes; oneway:bicycle:no. Any routing tool interested in bicyclerouting, will have to be setup having a look at much more pecularities. I think any additional value will be one more line in the rendering rules, and it doesn't really matter what the name is, as long as it is included to rendering rules.--Extremecarver 10:11, 28 November 2008 (UTC)

Types of access restrictions

• maximum speed
• minimum speed
• maximum weight
• maximum maximum weight
• maximum weight per axle
• maximum length
• maximum height
• minimum occupancy
• no certain kinds of goods allowed (dangerous, explosive or inflammable, or polluting goods)
• use of cruise control not allowed

...

• oneway
• if transit allowed through this way

• access restricted during certain time period
• access restricted when temperature is more than limit

• what about variable restrictions? (e.g. a school zone where you can only go 30 km/h when the traffic sign is lit up, or a motorway where the speed is given by matrix signs over the lanes.)
  • Key:conditional handles static rules that can be expressed in a tag and the result can be calculated - in contrast, a variable-message sign can't be "calculated"
  • Proposed_features/Dynamic_maxspeed covers speeds, but there are much more restrictions (entrance,overtaking,... (not) allowed)
  • See also DE_talk:Road_signs_in_Germany#Wechselverkehrszeichen
  • This can not be mapped exactly to be fully used by routing software, but it is still possible to map this as range of values with text comments describing whole situation. In this case routing software can use low value from range to calculate pessimistic time, and you will still drive by signs on road, not on the map. For example for school it is possible to make such range restriction for day-time and more simple one for night-time, as there will be no children there at night, I hope. In some cases, as shown in example below when speed limit on lanes defined by weather conditions it will be possible to make more computer-understandable restrictions, but routing software still don't know weather conditions for now. May be in future.
  • Just to allow search to find this easily, a list of names for those signs according to Wikipedia: variable-message sign (VMS), changeable-message sign (CMS), electronic-message sign, dynamic-message sign (DMS), matrix sign, and in German Wechselverkehrszeichen

• you have to pay a toll to use the road

specifically for parkings:

• maximum stay
• disc parking
• you need a resident card
• you need a card which allows you to park there
• you have to pay to park

Vehicle types

• motorcar
• bicycle
• moped
• bus
• psv
• taxi
• tram
• goods vehicles
• heavy goods vehicles
• agricultural vehicles
• emergency vehicles
• foot
• horse
• motorcycle
• ski
• snowmobile

...

We perhaps need subsets of vehicle types: psv={bus,taxi,tram}, all_vehicles, motorized_vehicles... Countries need to have freedom creating their own vehicle types or discarding some depending on their own traffic law (e.g. "hgv" as a synonym for "goods", or different moped types).

Agreed. I composed the following list based on the German list of vehicle types. Descriptions and hierarchy might be different in other countries, depending on the local law. At the moment, the DE:Key:access page (as well as Key:access) only provides a plane list, that doesn't represent the type subsets or groups that are necessary and also already in use in some way or another (access for general permission, motorcar for all multi-track vehicles). More specific rules should always override generic rules (e.g. vehicle=no, bicycle=yes naturally allows bicycles). --Driver2 12:44, 12 October 2008 (UTC)

Currently your example should be tagged as access=no, bicycle=yes! I would propose something like access=default:no;bicycle:yes. --Phobie 07:01, 28 November 2008 (UTC)

No. vehicle=no only forbids vehicles, while access=no forbids everything. --Driver2 15:10, 28 November 2008 (UTC)

We definitely need grouping, see my Proposed features/Any moving thing grouping system and also Eimai's Talk:Vehicle_types#Vehicles_as_defined_by_Belgian_law or else we will definitely be drawn under hundreds of tags, and we will also remove some "unclarity" Sletuffe 17:23, 22 November 2008 (UTC)

• access (General access, for everyone)
  • foot (Pedestrians)
  • horse
  • vehicle
    • bicycle
    • motorcycle (Motorcycle and Mopeds)
      • moped
    • motorcar (Cars and other multi-track vehicles)
      • goods (Lieferfahrzeuge bis 3.5t)
      • hgv (Heavy Goods Vehicle, LKW über 3.5t (einschließlich ihrer Anhänger und Zugmaschinen, ausgenommen Personenkraftwagen und Kraftomnibusse))
      • psv (Public Service Vehicle, Linienbusse)
      • agricultural (motorvehicles that can't go faster than 25 kph (symbol tractor))
      • emergency (Rettungsfahrzeuge)
    • motorboat (Motorboot)
    • boat (Boot)

Brainstorming

• Simple scheme (easy restrictions): more or less as we tag now but now with strict rules
• Complex scheme: relations
• The simple tags should be defined by an equivalent complex tag
• The complex scheme with relations should only be needed in a few situations, we may need to add some simple tags for common situations to make sure that relations aren't needed everywhere. (like bicycle=twoway or we'd need a relation for practically all oneway roads in a country)

What's needed in an access restriction?

• The vehicle types it applies to
• Properties of the vehicles to which the restriction applies: for example a minimum weight
• The exact place where it applies (could be only one in direction, or on a specific lane)
• Properties of environment when restriction applies
  • The time period
  • The temperature range, etc.
• An importance or precedence number that's needed to fix conflicts (the highest number wins) e.g.: in "access=no; bus=yes": both tags apply to the vehicle type "bus", but the latter rule should have more importance, so for a bus the latter applies.
• The exact restriction:
  • access=no/yes/destination/...
  • maxspeed=* or minspeed=*
  • overtaking allowed or not
  • specific parking restrictions for parkings or for parking along the road.
  • (note that restrictions like maxlength, maxweight, etc are properties of the vehicles and don't belong here)
• A "zone" tag: could define a built-up area, or could just say that it's a "zone 30"

Issues

Importance numbers

I'm getting confused on a proper importance number for the oneway=yes vs the tags like bicycle=*. Should oneway=yes be more important? Then we cannot get bicycles allowed in two directions on a road without using relations to specify a bigger importance number.

On the other hand, we could make bicycle=* more important. In that case a oneway road that allows bicycles in two directions would be: oneway=yes; bicycle=yes.

We could special case the bicycle=twoway of course, but that's ugly...

Doesn't bicycle=yes just mean that bicycles are allowed on a street? It doesn't have to do anything with oneway? --Driver2 19:43, 23 September 2008 (UTC)

Depends on how you define the tags. Right now it isn't defined so everyone's interpretation is right. --Eimai 20:09, 23 September 2008 (UTC)

I've now started using bicycle:oneway=no on a oneway street. --Eimai 20:09, 23 September 2008 (UTC)

Why not oneway:bicycle=no? The 'no' refers to the 'oneway', does it not? In that case to go conform with already used tags like name:en=* the right way would be to set 'oneway' to 'no' for the parameter 'bicycle' (the same as in setting the 'name' to something for the parameter 'en'). Unless I understand something wrong of course. I find this stuff quite complicated. --Driver2 23:06, 23 September 2008 (UTC)

I switched from oneway:bicycle=no to bicycle:oneway=no after tagging two streets with the first one: somehow it felt more natural that I was defining access rules for bicycles, that the important one should be in front. But yes, it depends on how you look at it. --Eimai 12:12, 24 September 2008 (UTC)

Concerning importance: I think the more specified rule should always override the generic ones. For example access=no restricts access for all types, but is overwritten to allow bicycles by bicycle=yes. Since maxweight=* also applies to alle types (unless we use something like maxweight:type=*), it should also be possible to override it with more specific rules, but only of the same restriction-type. For example maxweight=3.5, motorcar=yes would not allow motorcars to pass whatever weight they have, but still disallow all vehicles weighting more than 3.5 tons. To disable weight restrictions for motorcars, one would have to use maxweight:motorcar=no. Since it depends on the properties of the types whether maxweight=* applies to them, it is hard to define a fixed position in the hierarchy of types (unlike access=* that always applies to all types). --Driver2 16:30, 6 October 2008 (UTC)

Country specific rules

It's naive to think the whole world can use the same set of access rules. We need a way to let each country define specific access rules, to solve things like:

• mopeds being split up into two classes in some countries
• defining all needed vehicle types (heavy goods vehicle may be pointless in countries where there's just one class for goods vehicles)
• defining default access rules for each highway type (the definition of "trunk" in some countries doesn't allow pedestrian, bicycle or moped access, where other countries allows them)
• other (e.g. access=destination doesn't apply to bicycles in some countries)

In practice, this needs:

• a set of defaults applying to the whole world
  • set of vehicle types (and subsets)
  • access rules for each highway type for each vehicle type
  • formal definitions of the simple access tags
• country-specific (or different divisions like states where applicable) rules that override these defaults (and possibly just replaces the whole set of default rules)
  • everything that's in the default world set
  • could also include rules for maxspeed for example

Are you excluding pedestrians completely? You always talk about vehicle types. --Driver2 23:12, 23 September 2008 (UTC)

Here is my thought about country specific rules Sletuffe 18:59, 22 November 2008 (UTC)

Trying to map existing tags to the list above

access=destination

• vehicle types: all
• importance: minus infinity
• restriction: access=destination

bicycle=yes

• vehicle type: bicycle
• importance: between minus infinity and the value of oneway=yes
• "restriction": access=yes

oneway=yes

• vehicle types: all except foot
• place where it applies: in opposite direction of way
• importance: x
• restriction: access=no

maxweight=3.5 tons

• vehicle types: all
• properties of vehicles to which it applies: those weighing more than 3.5 tons
• importance: ?
• restriction: access=no

maxspeed=50

• vehicle types: all
• restriction: maxspeed=50

More complex

No entry for goods vehicles over 3.5 tons except destination traffic

• vehicle types: goods
• properties of the vehicles: over 3.5 tons
• restriction: access=destination

Only buses of company X allowed access=no plus:

• vehicle types: bus
• properties of the vehicles: operator=company X
• restriction: access=yes

A path where pedestrians and bicycles are allowed, but bicycles aren't allowed on Sunday. highway=cycleway plus:

• vehicle type: bicycle
• time period: Sunday
• restriction: access=no

Oneway road where buses can go both ways (depends on the exact definition of oneway=yes) oneway=yes plus:

• vehicle type: bus
• importance: higher than oneway=yes
• restriction: access=yes

(we could add a new restriction value access=twoway perhaps, so it becomes oneway=yes, bus=twoway)

No parking allowed for vehicles with maximum allowed weight over 3.5 tons alongside a road

• vehicle type: all
• properties of the vehicle: maximum allowed weight over 3.5 tons
• restriction: no parking

Low emission zone

• found: Germany, see Umweltzone.
• Differing concepts found in other countries, see Low emission zone
• restriction: access forbidden for motor vehicles, that do not have a permission badge in the right color.
• badges in different colors can be bought if the vehicle reaches different levels of exhaust quality, measured by an entry in the motor vehicle registration certificate (Euro I, II, III, IV norm).
• valid for:
  • areas in highly contaminated city centers, with ways that are excepted (usually motorways)
  • ways
• currently tagged (no proposal yet): Relation of type "LEZ".
• currently rendered: no
• As you can buy a special exception permission, it is a kind of toll zone.
• routing: (easiest: treat like a toll zone) user shall be asked if
  • the permission is available (go best way through the zone)
  • the permission shall be bought (navigate to the nearest bureau to buy one, check opening hours)
  • avoid zone (go around)

Maximum speed in right lane on a three lane road is 50 instead of default speed

• vehicle type: all
• place where it applies: lane 1 (let's count from outer to inner lane)
• restriction: maxspeed=50

Maximum speed in all lanes 130km/h, minimum speed in outside lane 110km/h, maximum speed in poor conditions 80km/h, maximum speed for HGVs/PSV/vehicles with trailers 100km/h

• vehicle type: varies
• place where it applies: most all, 1 the outer lane
• restriction: varies

School zone: Maximum speed 30km/h, monday to friday, 7:00 to 9:00, 11:00 to 14:00, 16:00 to 19:00 for next 200m

• vehicle type: all
• time period: monday-friday & (0700-0900|1100-1400|1600-1900)

for the time period i would use opening_hours a tag wich was intended for POIs, but voted ok to apply to ways. i think time restrictions are best aproached with the syntax of that tag as is more flexible, does not make it complex when case is not. and can solve most, if not all: month-monthday-weekday-hour-minute restrictions. If every one agrees i would use that even if some modification of the tag opening_hours is needed.--Sergionaranja 16:45, 1 July 2008 (UTC)

we can borrow the syntax indeed for a new tag in the relation scheme, and keep opening_hours tag on ways for easy situations. --Eimai 17:07, 1 July 2008 (UTC)

• place where it applies: next 200m
• restriction: maxspeed

Cycleway access allowed for cycles, other vehicles must give way to cycles and can only enter the cycleway for access to adjacent buildings vehicle type: non-cycles restriction: access only, must give way

Deriving a good syntax...

A access restriction could have these tags: (tags and syntax should be defined for each) (obviously most access relations will have very few of these tags)

• type=access

To list the vehicles to which it applies (default = all vehicles)

• vehicles=list of vehicles to which the restriction applies, seperated by ';'
• weight=+3.5tons
• weight_per_axle=+1tons
• maximum_allowed_weight=+3.5tons
• height=+3
• length=+10
• occupancy=+3
• operator=Some bus company
• all kinds of types of dangerous (poisonous/explosive) goods

What is maximum_allowed_weight=+3.5tons supposed to mean? It sounds more like a restriction, than a property of a vehicle. Wouldn't it be better to either have maxweight=* and minweight=* (could confuse people since they are also shortcuts for restrictions) or weight=* with ">" and "<" or "+" and "-" to define wheather the vehicle weighs more or less than the given value (maybe that's what you meant by "+"?). weight=* is probably easier to understand. The same could be used for height, length and weight per axle (as already in the list, if it was meant that way). --Driver2 13:07, 12 October 2008 (UTC)

As I wrote it there it'd mean that the access restriction (say for example: no access except for loading and unloading) only applies to vehicles that have a maximum allowed weight over 3.5 tons (note that it's a different concept than the weight tag above). I agree the syntax is confusing with other tags like maxweight, but in at least Belgian traffic rules some weight restrictions (no access over 3.5 tons) apply to vehicles that have a total weight over 3.5 tons at that specific time, while others (no parking over 3.5 tons) apply to how much the vehicle is allowed to weigh (i.e. the weight it would have on full load). I couldn't find a better wording for the latter than "maximum allowed weight" (which is a direct translation of how it's described in Belgian traffic law). --Eimai 13:32, 12 October 2008 (UTC)

Now that you say it, I think we have a similiar rule in Germany, here it's called "maximales zulässiges Gesamtgewicht" (your maximum allowed weight) and "tatsächliches Gewicht". maximum_allowed_weight=+3.5tons is usually represented by hgv=* here. So if I understand it correctly, you did mean "3.5 tons and above" by using "+"? --Driver2 13:56, 12 October 2008 (UTC)

Yes, the "+" meant "anything above", could be a ">" perhaps. As said, I don't find the syntax for it optimal but I don't know an easy solution. Representing it with "hgv" isn't exactly an option since the maximum weight can vary a lot. --Eimai 15:49, 12 October 2008 (UTC)

The restriction:

• access=yes/no/destination
• maxspeed=90
• minspeed=70
• overtaking=yes/no
• cruisecontrol=yes/no
• different parking restrictions
• restriction to pay toll?
• something with variable restrictions?

The exact lane(s) or direction where it applies: (default: everywhere on the piece of road with this relation)

• lanes=1;2
• direction=forward/backward/both

The period when it applies: (default: all the time)

• time=syntax as defined by Key:opening_hours
• mintemperature=-5°C
• maxtemperature=30°C

Importance of this rule (to override rules of lower importance) (default would be 0)

• precedence=5

Group restrictions

Unless I've missed it up above (which is quite possible), access restrictions need to be grouped. I have two suggestions on how to do it. These are done using an XML syntax.

1. Nesting

<access=yes>

<restrictions appear here&lt

</access>

<access=no>

<restrictions appear here&lt

</access>

1. Numbered

access=bicycle,foot

access_1=no

date_on_1=****-04-01

date_off_1=***-09-01

note_1=No motorized traffic 1 Apr - 1 Sep

The advantage of the first one is that it doesn't require numbering, but it is unconventional and would require redesigning some of the editors. The second one would require more work by the editors (but that's what we're doing anyway), but would not require redesigning. Either way, as soon as there is a restrictive access tag, it is assumed that anything not listed in any of the access tags is not allowed. If the other things are allowed, then some sort of date_on/off is used. I maybe the "access_1=no" should be "access_1=yes" What do you think? — Val42 17:57, 27 September 2008 (UTC)

One of the possible solutions to group access-restrictions was to use relations. Relations have the advantage of properly seperating the restriction group and the rest of the tags. They also make it possible to add several ways to one access-restriction, instead of adding the tags to every way separately. --Driver2 19:10, 27 September 2008 (UTC)

Roads closed in winter

In French mountains, there are roads that are closed in winter, but at dates that depend on the weather. Basically, once it snows too much the authorities stop ploughing the road.

Proposed:

access:winter=no

Maybe we should have indications of the closure dates to be expected? This should prevent, for instance, routing a car through a pass that's always closed in January. How about expected_winter_start=... and expected_winter_end=... ?

Some of these roads are converted into ski tracks during the winter. Proposal:

ski:winter=permissive

Submarine 12:44, 19 January 2011 (UTC)

See Key:winter_road

The same in Norway. Most minor roads are "winter closed", which is marked with a little line across the road on printed maps. Nobody bothers about exact dates; it's nature that decides. I wonder why there isn't such a tag on OSM. On the other hand I understand that a routing system could not easily handle something like "winter", but would need at least a "default winter season" like Dec-May for Norway. --GerdHH (talk) 15:12, 22 October 2014 (UTC)