Proposed features/Legal access restriction
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.
|Legal access restrictions|
Version of the rfc ;-)
this is version 1.0
I will archive talk page based on this version when we move to version 2.0
Provide a more easy and extensible schema to tag legal access restrictions of any thing, at any time, to anything with any properties. (yeah sounds hard !)
PS: you don't see a reason to change ? ok... how do you tag a way that is oneway for anything, two ways for buses and forbiden to buses over 18m ?
This work is strongly based on Proposed features/access: name space and Proposed features/Access restrictions Many ideas are stolen from there. Anyway I am recreating a proposal to somehow clean things and provide a less "virtual" proposal than the 2nd and without distroying the 1st.
- Keep existing compatibility (ouch !)
- Managed with a new? "any moving thing" grouping system
- use ":" separator in the key name
give it a first try without relations (very hard!)Impossible in the case of a "OR"
First you need to understand the Proposed features/Any moving thing grouping system as it will be used to group some moving things we are interested in
The tag format is as follow, based on the Proposed features/Access restrictions :
- moving_thing_or_groupe : restriction = value
- moving_thing_or_groupe can be one of Any moving thing grouping system
- restriction can be one of Routing or time or statutory
- value can be the established : yes / designated / destination / permissive / private / no Description here
OR a number describing the propertie restriction
Until now, examples are much better than an impossible table
Simple, already covered by key:access
1) A route that has no restrictions at all
- access=yes (or nothing)
2) A motorway that is forbiden to "pedestrians" and to "bicyles" only
3) A road oneway to any vehicules but pedestrians, wheelchair, etc.
Ok, compatibility is kept, we are already doing it, this way. In 2, nothing is completly clear about "wheelchair" (someone has to asume wheelchair is included in foot) and for "moutain bikes" (someone has to asume mtb is included in bicycles )
3 is unclear too, are pedestrians, allowed in the other way ? We have to asume that yes.
More complex, using a grouping system
A route allowed only to humans on foot, wheelchair, skateboard, rollers and kids bicycles but nothing else
The same, but very specificly, kids are not allowed
Using restrictions based on simple numbered properties, not class of objects
A route allowed to any vehicles but not with weight over 5 tons
- (might or might not be an option : vehicles=yes )
Separate speed limits for heavy goods (max 55 km/h) and any other transport ( 65 km/h)
examples of not uniform oneways =
A road which is one-way to cars only, two-way for any type of bicycles and any pedestrian group, forbiden to the rest.
From here comes the problems
How to differanciate AND conditions from OR conditions Please don't read further, it's a work in progress
With multiple OR restrictions
a road that is allowed to any thing, but heavy goods over 10 tons or over 20m and forbiden to people on foot under 18 years old
Here no problems for AND between different "class"
With multiple AND restrictions
a road that is allowed to any thing, but heavy goods over 10 tons and over 20m
Combination of AND and OR
I don't care
Discussion on this schema is welcome in the talk page BUT general discussion about problem we face regarding legal access should be discussed here Proposed_features/Access restrictions