Proposal talk:Access restrictions 1.5

From OpenStreetMap Wiki
Jump to navigation Jump to search

To avoid the talk page getting out of hand, please use "Add topic" at the top for each new point raised, and consider using Template:Resolved and friends to mark headings that people can skip over, or which need urgent attention. Thanks! --achadwick 15:22, 26 April 2011 (BST)

[general] Diagram the hierarchy?

Resolved: --Flaimo 09:48, 10 May 2011 (BST)

Might be worth diagramming the hierarchy. Graphviz ".dot" format text in the comment of a generated .svg file upload would probably be sensible: that way other users can edit and regenerate the image. --achadwick 15:20, 26 April 2011 (BST)

the access tree is work in progress. at the end it definitely should be formatted better, with explanations for each row, icons, example pictures and such. --Flaimo 22:07, 26 April 2011 (BST)
not only the access key, but also conditions and modifiers should be provided maybe as xml files. but this should be handled in a separate proposal. --Flaimo 09:48, 10 May 2011 (BST)

[general] Wizard needed

Resolved: added chapter about editors

The proposal looks really good and extended but the tagging scheme therefore gets more complicated. Editors should definetly get a good wizard of some sort to support widespread use. --Computerfreaked 18:31, 9 May 2011 (BST)

Hi, Computerfreaked! I added a new section since this is really nothing to do with diagramming. Things are a little in flux now, but hopefully we'll settle on a syntax that's sufficiently easy to code to that somebody can make a wizard for JOSM. Personally I think we need to simplify the key syntax a lot. --achadwick 18:55, 9 May 2011 (BST)
that is exactly why i am using different separators for the different parts. only this way editors/parsers can differentiate between them, without always having up to date lists of all keys, connectors, conditions and modifiers. also it eliminated the possibility of strings being used more than once. if someone wants to define a condition "taxi" he can do so without running the risk of a mixup with a key for the role "taxi" ("access:taxi" vs "access!taxi" or "access?taxi").
also don't forget that complicated constellations with this tagging scheme are more the exception than the rule. most of the time people will use simple tags like access:bicycle=yes, which i actually conciser better for absolute beginners, since they know immediately, that a certain key has to do with access restrictions because of the "access:". currently "hgv", "goods", "customer", are completely separate tags at first sight. without looking at the wiki page you would never know, that they are connected somehow. --Flaimo 08:56, 10 May 2011 (BST)

[modes] Animal driving vs. animal riding vs. carriages...

Resolved: Horse-drawn carriages represented. Skip sheep-herding notation for now. --achadwick 00:46, 28 April 2011 (BST)

Need to distinguish at least between driven animals like cattle or sheep (or camels or horses), ridden animals (horses, camels, elephants), and towing animals (horses, cattle...). Does that introduce another node in the hierarchy? --achadwick 15:25, 26 April 2011 (BST)

towing should be covered by the trailers sub chapter now. are driven animals actually important? it is not something you "drive" or use to get from A to B… non of the comments in the other proposal mentioned that i think, so demand isn't really high for that --Flaimo 22:06, 26 April 2011 (BST)

I suspect you might find some restrictions out in the countryside for sheep herding, on signs. But you're right, it's not something that's useful for general mid to long distance routing. Let's leave it out this time.

[modes] mofa

Resolved: removed mofa for lack of physical differences to mopeds --Flaimo 09:51, 10 May 2011 (BST)
  • What's a "mofa", and how does it differ from a moped? Seems to be a German term. --achadwick 15:47, 26 April 2011 (BST)

@mofa: not sure about that either. seems to be a classification in germany, but i think not here in austria. it is allowed to go 25km/h max, which actually is kind of the maxspeed even electrical bicycles are allowed to drive here. i have moved it under "moped". --Flaimo 22:02, 26 April 2011 (BST)

Last year I learned that some other countries have a similar classification; in Belgium, it's apparently called moped class A. A page to start from could be User:Eimai/Cycleway. On the other hand, at least here we have (in the legal sense) only motorcycles and mopeds, so placing mopeds under motorscooter seems at least redundant. Alv 07:35, 27 April 2011 (BST)
i have now added some descriptions to motorcycle, motorscooter, moped and mofa. if mofa is something that only a couple of countries have, i would have no problem dropping it from the list. it could be described with access:moped#speed=25. --Flaimo 18:47, 1 May 2011 (BST)
i removed mofa from the list. there aren't any real physical difference to mopeds accept for the maxspeed. --Flaimo 09:51, 10 May 2011 (BST)

[modes] powered wheelchairs

Resolved: Flaimo 13:17, 27 April 2011 (BST)
  • …:foot:wheelchair is fine for manual wheelchairs. Need to add …:vehicle:motorized:…:powered_wheelchair too, probably --achadwick 15:47, 26 April 2011 (BST)

@wheelchair: added subkeys --Flaimo 22:02, 26 April 2011 (BST)

[modes] scooters and powered scooters

Resolved: electric is now a property. kickscooter and motorscooter are seperate modes now --Flaimo 11:44, 28 April 2011 (BST)
  • Same (as for powered wheelhairs) for …:motorized:single_tracked:…:powered_scooter, …:mode:foot:…:scooter --achadwick 15:47, 26 April 2011 (BST)
@electric bike: we need examples on why electric bikes need to be handled separately. here in austria, for example, by law a bike is a bike ith or without an electric support. if it is driven by an motor (compustion or electric doesn't matter) and goes faster than 30 km/h, it is automatically classified as a scooter. --Flaimo 22:02, 26 April 2011 (BST)

[modes][okay, more like roles] buses for special uses

Resolved: Flaimo 13:17, 27 April 2011 (BST)

Divide buses into :tourist, :local, :school? --achadwick 15:47, 26 April 2011 (BST)

@local: whats a local bus? a bus used only for local public transport with limited reach? other bus values are in the list now. --Flaimo 22:02, 26 April 2011 (BST)

Bus: I've seen three kinds of bus restrictions so far:
  • "no buses" - no vehicle registered as a bus allowed (or only such vehicles allowed); in fact not a subclass of psv, even if a majority of them operate as such.
  • "only line traffic buses allowed" - sometimes even the bus route ref is identified, or that it's local traffic (public, regularly run line)
  • "only tourist buses" - I can atm only recall parking allowances using this form, but wouldn't be surprised to find it used elsewhere, too.
The last case would also include "only library bus", and could also include school buses in counries that have them. Alv 08:00, 27 April 2011 (BST)
actually, "school", "local public transport", "tourists" and such are mostly roles, not physical properties of the vehicle. i have added those under roles and slimmed down the mode branch. --Flaimo 10:18, 27 April 2011 (BST)

A "local bus" is a scheduled bus that's local to a roughly city-size area, and which doesn't go (much) beyond its outer boundaries except to join up with a nearby town or two. They're distinct from "coaches" in UK usage, which tend to join up cities and run longer routes. Local buses sometimes get roads set aside for their use. I agree this is more like a role in the model we're discussing: the vehicles can be identical. --achadwick 00:41, 28 April 2011 (BST)

[modes] sidecars and trailers

Resolved: Flaimo 13:17, 27 April 2011 (BST)
  • Possible need for …:motorcycle:sidecar and the same for bicycle and other two-wheelers
  • No reason not to generatively permit …:trailer for any vehicle that can tow one

--achadwick 15:47, 26 April 2011 (BST)

@trailers: added a sub chapter about trailers,sidecars,… --Flaimo 22:02, 26 April 2011 (BST)

[modes] 4wd and electric

Resolved: Flaimo 20:06, 27 April 2011 (BST)

4wd vans exist, also electric vans. (Here neither 4wd nor electric has been used as a restriction, so someone else would have to voice an opinion.) Also: hybrid buses. Alv 16:40, 27 April 2011 (BST)

introduced properties for access keys. 4wd was added because of this proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/4WD_Only --Flaimo 20:06, 27 April 2011 (BST)

[roles] "service traffic"

Resolved: added law based conditions. --Flaimo 10:02, 28 April 2011 (BST)

I've mentioned this on some talk page in the distant past, but it fits here: we have a very common case that I'd find hard to tag - not that anyone would have tagged them so far. The combination is usually "no motorized vehicles" + (literally) "service traffic allowed" ("huoltoajo sallittu"); there's a clear definition of service traffic in the law, but it includes whole lot of use cases:

  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

It's not =destination, since not everyone can drive there; taxi=destination covers the case #6. motor_vehicle=delivery would cover #5, but cases 1 to 3 are more harder to express. Not that it would be reasonable, to expect it to be possible to encode all of these into every way with the said sign... The main traffic sign can also be something else which generally rules out motorcars. Alv 08:35, 27 April 2011 (BST)

Maybe it would be best to use something like #def:huoltoajo=sign:Fi:872 and motor_vehicle#if:huoltoajo=yes (with the motor_vehicle=delivery and taxi=destination and disabled=yes. One sign to 5 tags... Alv 08:44, 27 April 2011 (BST)


all of those things you mention are roles:
  1. @traffic for guarding…: access:guard, access:operator, access:caretaker (newly added)
  2. @traffic to transport a person…: access:aid (newly added)
  3. @more than one child under 7 years old…: propably to exotic. one of those rules that won't be covered by this scheme
  4. @vehicle driven by a physically disabled person…: access:handicapped
  5. @Any delivery traffic…: access:delivery
  6. @Any taxi…: access:taxi
--Flaimo 20:24, 27 April 2011 (BST)

[conditions] "weight" should be added, before "axleload"

Resolved: added underscore for axle_load + link to wikipedia; added weight. --Flaimo 08:53, 28 April 2011 (BST)

Suggest

  • adding #weight before #axleload (it's more frequently used here, and is what English speakers will be searching for. We may need to explain exactly what axle load is.
  • using_some_underscores to help break up impossible compounds like maxaxleload. axle_load please, and max_axle_load.

--achadwick 21:57, 27 April 2011 (BST)

[syntax] [wiki-meta] The "#" separator and Template:Tag

Resolved: better usage of tag template. cases without ":" can't be linked correctly though. --Flaimo 11:37, 28 April 2011 (BST)

The hash sign ("#") is really messing up Template:Tag in the wiki if the page exists, since it's meaningful in links. Can we settle on linking to Key:access so it's not a confusing mess of red and blue links.

Wiki syntax Renders as 
 {{Tag|access#direction||forward}}  
 {{Tag|access|:=motorized#speed||60mph}}
 {{Tag|access|:=foot#avoid||yes}}
 {{Tag|access|:=non_motorized#avoid||yes}}

 access#direction=forward
 access:motorized#speed=60mph
 access:foot#avoid=yes
 access:non_motorized#avoid=yes

Alternatively, perhaps not bothering with the template and using typewriter text or bold text for tag examples would be quicker at this stage?

--achadwick 00:17, 28 April 2011 (BST)

Combine "properties" and "trailers" sections?

Resolved: combined both chapters. --Flaimo 08:59, 28 April 2011 (BST)

We should combine the Properties and Trailers sections, since they both use the same syntax, and are both basically properties (of a mode, specifically, for now...). It makes sense to list them in separate tables, but put them under a single heading. --achadwick 00:49, 28 April 2011 (BST)

[conditions] [syntax] A couple of related suggestions

Resolved: syntax changed to ! and ?; modifiers alsways at the end. --Flaimo 10:43, 28 April 2011 (BST)

If we're going to use punctuation to separate things, can I make two suggestions?

  • Use "?" where we're now using ":if:" along the mode or role axis
    • → access:hgv?ice=no
    • meaning "No access for lorries when the roads are icy"
  • Move conditions before modifiers, but after properties:
    • → access:hgv+trailer?wet#maxspeed=30mph
    • meaning "The maximum speed for articulated lorries when raining is 30mph."

Only one condition per key is best: that way you don't have multiple equivalent orderings. --achadwick 01:01, 28 April 2011 (BST)

it is also less error prone for validators. changed the syntax and examples --Flaimo 10:43, 28 April 2011 (BST)

[values] Use "forward", "both", and "backward" for 1/0/-1 (and use yes/no for boolean types)

Resolved: removed 0/1 for boolean values. --Flaimo 10:10, 28 April 2011 (BST)

Please can we avoid "0" and "1" for boolean values, and use "no" and "yes" instead? Also, the permissible values for #direction should be "forward", "backward", and "both", with "both" as the default. --achadwick 01:07, 28 April 2011 (BST)

removed 0/1 (see http://wiki.openstreetmap.org/wiki/Proposed_features/boolean_values), but kept -1/0/1 since it is not a boolean. backward/both/forward are preferred. --Flaimo 10:10, 28 April 2011 (BST)

[modifiers] an assumed #modifier

Resolved: Looks like we settled on "#usage" --achadwick 19:06, 9 May 2011 (BST)

Parts of the model are emerging quite nicely, but it would be nice if we explained that the legal access level, i.e. compulsory/yes/permissive etc., can be understood as a 'modifier' too. Suggestion: 

                     access:bicycle     = no
 is equivalent to    access:bicycle#use = no    (but you never need to write out the "#use")

Meaning "use of (ridden) bicycles is forbidden". Perhaps we need a better name than "modifier" for the "#thing" syntax. "Qualifier"? "Limitation"?

--achadwick 01:33, 28 April 2011 (BST)

maybe just "Restrictions"? --Flaimo 11:51, 28 April 2011 (BST)

logical AND/OR relations

Resolved: dropped the OR syntax;kept the AND rule --Flaimo 09:54, 10 May 2011 (BST)

the biggest problem, which i consider the holy grail of access restrictions, are logical AND/OR relations between access keys. Example: a service road tagged with service=parking_aisle can only be accessed by bus if the driver is the operator or by customers but only in normal cars. translated that would mean something like that:

(access:bus AND access:operator) OR (access:motorcar AND access:customer)

any ideas on how the syntax should look like? i fear that it is not really doable with the flat key/value scheme.

idea:

  • access:(bus&&operator)||(motorcar&&customer)#usage=yes
  • access:(bus&&operator)||(motorcar&&customer)#maxspeed=40
  • access:(bus&&operator)||(motorcar&&customer)?wet#maxspeed=25

another example: access for customers is permissive, if they use motorcars, but private if they want to use good vehicle. delivery by goods vehicle on the other hand is permissive again.

  • access:(vehicle&&customer)||(goods&&delivery)#usage=permissive
  • access:(goods&&customer)#usage=private

combined with conditions the keys would become extremely long and basically only readable by people who know how to write code. Another problem would be the 240 or so character limitation for keys/values --Flaimo 22:25, 28 April 2011 (BST)

Strong -1 from me, primarily because the syntax above is absolutely horrible for mappers to write. Just write it out as several lines. We probably don't need to go into detail about operator or customer roles (or conditions, or whatever) here either. Keep it simple, and please just drop this whole concept. --achadwick 23:14, 29 April 2011 (BST)
i dropped the OR syntax and the braces, since they were redundant, because it can also be written in two separate lines, but i kept the AND rule. i simplified the example in the chapter; maybe it gets clearer what the flaw would be without such a construct. it is meant for corner cases anyway, but i didn't want to leave this cases untouched in the proposal. and also, don't forget that access rules are not just there for defining official street laws. they should also work on any kind of element and when it's private, the owner can make up all kinds of rules. --Flaimo 13:18, 30 April 2011 (BST)

Self-defined conditions

Disregard: Perhaps rather than a macro language we can do something a little more evolved. See below. --achadwick 14:10, 9 May 2011 (BST)

I really think real-world access restrictions that you might read off a road sign aren't going to be complex enough to need the little macro language you're inventing. Do you have any concrete examples? Photos of signs would be ideal. If not, let's backburner this and thrash it out on the talk page. --achadwick 23:23, 29 April 2011 (BST)

i overreached a bit on that one. i removed the passage that said, that you can add multiple criteria to a condition. but i kept the general rule of defining your own condition keyword for a custom timespan, otherwise the hard coded value would need to be added to the key and that is something i definitely won't do, besides the fact it it is more error prone, than defining the value once in a separate line. originally i was inspired by that proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Tag:restriction%3Dschool_zone , but it is also mentioned here http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags#time (the, in my opinion, bad version with the value on the left side)--Flaimo 02:26, 30 April 2011 (BST)

Progressing this a bit. I think there's more we can do, but we have to step outside the existing model. See below for some (fairly long-winded) discussion. --achadwick 14:10, 9 May 2011 (BST)

Restricted access ("Zona a Traffico Limitato")

Resolved: "Zona a Traffico Limitato" could be described with the syntax of this proposal using a custom time based condition --Flaimo 09:16, 3 May 2011 (BST)

In the historic centre of Rome we have roads in restricted access areas (calls ZTL "Zona a Traffico Limitato" - "Limited Traffic Zone" in English) without an appropriate tag to describe these restrictions. The restrictions are on only in some days and/or hours and is not valid for all kind of motor transport. Every restricted area have passages controlled by enforcement cameras for control who can access or not when the restriction is on. I think we need new tags for describe these situations and similar.

So I think we need:

A new tag "restricted" for every road in the restricted areas (ZTL):

access:restricted=yes
access:motorcycle=yes
access:motorcar=restricted
access:moped=yes
access:psv=yes
access:foot=yes
access:day_on#restricted=*
access:day_off#restricted=*
access:hour_on#restricted=*
access:hour_off#restricted=*

And a tag for the passages:

traffic_enforcement=yes
name=ZTL

--Madeco 15:53, 2 May 2011 (BST)

does the Zona a Traffico Limitato restriction mean, that such a street is only opened at a certain time in general for everybody, or just for certain certain kinds of vehicles? what i am also not sure about, is the enforcement by camera. does that mean every vehicle has to stop before a camera and wait until some police officer gives a GO or NO GO?
what you could do with the keys of this proposal, is define such a time period as a time based condition. Example:
The "Zone a Traffico Limitato" (ZTL) (Limited Traffic Zones) are areas in the historic centre of Rome where the access of motorcar and other kind of motor transport is restriced, expect authorized motorcar, motorcycle, public transport service, electric motorcar. The access to the ZTL is controlled by enforcement cameras for every passage. Every vehicle doesn't stop it, but automatically the camera register the car plate for establish if that vehicle can access or not when ZTL is on. Only few passages are not controlled by cameras, but by police. The ZTL is on in the weekdays in certain times, and When is off, all of kind of vehicles can access it. http://www.agenziamobilita.roma.it/en/ztl/ztl.html
So:

--Madeco 23:24, 2 May 2011 (BST)

There is also a proposal dealing with them: Proposed_features/boundary=limited_traffic_zone --Dieterdreist (talk) 17:23, 14 March 2013 (UTC)

"Self-defined" conditions: subproposal for merge?

Unresolved

I've had a few thoughts on this myself, and I think that if we allow user-defined access classes we should do it a bit more thoroughly, and allow the wiki page or other sources to use the same language so that people can keep writing new access classes. Luckily it turns out to be quite easy to express, so I've taken the idea and I've run with it. I've also thrashed out the order of application in a way that covers conflicts better, and considered map rendering uses of the data.


Quick sketch of what I'm proposing → User:Achadwick/Access_1.5_thoughts


What do you think? If you think it's good, I'd like to merge the two proposals like this:

  • Use your range syntax. Loving the trailing "+" notation for weights and speeds!
  • Use your role hierarchy. Nicely expressive!
  • Use your mode hierarchy. Well thought out here, only arguments might be the precise strings to use.
  • Move roles from tags to values, using the .condition notation in my spec linked above.
  • Move conditions from tags to values, again using the dot notation from mine.
  • Describe how the spec applies to three sort of user/coder:
    1. an everyday mapper,
    2. someone writing a custom map win a simple stylesheeting language,
    3. someone coding a smart routing engine
  • Keep the "+" notation for trailers etc. from yours. I think. I'm less certain about this one.
  • I think using dots for properties looks nicer than hash signs ☺

(Full disclosure, I think having anything syntactically tricky in tag keys is a bad idea for the long term - so a lot of what your current proposal states in parts of the key has been moved to tag values where in my admittedly biased opinion it belongs☺)

--achadwick 14:04, 9 May 2011 (BST)

you should put it on it's own proposal page, so certain points can be discussed separately on its own comments page. --Flaimo 22:13, 9 May 2011 (BST)
It's not a proposal in its own right really, but I'm hoping it can be merged into this proposal as a change of syntax (and an addition to the semantics). However I don't want to tread on your toes by just integrating without asking first and soliciting comments. Feel free to comment, discussion welcome: the comments page is User_talk:Achadwick/Access_1.5_thoughts. --achadwick 22:54, 9 May 2011 (BST)
The ":"separator
By using it for both modes and profiles, parsers won't be able to differentiate between those two. How should it handle names for profiles that later are also used as role names by other mappers? that is exactly the reason why I choose different seperators, so an "access:taxi" (access key) can't be mixed up with an "access!taxi" (self defined condition).

Okay, I'll forbid it from profile names then. --achadwick 17:56, 10 May 2011 (BST)

Parsers
For both proposals it would need special parsing routines. Access restrictions are complicated in general, that is why even with the current access scheme hardly any routing program or renderer evaluates anything besides the general access tag. A new tagging scheme would definitely need a completely revamped parsing routine, which maybe could be provided as a framework for different programming languages, so programmers only have to rack their brains over it once. So I don't see an argument here for or against the one or the other syntax.

Correct, with the caveat that simpler key syntax degrades better for current rendering software and existing stylesheet languages. My scheme has only 1 + the number of modes possible profile assignment keys (and I think that's too many, but at least it's finite); yours has that times the number of profile identifiers times the number of conditions times the number of possible self-defined condition strings, i.e. infinity. Key proliferation for tags that may be used in making rendering decisions is probably a bad move.

Another observation: not all processors are equal, or need to process the definitions to the same extent. There are simple data consumers and complex ones.

I'm trying to keep MapCSS in my sights as a "simple" data consumer. It's able to do a little smart matching on tag values, as opposed to keys. Notice that it can use regular expression matches for values but not keys. I envisage that simple data consumers are only going to look for known substrings in the values of tags whose keys they know about.

I consider routing engines to be "complex evaluators", a distinct category.

Roles
Your ideas reflect an access scheme with roads and transportation in mind. I try to illustrate a mapping scheme for every kind of element. Some might only use roles and no transportation modes at all (access:woman/man for toilets for example or "access:USA" for american citizens at customs at US airports). Both, roles and modes, are of equal value and should be treated as such.

I'm not sure where you're getting that assumption from, but I should probably clarify that it's for general use, not just for roads.

I see modes and roles as cross-cutting and complementary. I've chosen to keep roles as key parts for a closer match with the existing way of doing things.

Further your model only allows the definition of roles in an OR coherence (For example the profile only applies if the user is a student OR an employee). It doesn't cover the cases where an AND coherence is needed. For example for disabled parking in front of an supermarket a user needs to have the roles "customer" AND "disabled" at the same time. if he has only one of them, the rule doesn't apply. Maybe it is possible with multiple profiles added up, but that would be an incredible complicated way for defining something like that.

Noted, and it's not possible with the current scheme. Profiles do not combine like that. Your example may be representable in OSM however by placing an area of disabled-only parking geographically within an area or accessed by serviceways whose access-by-role is customer (for how do you drive to the parking area without being a customer)? That doesn't cover everything though, so it looks like I'll have to invent more syntax. Drat!

Profiles
I'm a bit confused. You propose profiles, but in the comments to my proposal, you criticize the creation of a macro like language as to complicated? If I read your idea correctly, it would even mean that multiple multi-line-profiles can be added up AND also can be inherited (sometimes from predefined profiles the user can't see and doesn't know without looking them up somewhere in the wiki). I consider this is even more confusing. From an parsing or data redundancy point of view may seem logical seems logical, but I highly doubt that it would be readable by a human. Other mappers already criticize this proposal here as to complicated, so I doubt they would say anything different about profiles.

The semantics of self-defined condition application are still confusing to me. It does feel oddly like a macro-substitution language, probably because it's operating from definitions in the keys and seems to expand to... one or more keys.

As for having a core set of profiles: we would need to define the set of predefined profiles carefully, and be rather consistent with naming. There's nothing wrong with documenting in the wiki; the user isn't supposed to hold the entire set of tagging possibilities in their head anyway; the wiki is here for documentation, and there should be presets for this sort of thing.

I note that the access tree must be looked up in the wiki (or in a copy of the data table) in order for anything consuming the data to understand that a new shorthand mode, mofa for example (!), is a kind of motor vehicle. Ditto any mapper who comes across a new shorthand term and wants to see precisely where it fits into the hierarchy.

BTW I intend to recommend access assignments that are as backwards compatible as they possibly can be, while keeping the syntax friendly and minimal on the key side for the reasons above. Still working on the "how to tag" recommendations though.

I actually had, what you call profiles, incorporated into self defined conditions in the early stages of this proposal which allowed the usage of multiple modifiers for a condition, but dropped it again, because after going through my own examples a couple of days later, even I wasn't able to understand them completely anymore. Multi line conditions become incredible difficult to read, even for experienced mappers like you and me. That is why I cut it down to exactly one modifier again, so it doesn't get more complex, than it already is. I knew, that because of that, certain conditions can't be defined anymore.

Mappers are quite used to reading multiline sets of tags, I don't think this will stress them too much. Keeping the syntax of the key part as simple as possible really helps.

But I consider problems like that a topic for a full featured 2.0 version of an access scheme. And that is where I also see suggestion like your concept of profiles. Don't forget, this proposal here only clarifies the current syntax (the access tree) and extends it a bit. The access tree is still the core of it and self defined conditions are mainly there for the, often requested, time restrictions, so people don't put them into the key field as a hard coded value.

I agree with the concept of the access tree. I disagree with the key proliferation in it and the degree to which naive data consumers must match against parts of the key.

I suggest that you put your ideas on its own proposal page, set it to RFC and ask other people which (or which parts) of the two versions they like better, because as the author of this proposal I will always have a biased view on it.
--Flaimo 10:56, 10 May 2011 (BST)

I was hoping we'd be able to merge the two cleanly rather than coming up with competing schemas for the same thing. I'll revise and see what I think. --achadwick 17:56, 10 May 2011 (BST)

emergency/service

Resolved: --Flaimo 18:20, 11 May 2011 (BST)

In a lot of cases roads are restricted to police, ambulance and road maintenance vehicles. Typically these are turnarounds on motorways, or access to a toll road for similar purposes. There seem to be no current descriptions that cover this situation perhaps if we had

access=emergency (and or) service

to cover this situation

in this proposal those would fall under user roles. they are actually already listed in the table. you could tag such roads exclusive to emergency like this:
  • access:role=no (disable access for all roles in general)
  • access:emergency=designated (allow explicity again for emergency roles and therefore all subkeys like police, ambulance, …)
  • access:caretaker=yes (also allow access for maintenance. an alternative might be access:operator if the operator of the street (government???) does the maintenance himself)
you wouldn't put any restriction on the access:mode branch, since you cannot know which kind of vehicles the emergency personnel is using. the police might use motorcycles, while the fire department uses a truck. --Flaimo 18:20, 11 May 2011 (BST)

rationale?

Unresolved

Frankly speaking, I don't understand what this is all for. The current access=* scheme is the only tagging scheme in OSM that is really well-thought (except that the values "designated" and "official" should be removed, and "customer" should be added).

You mix up the distinction who may access something (as in current access=* scheme) and how (maxspeed etc.). Of course there may be some maxspeed for hgv for instance, but I would prefer maxspeed:hgv for that, as proposed here.

What we do need is

  • the distinction which access is allowed (e.g. a maxheight=* sign), and what is possible (actual height of the ceiling). Maybe some separate scheme like physical:*=* would be fine.
  • the distinction who may enter some object, and who may operate it. E.g. there are some waste transfer stations where everybody is allowed to enter, but only residents are allowed to leave their waste. I think that we need a new key such as operation=* for that, with the same values as in access=*.

--Fkv 03:41, 15 May 2011 (BST)


  1. if you suggest that designated and official should be removed, i think you haven't quite figured out the current access scheme.
  2. you are wrong: maxspeed=* isn't a "how" value. "how" refers to the mode of transportation. "who" is the user role. maxspeed=* is an artificial restriction (in this proposal called modifier), which can only exist and have meaning if there is something to apply it to. that is why it is applied to the transportation mode or user role and not the other way around as you suggest.
  3. through the access namespace you can clearly differentiate between such restrictions and physical descriptions of an element. height=* is a physical description, access.height=* or access:motorcar.height=* are restrictions. another reason to put the access tag, mode or role at the beginning and not the end.
  4. if you think that the current scheme is well thought through, then please provide examples for the following situations:
    • a single parking space that is for disabled customers only (user must have both roles).
    • a road than can only be accessed by agricultural, forestry or emergency motor vehicles.
capacity:disabled="1", motor_vehicle="agricultural;forestry". No value is needed for emergency vehicles, because they are allowed to access everything. --Fkv 16:39, 15 May 2011 (BST)
the ";" syntax isn't part of the current access scheme. also capacity:disabled isn't part of amenity=parking_space; emergency vehicles cannot access everything. privately held roads for example. --Flaimo 20:53, 15 May 2011 (BST)
The ";" syntax applys to all values in OSM, this is OSM basics. capacity:disabled is defined in amenity=parking. It would be illogical to use another syntax for amenity=parking_space. Emergency vehicles cannot access every private road, but the are allowed to, and this is what matters. Emergency personnel is also allowed to break things without asking. When a house is on fire, there is no time to write an application. --Fkv 07:32, 16 May 2011 (BST)
  1. you would need to tag the waste deposit separately from the whole area (or the entrance gate). the rest can easily be done with user roles (access:operator=*, access:visitor=*, access:customer=*).
--Flaimo 12:06, 15 May 2011 (BST)

Parking / parking spaces default suggestions

I like the proposal, but i think there are some not so good details. Namely:

1. I would change access:motorcycle=yes, access:roles=yes to access:motorcycle=permissive, access:roles=permissive. You use permissive everywhere else and I thing for a good reason.

the default access values based on this new scheme should represent the same information as the current one. and currently, if a parking element doesn't have any explicit access tags, it is evaluated as "public". that is the reason for the "yes" values.. you can still implement differing default values per country (for example if in your country, motorcycles are not allowed to use parking spaces build for cars). --Flaimo 13:28, 18 August 2011 (BST)


2. I do not like how the default is specified. It is ok if no access values are explicitly tagged, but it is wierd to have to override defaults everytime you need some special parking place. I take your own example (although there are better ones like bicycle parking) and mark the lines:


than notice that 3 out of 6 have nothing to do with the case you are trying to explain and are only present to everride defaults ( a),b),d) ). If there were no defaults, you can write just:

which is much, much cleaner and in fact it is the solution which I suggest. In case there is explicitely access=no than dismiss all defaults. Think about it and you will find it very practical and intuitive. The best evidence is the fact that you use this convention in your examples yourself - in all your parking examples you have omitted at least the access:roles=no override.

My suggestion therefore is to specify what exactly "if no access values are explicitly tagged" means in your fist sentence of the Parking / parking spaces chapter. I think that the rule is: mentioned defaults are assumed and added to specified tags unless they are specifically overriden (by i.e. access:motorcycle=no) or unless access=no is specified. In this case no defaults are assumed.

--Jakubt 00:06, 18 August 2011 (BST)

you are right, the example is a bit overcomplicated. the "no" on the general access tag does the job too. i'll change the example. besides that i think i should clearify something: i wrote those values down as examples for the access scheme. consolidating on default values, based on that scheme, should be done in a second step, after there is agreement on the access tags themselfs. i will note that in the proposal, that the default access values for elements are not part of the proposal. --Flaimo 13:28, 18 August 2011 (BST)
on second thought, that might not be such a good idea. if you would make "access=no" the default, you would also have to explicitly tag common parking spaces for cars with "access:car=designated" every single time. you could argue that it would be fair to treat every kind of transportation the same, but in reality the majority of parking spaces mapped in osm are for cars. buses and other transportation modes are the exception and therefore should be treated as such when it comes to default access values. --Flaimo 13:47, 18 August 2011 (BST)

Several examples

Resolved: --Flaimo 21:11, 17 November 2011 (UTC)

I wonder how one would express following restictions:

(Mind you, these are on the street, which is access=yes 24/7. Just parking/halting is limited - oh, it's mentioned once below) Alv 16:35, 18 August 2011 (BST)
Image Note Solution
Fee9-19exceptF.png
 Between Mo-Fr 09:00-19:00 parking is with tickets (zone 2), except if you have a residential permit with the label E. Free parking for all outside said time interval. my suggestion based on the scheme:

--Flaimo 23:50, 18 August 2011 (BST)

Residents or ticket.png
 During certain times you can park with ticket, residents with parking badge A can park anytime. my suggestion based on the scheme:

in case this signs represent parking alongside a road you would have to use "access_parkinglane_right" as the namespace instead of "access". --Flaimo 14:16, 18 August 2011 (BST)

Parkinghaltingdifferenttimes.png
 These are on the same pole. Two lanes, no extra space between lanes and the sidewalk. Free parking every night, every sunday and saturdays after 15:00. Even stopping your vehicle is banned on weekdays both 7:00-9:00 and 15:00-18:00 + saturdays 9:00 to 15:00. On weekdays parking is banned from 9:00 to 15:00. ["(9-15)" is just "saturdays 9:00-15:00". Red numbers would be the interval on Sundays.] I don't know what the values in the yellow sign mean exactly, but if it are just the times your are allowed to park, then this should be representable with the opening_hours syntax and the "time" modifier. --Flaimo 14:22, 18 August 2011 (BST)
These are from Talk:Proposed_features/parking:lane#Different_intervals_for_no_stopping_and_no_parking. I clarified their meaning. Alv 16:30, 18 August 2011 (BST)
parking and stopping are two different kinds of usage, therefore a separate namespace could be used for them:

--Flaimo 17:37, 18 August 2011 (BST)

"Handicapped" is not a nice word

... in English. Use "Disabled" only. There will never be access restrictions for all kinds of disabled persons, there might be exeptions for persons with walking disabilities maybe. So instead of access:role:handicapped:disabled I propose to use access:role:disabled:walking_impairment, access:role:disabled:hearing_impairment, access:role:disabled:visual_impairment. --Lulu-Ann 12:03, 16 November 2011 (UTC)

sounds reasonable. can a native speaker confirm that? --Flaimo 21:13, 17 November 2011 (UTC)

Generic solution for conditions

Please have a look at this: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extended_conditions_for_access_tags#Splitting_conditions_and_values

This would introduce a generic solution for conditions, which could be used on any key/value pair. As we need conditions for many keys (access, parking, reversible lanes, ...) an identical solution for all those situations would be preferable. --Imagic 07:23, 23 February 2012 (UTC)

this proposal already covers that: https://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5#Self_defined_conditions . also you can use namespaces other than "access" to use these conditions. see: https://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5#Namespace so parking lanes along roads or turn lanes are also covered --Flaimo 10:53, 23 February 2012 (UTC)

[Environment based conditions] for waterways

I suggest to add conditions for waterways:

  • water level in cm
  • volumetric discharge in cbm/s describes the flow of the river

For both the name of the reference gauging station (man_made=monitoring_station) shall be added: access:ref?min_level=Hoffnungsthal. I know this limits from rivers in North Rhine-Westphalia (example: Kanuverband von Nordrhein-Westfalen).--5erBande 11:40, 10 June 2012 (BST)

how are min_level and max_level defined? in your example, what is the "60" referring to? the level of the river or the boat? right now, i have added a general "depth" as a condition, which could be used to define the min/max depths of boats for waterways, but that still leaves out the environment based condition you suggest. i could add "min_level" and max_level" to the conditions, but they would make no sense as long as one defines them (see chapter self defined conditions). for example: access!min_level.depth = 50; --Flaimo 17:40, 10 June 2012 (BST)
To explain my example: You have access to a waterway marked with access?min_level=60 and access:ref?min_level=Hoffnungsthal (maybe both tags can be combined in one), if the gauging station named Hoffnungsthal shows a waterlevel of 60 cm or above. The access is limited by the authorities (german example of the Rhein-Sieg-Kreis) due to the nature reserve. Sometimes it is a recommendation of a sports club (see the link in my first statement). I found also some discussion at Talk:WikiProject_Whitewater_Maps#Access. --5erBande 07:19, 11 June 2012 (BST)
if i interpret that correctly, the notation based on this proposal would look like: access:water?min_level.depth=60. since it is tagged on waterways only the subkey could probably be left out: access?min_level.depth=60. The Station could also be added with the already existing source modifier: access?min_level.source=Hoffnungsthal. same goes for the other two conditions. if you think that it's correct, i could add the three environment based conditions to the proposal. --Flaimo 19:40, 11 June 2012 (BST)
sounds good, but it would be great if a native speaker could confirm the wording:
min/max_depth, min/max_level or min/max_stage ?
min_flow of min_discharge ?
One question: Is the modifier "depth" really necessary, because min_level is already clear (maybe I don't understand the concept of modifier well) ? The modifier "source" is reasonable. --5erBande 21:23, 12 June 2012 (BST)
Yes, because there could also be additional restrictions besides depth. If the waterway carries high water (max_level) there could also be a restrictions for height (because of bridges). In such a case both restrictions would be written as: access?min_level.depth=60 + access?min_level.height=15. Another example for roads maybe makes this more clear: If there is snow, the maximum weight of vehicles, as also the maximum speed could be restricted: access?snow.speed=50 + access?snow.weight=3.5 --Flaimo 22:16, 12 June 2012 (BST)

Any life here?

Current system needs some improvement:

  1. refactoring : imho lots of the difficulties we currently have arise from the fact that signs on roads/highways mean different things in different countries. So there needs to be a "translation mechanism" to translate "road signs" into OSM restrictions
  2. implicit/default restrictions and interpretation are highly complex and may depend on country, landuse, ownership etc. While the declared policy of OSM is tag what is on the ground - sign or no sign - I believe that at least mid-term there must be a way to map implicit restrictions (and also hazards etc btw) which are not specifically posted but are known to local mappers. That could be for example something like access:implicit:bicycle=*
  3. some type of highways like path/track (formal/informal) vs unpaved roads are vaguely defined

RicoZ (talk) 12:20, 23 August 2015 (UTC)

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