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:

• access:mode:vehicle:single_tracked:bicycle=* → access:bicycle=*
• access:role:handicapped:disabled=* → access:disabled=*

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

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:

• access:bicycle+electric=*
• access:wheelchair+manual=*
• access:car+4wd=*

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

• access:car+caravan=*
• access:motorcycle+sidecar=*
• access:foot+rickshaw=*

Properties and trailers can also be combined. Example:

• access:car+electric+travel trailer=*

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.

• Old (current) scheme: bicycle=permissive
• Proposal (fully qualified key): access:mode:vehicle:non_motorized:single_tracked:bicycle.usage=permissive
• Proposal (shortcut): access:bicycle=permissive

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:

• access=no
• access:foot=yes
• access?fi_huoltoajo=yes

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:

• access:vehicle=yes (vehicles in general can pass at 50 km/h)
• access:vehicle.maxspeed=50
• access!school_zone.time=Mo,Tu,We,Fr 07:00-10:00,15:00-17:00 (defines the time period for a school zone)
• access:lgv?school_zone=no (large goods vehicle are not allowed during that time)
• access:vehicle?school_zone.maxspeed=30 (all other vehicles can go 30 km/h max at that time)

You can also override predefined time based conditions listed above:

• access:vehicle!schoolday.time=Mo-Fr 07:45-16:00
• access:vehicle?schoolday=no

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

• access!super_heavy_vehicle.weight=12+ (define what super heavy vehicles are)
• access:vehicle=yes (all vehicles can use the way)
• access:vehicle?super_heavy_vehicle=private (…except if you are a super heavy vehicle, then you have to get the permission of the owner first)

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:

• access!high_vehicle.height=2.8+ (define what high vehicle is)
• access:vehicle?high_vehicle.height=3.0 (this height restriction won't work since you already used the modifier in the definition of the condition)

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.

• access:<key>:<subkey>+<property/trailer>?condition=* weights more than
• access:<key>:<subkey>+<property/trailer>=* weights more than
• access:<key>:<subkey>=* weights more than
• access:<key>=* weights more than
• access=*

The following example uses fully qualified keys for demonstration purposes:

• access:mode:vehicle=no
• access:mode:vehicle:motorized:double_tracked=yes
• access:mode:vehicle:motorized:double_tracked:car=no

Since transportation modes are mutually exclusive it would be interpreted as

• access:mode:vehicle=no
• OR
• access:mode:vehicle:motorized:double_tracked=yes
• OR
• access:mode:vehicle:motorized:double_tracked:car=no

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

• access:role:handicapped:disabled=no
• access:role:commercial:customer=permissive
• access:role:commercial:employee=designated

In case of a disabled customer the following lines would apply

• access:role:handicapped:disabled=no
• AND
• access:role:commercial:customer=permissive

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:

• amenity=parking
• access=no (first disable access for all modes and roles)
• access:car=permissive (allow again for the transportation mode…)
• access:resident=permissive (…and the role)

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.

• access=no
• access:car=permissive
• access:goods=permissive
• access:customer=permissive
• access:delivery=permissive
• access:goods&&customer=private

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.

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.

Train

todo

Water

todo

Air

todo

Other elements

Traffic related

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

• access=no
• access:lgv=permissive
• access:delivery=permissive
• access:delivery.time=Mo-So 06:00-10:00

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

• access:lgv!weekend_zone.time=Sa-So (defines what the condition "weekend_zone" even means)
• access:lgv!school_zone.time=Mo,We 08:00-18:00 (defines what the condition "school_zone" even means)
• access:lgv.maxspeed=100
• access:lgv?weekend_zone.maxspeed=80
• access:lgv?school_zone.maxspeed=50

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

• access=no
• access:car=permissive
• access:customer=permissive
• access:disabled=permissive
• access:disabled.limited=yes
• access:disabled.description:en=parking space is very narrow. might not be accessible to all wheelchair users

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

• access=no
• access:car=permissive
• access:customer&&disabled=permissive

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

• access:foot=yes
• access:foot.avoid=yes
• access:foot.description=high amount of traffic. not recommended to walk here.

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

• access!evening.time=Mo-Su 12:00-20:00 (defines what the condition "evening" even means)
• access.direction=forward
• access?evening.direction=backward

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

• access.usage=yes
• access!destination_direction.direction=backward
• access?destination_direction.usage=destination

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

• access:lgv.usage=yes
• access:lgv.limited=yes
• access:lgv.description=Probably not accessible due to parked cars

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

• access:bicycle!delivery_time.time=Mo-Fr 10:00-18:00
• access:bicycle=yes
• access:bicycle?delivery_time=no
• access:cargobike+trailer?delivery_time=yes

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.

• access!hov_time.time=Mo-Fr 16:00-19:00
• access?hov_time.occupants=3+
• access:emergency?hov_time.occupants=1+
• access:operator?hov_time.occupants=1+
• access:motorized+electric?hov_time.occupants=1+

Zone a Traffico Limitato (ZTL)

• access!ZTL.time=Mo-Th 06:30-18:00; Fr 06:30-18:00,23:00-24:00; Sa 00:00-03:00,14:00-18:00,23:00-24:00; Su 00:00-03:00
• access=yes
• access?ZTL=no
• access:car?ZTL=private
• access:motorcycle?ZTL=yes
• access:moped?ZTL=yes
• access:foot?ZTL=yes
• access:taxi?ZTL=yes
• access:public_transport?ZTL=yes

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)

• access=destination
• access:role=yes
• access:foot=yes
• access:bicycle=yes
• access_parkinglane_both:role=no (disallow parking along the road in general for all user roles)
• access_parkinglane_right:resident=yes (explicitly allow again for residents on the right side)
• access_parkinglane_right:resident.identifier=S7 (and only if they have a "S7" parking permission)

Other elements

Toilets/Restrooms

• access:woman=designated
• access:man=no