Proposal:Access restrictions 1.5

From OpenStreetMap Wiki
Jump to navigation Jump to search
Information
 Alternate Proposals
A number of alternate solutions have been proposed. For a full list see Proposed_features/Advanced_access_tags. Update Oct-2012: The Conditional Restrictions proposal was approved by a majority vote.
access restrictions 1.5
Proposal status: Abandoned (inactive)
Proposed by: flaimo
Tagging: access=*
Applies to: node, way, area, relation
Definition: Refinement and structured refactoring of the current access tags and modifiers
Statistics:

Rendered as: *
Draft started: 2011-03-17 (as a comment)
RFC start: 2011-04-26

Foreword

This is my take on the access problematic. It was originally posted as an comment for another access proposal, but since it is rather detailed and long, I decided to give it its own page, so it wouldn't overload the comments page. It is not meant as an competing proposal (at leased not for now), where in the end, you have to choose this one or the other. Ideas found here could easily be incorporated in one of the other proposals.

Outline

Of course you will never be able to handle all the access restrictions in the world. The goal should be to bring some structure and naming conventions to the current access tags and values and handle special cases a bit better than right now. That's why it has the version number 1.5 and not 2.0. Changes in short:

  • Clean separation between the kind of transportation (vehicle), user roles and access values. Currently they are all thrown into one pot, which leads to an inconsistent mapping scheme.
  • Every access related key now starts with "access". Better for quickly finding access related tags and also allows evaluation of the new access tags without worrying about backwards compatibility.
  • No more special cases for wheelchairs. all access values can be applied. "limited" has become a modifier which can be used for all kinds of transportation.
  • The keys in this proposal in fact do get longer and probably for some more difficult to read. There is no way around it, if you want to map more complicated access situation than with the current scheme.

Namespace

Every key/value entry starts with access=*. In case a transportation mode or role is defined (see chapter below), the separator ":" is appended to "access". Therefore it functions as a namespace prefix.

In situations where there is only one element that tags can be applied to, but different kind of access targets need to be represented, the access namespace can be replaced by a custom value. The primary reason for that is, so that access restrictions for a road can coexists with access restrictions for parking lanes on the side of the street, where information for both needs to be tagged on one single way element.

Example: Access tags for the road itself:

Access tags for the parking lanes tagged on the same road:

Further explanation of the terms used in this keys can be found below in the following chapters.

Keys

"access" would basically function as the super node. Under it are two level-one categories: "kind of transportation" (mode) and "special interest group" (role). While the kind of transportation is exclusive (you can't drive a car and walk at the same time), the person affected by restrictions can have multiple roles and therefore be part of different special interest groups at the same time. For example a disabled person can also be a customer at the time of evaluation. Under the mode and role branches the key hierarchy is build, which would result in these keys for example:

Shortcuts

Of course this keys can become very long, that's why you can take the super node/namespace "access" and the last level of a key and combine it to a shortcut key: example:

Shortcut keys should always be used as long as they don't conflict within the whole access tree. The important part is, that there's an "access" at the very beginning of the key. This way the purpose of the key is exactly clear. Right now its a big mixture. Mappers who are not experienced probably don't know what the key hgv=* means, but with access:lgv=* they would know instantly that it has something to do with access restrictions.

Another benefit would be, that all restrictions for a certain kind of transportation or special interest group are grouped together when sorted alphabetically in tag editors.

List of keys

Icon Fully qualified Key Shortcut Key Description
access main access key without a subkey
access: mode mode kind of transportation
access: mode:land land all kind of transportation used on land
Sinnbild Fußgänger.svg
 access: mode:land:foot foot
access: mode:land:foot:ice_skates ice_skates Wikipedia
access: mode:land:foot:inline_skates inline_skates Wikipedia
access: mode:land:foot:ski ski different sports are now a role Wikipedia
access: mode:land:foot:kickscooter kickscooter Wikipedia
access: mode:land:foot:wheelchair wheelchair yeah, i put it under foot because it's placement under vehicle right now is just absurd Wikipedia
access: mode:land:vehicle vehicle more precisely: vehicles for land based transportation, but without trains
access: mode:land:vehicle:non_motorized non_motorized
access: mode:land:vehicle:non_motorized:single_tracked single_tracked
Sinnbild Radfahrer.svg
 access: mode:land:vehicle:non_motorized:single_tracked:bicycle bicycle Wikipedia
access: mode:land:vehicle:non_motorized:single_tracked:bicycle:mountainbike mountainbike Wikipedia
access: mode:land:vehicle:non_motorized:single_tracked:bicycle:racingbike racingbike Wikipedia
access: mode:land:vehicle:non_motorized:single_tracked:bicycle:cargobike cargobike Wikipedia
access: mode:land:vehicle:non_motorized:double_tracked double_tracked
access: mode:land:vehicle:non_motorized:double_tracked:carriage carriage
access: mode:land:vehicle:motorized motorized
access: mode:land:vehicle:motorized:single_tracked single_tracked
Sinnbild Kraftrad.svg
 access: mode:land:vehicle:motorized:single_tracked:motorcycle motorcycle Wikipedia
access: mode:land:vehicle:motorized:single_tracked:motorcycle:motorscooter motorscooter a motorcycle with step-through frame. can be powerful enough to be driven on highways Wikipedia
access: mode:land:vehicle:motorized:single_tracked:motorcycle:motorscooter:moped moped max speed of 45km/h in some countries. normally not allowed on highways Wikipedia
Sinnbild Kfz.svg
 access: mode:land:vehicle:motorized:double_tracked double_tracked
access: mode:land:vehicle:motorized:double_tracked:atv atv An all-terrain vehicle (ATV), also known as a quad, quad bike Wikipedia
access: mode:land:vehicle:motorized:double_tracked:golf_cart golf_cart Wikipedia
Sinnbild PKW.svg
 access: mode:land:vehicle:motorized:double_tracked:car car previously "motorcar". Wikipedia
Sinnbild Traktor.svg
 access: mode:land:vehicle:motorized:double_tracked:tractor tractor Wikipedia
access: mode:land:vehicle:motorized:double_tracked:goods goods do we need this in this proposal? isn't this covered by the role:commercial branch?
Sinnbild LKW.svg
 access: mode:land:vehicle:motorized:double_tracked:lgv lgv = large goods vehicle, formally hgv (heavy goods vehicle) Wikipedia
Sinnbild Kraftomnibus.svg
 access: mode:land:vehicle:motorized:double_tracked:bus bus separation by physical properties, not what they are used for Wikipedia
access: mode:land:vehicle:motorized:double_tracked:bus:pt_bus pt_bus = public transport bus. limited range and speed, entrances at the level of sidewalks.
access: mode:land:vehicle:motorized:double_tracked:bus:trolleybus trolleybus electric local public transport bus, powered through overhead wires Wikipedia
access: mode:land:vehicle:motorized:special special
access: mode:land:vehicle:motorized:special:snowmobile snowmobile Wikipedia
access: mode:land:rail rail
access: mode:land:rail:tram tram Wikipedia
access: mode:land:rail:train train Wikipedia
access: mode:land:animal animal
Sinnbild Reiter.svg
 access: mode:land:animal:horse horse
access: mode:land:animal:camel camel
access: mode:land:animal:elephant elephant
access: mode:water water
access: mode:water:boat boat
access: mode:water:boat:motorboat motorboat
access: mode:water:boat:sailboat sailboat
access: mode:water:boat:canoe canoe
access: mode:water:fishing_vessel fishing_vessel
access: mode:water:ship ship
access: mode:water:ship:passenger passenger
access: mode:water:ship:isps isps
access: mode:water:ship:cargo cargo
access: mode:air air
access: mode:air:helicopter helicopter
access: mode:air:plane plane
access: mode:air:plane:unpowered unpowered
access: mode:air:plane:unpowered:glider glider
access: mode:air:plane:unpowered:hang_glider hang_glider
access: mode:air:plane:unpowered:paraglider paraglider
access: mode:air:plane:powered powered
access: mode:air:plane:powered:propeller propeller probably needs subkeys for different kind (sizes) of planes
access: mode:air:plane:powered:jet jet probably needs subkeys for different kind (sizes) of planes
access: role role Special interest group. When in doubt, user roles should be notated singular.
access: role:emergency emergency
access: role:emergency:police police
access: role:emergency:fire_department fire_department
access: role:emergency:ambulance ambulance
access: role:emergency:technical_aid technical_aid for example THW in germany
access: role:commercial commercial
access: role:commercial:customer customer
access: role:commercial:visitor visitor
access: role:commercial:operator operator
access: role:commercial:caretaker caretaker for example the maintenance company for roads or the janitor of a house. can sometimes, but doesn't necessarily has to be, the operator. I choose "caretaker" since it is easier to write for non native speakers than "maintenance".
access: role:commercial:employee employee
access: role:commercial:student employee
access: role:commercial:member member
access: role:commercial:resident resident
access: role:commercial:guard guard
access: role:commercial:military military
access: role:commercial:agricultural agricultural
access: role:commercial:forestry forestry
access: role:commercial:delivery delivery
access: role:commercial:delivery:hazmat hazmat
access: role:commercial:delivery:chemicals chemicals
access: role:commercial:delivery:gas gas
access: role:commercial:delivery:oil oil
access: role:commercial:transport transport
access: role:commercial:transport:taxi taxi
access: role:commercial:transport:school school
access: role:commercial:transport:tourist tourist
access: role:commercial:transport:public_transport public_transport
access: role:commercial:transport:aid aid transport of elderly, ill, disabled people; not emergency cases
access: role:sports sports
access: role:sports:skiing skiing
access: role:sports:skiing:nordic nordic
access: role:sports:skiing:alpine alpine
access: role:sports:skiing:telemark telemark
access: role:sports:running running
access: role:sports:swimming swimming
Sinnbild Wanderer.svg
 access: role:sports:hiking hiking
access: role:disabled disabled
access: role:disabled:walking_impaired walking_impaired
access: role:disabled:visually_impaired visually_impaired (blind)
access: role:disabled:hearing_impaired hearing_impaired (deaf)
access: role:gender gender
access: role:gender:male male
access: role:gender:female female
access: role:social social can vary from country to country. Someone may be a minor until 18 in one state, but 21 in another. It is up to routing programs to interpret those correctly
access: role:social:minor minor
access: role:social:adult adult
access: role:social:senior senior
access: role:social:parent parent
access: role:social:pregnant pregnant Usage example
access: role:language language locale
access: role:language:en en english speaking person
access: role:language:en_us en_us us english speaking person
access: role:language:en_au en_au
access: role:language:de de
access: role:language:de_de de_de
access: role:language:de_at de_at
access: role:language:<language or locale> <language or locale>
access: role:country country ISO 3166-1 alpha-3
access: role:country:USA USA united states citizen
access: role:country:GER GER german citizen
access: role:country:IND IND
access: role:country:<country code> <country code>

Properties and trailers

Since a lot of the vehicles described in the list above can have different kind of engines or other properties it wouldn't be feasible to create a sub entry in the list for each one of them. That is why you can append them to the main access key (from the mode branch) separated by a plus sign. Examples:

The same situation as for properties also applies to trailers. Examples:

Properties and trailers can also be combined. Example:

Possible values

Properties

  • manual
  • electric
  • hybrid
  • combustion
  • 4wd (Four-wheel drive)
  • single_hull (cargo ships)
  • double_hull
  • <suggest more values in the comments>

Trailers

  • trailer (general)
  • trailer_1_axle (general)
  • trailer_2_axle (general)
  • trailer_3_axle (general)
  • travel trailer (caravan)
  • livestock_trailer (horses for example)
  • boat_trailer
  • motorcycle_trailer
  • sidecar
  • rickshaw
  • <suggest more values in the comments>

Modifiers

Modifiers are appended after the main access key (fully qualified or shortcut key) or after a condition, if one exists. A period (".") is used as a separator instead of ":" to better distinguish between the actual keys, and modifiers. Examples:

Value Defaut value Default unit Comment Examples
usage <string> (see list below) depends on the default values for the way/element This modifier is described below in its own sub chapter
speed <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element km/h If only one value is given it is interpreted as maxspeed. Use <integer>+ to define minspeed. access.speed=100, access.speed=30mph-60mph.
length <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element m If only one value is given it is interpreted as maxlength. Use <integer>+ to define minlength. access.length=1-5, access.length=375cm.
width <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element m If only one value is given it is interpreted as maxwidth. Use <integer>+ to define minwidth. access.width=3ft-10ft, access.width=7.
height <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element m If only one value is given it is interpreted as maxheight. Use <integer>+ to define minheight. access.height=0-5, access.height=500cm.
depth <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element m If only one value is given it is interpreted as maxdepth. Use <integer>+ to define mindepth. Mainly used for waterways access.depth=60-120, access.depth=550cm.
weight <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element t If only one value is given it is interpreted as maxweight. Use <integer>+ to define minweight. access.weight=3.5-5, access.weight=3500kg+.
axle_load <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element t If only one value is given it is interpreted as maxaxleload. Use <integer>+ to define min_axle_load. Definition of axle load access.axle_load=2.5, access.axle_load=1.5-2.
draught <min_integer>-<max_integer>;<min_integer>-<max_integer>;… depends on the default values for the way/element m If only one value is given it is interpreted as maxdraught. Use <integer>+ to define mindraught. access.draught=5.
stay <min_integer>-<max_integer>;<min_integer>-<max_integer>;… no restriction min If only one value is given it is interpreted as maxstay. Use <integer>+ to define minstay. access.stay=0-60, access.stay=24h.
age <min_integer>-<max_integer>;<min_integer>-<max_integer>;… no restriction years If only one value is given it is interpreted as minage. access.age=0-6;10-16, access.age=18.
occupants <min_integer>-<max_integer>;<min_integer>-<max_integer>;… no restriction persons If only one value is given it is interpreted as maxoccupants. Use <integer>+ to define minoccupants. for highly occupied vehicle (hov) rules. access.occupants=3+, access.occupants=4-6
time <opening_hours syntax> 24/7 "time" is a more neutral name than "opening_hours", since it actually can also be used to define the "closed_hours" (see chapter about conditions below). If directly applied to an access key it is interpreted as opening hours.
direction backward/both/forward or up/down or clockwise/counterclockwise or north/east/south/west both previously oneway; depending on the element, could also have different values (see separate proposal). Please note, that direction=* in combination with the access namespace describes an access restriction while the direction=* key for itself (without a namespace) should be used to describe the physical orientation of an element.
fee yes/no no whether there is a fee to pay to access or not.
limited yes/no no while it may be officially be possible for a certain mode or role to use a way, there are some physical limitations. please note, that limited is not a value anymore but rather a modifier, so it's use it not just bound to wheelchair specific tags. should always be used in combination with a description.
avoid yes/no no while it may be officially be possible for a certain mode or role to use a way, there are (non physical) reasons why not to use it. for example high criminality in an certain area. should always be used in combination with a description.
identifier <string> none certain identifiers like license plates or stickers. If you want to do a check for "begins with" use "<string>*", for "ends with" use *<string>" and for "contains" use "*<string>*"
description <string> none additional information for certain restrictions, that can't be described by access keys alone.
source <string> legal/physical/<string> Can be used to further describe the source of a restriction, for example the traffic sign the rules are based on.

The modifier "usage"

The modifier "usage" is a bit of a special case. It describes the access restriction in general. Under the old scheme it was directly applied as a value to the access key. In this new scheme it is one of many modifiers. To make things shorter and to remain backward compatible with the generic access key, the ".usage" can be left out.

Values

The values are basically the same as used for the current access restriction:

Value Comment
compulsory "You have to use it, even if there are alternatives"
The element is dedicated to a specific transportation mode or role. If forced by law, it is usually marked by signs and compulsory. "compulsory" is more clear than "official". It doesn't matter if you are forced by law or by a guy with a gun.
designated "You should use it"
The element is a preferred/designated route for a specific transportation mode or role (by law or otherwise) but not compulsory. In traffic situations often marked by a traffic sign
yes "You can use it"
The public has an official, legally-enshrined right of access, i.e. it's a right of way.
permissive "You are allowed to use it"
The owner gives general permission for access.
destination "You are allowed to use it, if there is no alternative"
The public has right of access, only if this is the only element to your destination. Probably can be dropped, because it could be tagged as access:role=no + access:resident=designated + access:visitor=yes.
private "You are allowed to use it if the owner permits it"
The owner may give permission on an individual basis.
unknown "You shouldn't use it"
The access conditions are unknown or unclear. This is the default value for most features.
no "You cannot use it"
Access is not permitted, public does not have a right of way. Also used if it is physically not possible for certain transportation modes to use an element.

Conditions

Modes-and-roles.png

With access tags and modifiers appended, most situations are covered. It would basically be a structured version of the current scheme. For special situations there would be "conditions". The separator for a condition is the "?" sign (as a synonym for "if") and appended after the key, but before the modifier. After the separator you write down the special situation that needs to be taken care of as a term/keyword. examples:

Conditions take care of the following situations:

Environment based conditions

Environment based conditions are self-explanatory and depend on external factors at the time of evaluation.

  • fog
  • wet
  • snow
  • ice
  • foliage
  • high_emissions
  • <suggest more values in the comments>

Time based conditions

The conditions listed here are basically placeholders for fixed values, which can vary from country to country or from season to season. Daylight saving time may start in march in some countries, while in others it can be april. It is up to routing programs to interpret those correctly.

  • spring
  • summer
  • autumn (fall)
  • winter
  • dst (Daylight saving time)
  • sunrise
  • sunset
  • sunrise_sunset
  • sunset_sunrise
  • dusk
  • dawn
  • dusk_dawn (the time between dusk and dawn; not the same as sunset/sunrise)
  • dawn_dusk (the time between dawn and dusk; not the same as sunset/sunrise)
  • full_moon (the night where a full moon occurs)
  • new_moon (the night where a new moon occurs)
  • full_moon_new_moon (the time between full and new moon)
  • new_moon_full_moon (the time between new and full moon)
  • high_tide (the time where a high tide occurs)
  • low_tide (the time where a low tide occurs)
  • high_tide_low_tide (the time between high and low tide)
  • low_tide_high_tide (the time between low and high tide)
  • workday
  • schoolday
  • weekend
  • holiday
    • new_year_day_gregorian
    • new_year_day_lunar
    • …other official holidays…
  • <suggest more values in the comments>

Law based conditions

While a lot of access restrictions can be described with the modes and roles of this proposal, there are often special conditions in certain countries which are very complicated and are often describable through one (local) term.

For example in Finland the law for "huoltoajo sallittu" ("service traffic allowed") includes the following rules, some of which can not be described with access restrictions:

  1. Any "unavoidable" traffic for guarding of, or for the maintenance of the properties
  2. Any traffic to transport a person with limited mobility or limited sense of direction - due to age, impairment, illness or other reason
  3. Any traffic when each passenger of legal age has to supervise more than one child under 7 years old
  4. Any vehicle driven by a physically disabled person (likely would need a formal recognition as such)
  5. Any delivery traffic, or transporting other goods that one can't "reasonably be expected to carry on foot"
  6. Any taxi to pick up or deliver passengers

In such a case a dedicated condition can be used:

Such conditions should only be used as a last resort if the rules can't be described otherwise. To avoid mix ups, the 2 letter abbreviation of the country plus an underscore is added to the term as a prefix. Law based conditions need to go through a proposal stage to assure they are precisely defined and documented.

Self defined conditions

There will be situations where the predefined conditions won't be enough. That is why you can also define your own. To define a condition use "!" instead of "?" and append the modifier, which should act as a condition, plus a value. Please note, that the access key itself plays an important role here too. If a definition is created on the general access key, it is valid for the whole access tree. If defined on access:vehicle=* like in one of the examples below, the custom definition for would only apply for that branch.

Example for a time based condition:

You can also override predefined time based conditions listed above:

Another example where the weight modifier is used to define a condition:

When defining a condition with a modifier, this modifier can't be used again in access entries which evaluate for that condition. The following example would be wrong:

Evaluation

At time of evaluation each key/value pair is processed to see if it matches.

Mode keys

Transportation mode keys are always evaluated before role keys. In case more than one key matches, the most specific one is used. Especially mode+role key combinations outweight rules with just a mode key. In case there is more than one entry with the same key but one has an condition attached to it (that applies), this one is used.

The following example uses fully qualified keys for demonstration purposes:

Since transportation modes are mutually exclusive it would be interpreted as

For someone driving a car, the last line would be the most specific one, and therefor be evaluated for modifier values.

Role keys

Roles are not are mutually exclusive, therefore all role keys, that match at the time of evaluation, are added up and the most restrictive one is used. Role keys are always evaluated after mode keys, so if access is denied because of a mode key, role keys don't apply even if the would grand access. On the other hand values for role keys could still prohibit access, even if the access is allowed for a transport mode.

Example for customer and employee parking spaces that are not suited for disabled persons

In case of a disabled customer the following lines would apply

Since the disabled key is more restrictive, it gets applied.

Mixture of modes and roles

Even when no explicit role or mode is set, every user has the abstract role "access:role" and uses the abstract transportation mode "access:mode", which inherit from the main access key. You would normally define a strict access value for the main access key (and thereby to all sub keys) and then define the exceptions to the rule by adding specific lines for certain targets. The matching transportation mode and the strictest value from all matching roles are added up and the stricter value counts.

A private parking space for motorcars of residents could be defined like this:

Even if you ride a car, but you are not a resident, the abstract role "access:role" would be evaluated and since it inherited the value "no" from the generic access key, you are not allowed to park.

Rules for specific mode/role combinations

Sometimes there are restriction, where the access value for a role depends on the transportation mode or a user needs to have more than one role at the time of evaluation (for example customer AND disabled). Those are normally corner cases and shouldn't occur that often. In such cases you can tie access keys together using "&&".

Example: Customers who drive cars or delivery services who drive goods vehicles are allowed to access a private property in general, but if a customer wants to access with a goods vehicle, he needs an explicit permission of the owner first.

Two keys combined with "&&" are more specific and override any of the other keys if they are tagged for themselves. If even this notation doesn't work for your situation, consider writing a mini proposal for a new law based condition.

Conflicting conditions

In case there are two or more access entries with conditions, which both weight the same, and their definitions overlap at the time of evaluation (for example time periods for self defined time based conditions), the more strict value is chosen.

Default access restriction values

The following are suggestions for general default access values for certain elements. Depending on the situation, these can be redefined for each country separately. Please note, that those are just for demonstration purposes and are not part of the proposal, since chances, that everybody agrees on all default values, is basically zero. Those defaults could be discussed after there is agreement on the access keys.

Highways

The following table is basically identical to the one found under Access-Restrictions extended for all highways, modes and roles. Please post suggestions for improvements to the comments.

Access proposal restrictions for highways.png

Train

todo

Water

todo

Air

todo

Other elements

Parking / parking spaces

Since the majority of parking lots are designed for motorcars the following default values could be assumed for amenity=parking, amenity=parking_space, amenity=parking_entrance and relations with site=parking (in case there aren't any access tags on the element itself):

  • access=no (disable access for the whole access branch)
  • access:car=designated (explicitly allow again for cars…)
  • access:motorcycle=yes (… and motorcycles can park there too, even if the single spaces are layed out for cars)
  • access:role=yes (all roles allowed; no restrictions)

Renderers and routing programs can interpret those default values as public parking spaces available to everyone.

Example: If you want to map a parking space only for tourist or school buses you would use the following access tags to override the default values stated above:

Example 2: A parking space explicitly for disabled customers. The parking lot for customers itself would be tagged with:

The actual parking space for disabled customers would be tagged like this:

More examples

All parts of an access entry combined

Access proposal key.png

Traffic related

delivery access for vehicles over 3.5 t only between 6:00 and 10:00

Heavy goods vehicles can go 100, but on weekends only 80 and on certain school days only 50

parking space for customers with motorcars which is suitable for disabled people, but not exclusively for them. Also the space is very narrow

parking space only for customers with motorcars who are also disabled.

people can walk on a street, but since there is a high amount of traffic it is not recommended

a oneway streets is accessible in one direction in the morning, and the other direction in the evening

a street that is accessable in general in one direction, but only for destination traffic in the other direction

a way is officially usable for heavy goods vehicle, but due to parked cars could be problematic to access

access for bicycles is not allowed during times of delivery of goods, accept if they are cargobikes with a trailer and deliver something themselves

a street becomes a HOV way at certain times, where a minimum of 3 people have to be transported, accept if you are the operator, an emergency vehicle or your vehicle is all electric.

Zone a Traffico Limitato (ZTL)

A residential road also accessible by foot or bicycle. Parking along the road is only permitted on the right side if you are a resident and have a "S7" parking permission (custom namespace for parking lanes)

Other elements

Toilets/Restrooms

Future tags

To avoid uncontrolled growth each new access key, modifier or predefined condition, that someone wants to add, has to go through a mini proposal in the comments section later on with a minimum RFC time period of 4 weeks.

Editors

Editors could provide a GUI especially for access restriction and therefor add an abstraction layer between the user and the raw tag list. It is already done for certain other tags with a complicated syntax (for example opening_hours) and therefore would make sense for access restrictions too.

See also

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Access_restrictions_1.5&oldid=2511551"