Proposal talk:Conditions for access tags

Would access:backward:bicycle=yes also be equivalent to bicycle:oneway=yes? Not that I would want to tag it that way, but do you also consider having more than one "condition"? Another example: maxspeed:hgv:wet=30 ("bei Nässe 30km/h für LKW", "when wet 30kph for hgv"), I'm not sure if something like that exists though, but it might. :) --Driver2 22:02, 29 January 2009 (UTC)

I have considered it and will probably create a follow-up proposal to deal with the more complex cases if this one is generally accepted. This has been discussed in the forum threads this proposal developed from (e.g. [1] and the one linked therein) and was part of the first draft (with a slightly different syntax, which is one of the many things that would have to be discussed for those cases), but I decided that the whole topic was too complex for a single proposal. --Tordanik 22:22, 29 January 2009 (UTC)

Order

Quick question: why maxspeed:hgv=* and not hgv:maxspeed=*? Why oneway:bicycle=* instead of bicycle:oneway=*? I propose to have the vehicle type first here, so there's no issue when "wet" also comes into play (hgv:maxspeed:wet=* instead of maxspeed:hgv:wet=* or maxspeed:wet:hgv=*.

Current numbers of tagwatch Europe give for (vehicle):oneway=* 96 uses in the database compared to only 5 for oneway:(vehicle)=*, so it looks like more people think the former is more logical. --Eimai 11:28, 30 January 2009 (UTC)

If you have a look at that other draft, you can expect that we will sooner or later will have things like weight, destination, time etc. Once that happens, we won't be able to avoid dealing with the scope1:scope2 vs scope2:scope1 problem anyway, and the rules regulating which scopes have to be put before the base key (is e.g. weight part of the vehicle description?) and which not will be another thing mappers need to look up and that they will often get wrong. "Everything goes behind the base key" is the easier rule, imo.

The tagwatch numbers are interesting, but the total number of uses (and esp. users) of those tags is far too small for proper statistical conclusions. --Tordanik 15:11, 30 January 2009 (UTC)

the question is, what's the base key? I'd take the base key to be "access" since all these keys are described at Key:access. --Hawke 20:15, 16 February 2009 (UTC)

As the introduction states, "this proposal contains some extensions to existing access tagging". Therefore, the "base key" is any of the existing keys described at Key:access. It can be one of the following:

• access
• oneway
• noexit
• maxspeed
• minspeed
• maxweight
• maxaxleload
• maxheight
• maxwidth
• maxlength
• maxdraught
• date_on
• date_off
• day_on
• day_off
• hour_on
• hour_off

Tags such as bicycle=yes can, in my opinion, be considered a short form of access:bicycle=yes, so they aren't own base keys but rather shortcuts for base key + scope.

I hope that this answered the question. --Tordanik 21:20, 16 February 2009 (UTC)

Partly. In my opinion, a tag like oneway=yes is similarly a short form of access:all:oneway=yes, and access=yes a short form of access:all=yes. For this reason it seems to me that it makes more sense to have these tags put the vehicle tags first. Of course, that's no "official" position, just a proposal at Proposed features/access: name space. But I think it makes sense, and it would be nice to have these two tagging proposals be compatible. --Hawke 22:11, 16 February 2009 (UTC)

Well, three things about the name space proposal:

1. You include "all" when something applies for all vehicles. I don't see why this is necessary. I also don't know how you could combine wet/forward/backward and similar information into your proposal. Probably you wouldn't explicitly state that some maxspeed/access is valid for all weather conditions? If you wouldn't, why do the "this applies for all vehicle types"?
2. I don't see what the advantage of namespacing everything with "access" is. It's not backwards compatible and unlikely to catch on as long as we are manually entering tags.
3. How could your proposal be extended with additional conditions, such as access=destination for vehicles weighing more than 3.5 t? With the system in my proposal, we could introduce weight conditions and slap them onto the base key.

On a side note, I'd consider oneway=yes an alternate form of access:backward=no. --Tordanik 23:50, 16 February 2009 (UTC)

"all" is required because in that proposal one must always specify a vehicle type. It consists of: the word "access", the vehicle type (with the list of vehicles taken from the access page), and an optional additional restriction (with the list of restrictions taken from the access page), separated with colons.

The advantage of treating access as a name-space: it implies that any tag "beneath" it is related to access=*, and it puts all these "subkeys" in a logical area -- no need to wonder whether any arbitrary tag is "part of the access system" if you don't have all the access keys memorised.

How to add additional arbitrary restrictions is an interesting question, but one which isn't solved by this proposal either, and if it were, could be applied to both. Can you describe how maxweight might be integrated into the key like this? (perhaps use the example you mentioned, access=destination for vehicle weight=3.5t)

I do really like the idea of forward=*/backward=* supplanting oneway=* as it seems much cleaner than oneway=1/-1, but I don't see that happening any time soon. --Hawke 03:22, 17 February 2009 (UTC)

From a human point of view, if the vehicle type comes before things like :maxspeed, then everything related to a particular vehicle type will be grouped together if the tags are shown sorted alphabetically. I think this would be generally more useful than having (for example) all the "time_off"s followed by all the "time_on"s. --EdLoach 17:11, 25 March 2009 (UTC)

Well, from my point of view, having all e.g. maxweight information grouped together isn't really a bad idea at all, because these restrictions are usually based on a single set of traffic signs and often start/end/change all at once (commonly a regulation sign with add-on signs stating exceptions). For time_on/off it's not that great, but I don't like these anyway and suggest using time conditions instead. --Tordanik 17:23, 25 March 2009 (UTC)

i aggree with EdLoach. conditions are always alternatives applied to a default situation. so the default situation (in that case the kind of transportation or the role a person holds) should be first, followed by the condition. I have written my version of a revamped access/modifier/condition suggestion over at http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Access_restrictions#Suggestion_for_a_new_scheme -- Flaimo 12:22, 17 March 2011 (UTC)

One of my design goals was to have rather short, human-readable tags. This does not seem to have been a major concern in the creation of your scheme. I understand and agree with pulling groups of users into the key, and also think that e.g. access:hgv would be a cleaner way of writing the hgv key. But beyond these sensible basic decisions, most of your suggestions don't seem to serve a clear purpose and I believe they would only make tagging more cumbersome: Why the inclusion of the (for me) unknwon acronyms "kot" and "sig" if you even consider "hgv" incomprehensible for new mappers? Why put the full hierarchy into the key (access:kot:vehicle:single_tracked:bicycle), instead of always using the so-called "shortcut key" access:bicycle? Why degrade independent attributes like maxspeed to "modifiers", again increasing the amout of syntactic overhead without clear benefit? And, to return to the topic of conditions, do you consider "access:hgv:maxspeed:alt:weekend_zone=80 + access:hgv:maxspeed:alt:weekend_zone:time=Sa-So 00:00-23:59" easier to use than my proposal? --Tordanik 22:42, 17 March 2011 (UTC)

maybe i didn't phrase it clearly enough, but the shortcut tag would be the default tag anyway. so for mode of transportation, all you basically add would be the "access:" in front of current tags. the fully qualified path is just in case a name is used in more than just one branch (which hopefully would never happen) and the "sig" and "kot" are just for structuring, so programmers can work more easily with the access tree (seperation between roles and transportation mode). they are still better understandable than for example relations. the problem is, you can't have it all. you can't try to put all the complex restrictions people would like to map in a scheme and at the same time make them as short and simple as the current one without being too vague for interpretation. that's not a problem of the access tag alone, but for all tags in general, now that users want to map every detail they can find on bing satellite images.

on to the next question: maxspeed would still be "independent" because you could apply it to the supernode. so "maxspeed" would become "access:maxspeed". to make it even more clear a different separator than the semicolon would actually be better, but i didn't wanted to go that far (for example access:hgv#maxspeed).

if the restriction applies to only a special kot or sig replace "access:" with for example "access:bicycle:". that kind of modularization is easier to understand, than to always worry if i have to put the "bicycle" in front if "oneway", or the other way around. i prefer to put the condition last, because a condition is always applied to an element, not the other way around, and for grouping and programmatic reasons its also better to work with. the thing that bugs me the most is at the moment, is that there are two separate proposals (access and conditions) which should actually be merged, because a modification of one can't go without adapting the other. and both seem to be inactive, if i look at the dates when people last commented. -- Flaimo 09:04, 18 March 2011 (UTC)

It might be a matter of taste, but I do not consider your ordering of the key's components easier to understand at all. This proposal has a clear key structure: base attribute (such as access or maxspeed) always comes first, then all the conditions. Possible conditions include kind of transportation, weather conditions, etc. It would also be easy to fit special interest groups in there as another category of possible conditions.

So you don't need to worry at all whether bicycle should be in front of oneway. bicycle is a KOT, not a base attribute, so it clearly should not be at the beginning of any key. Instead, it always comes after the base attribute, as in access:bicycle, or maxspeed:bicycle, or oneway:bicycle. I consider that resonably consistent. (The exception, of course, is the traditional tagging style of using just bicycle=yes for what would more precisely be called access:bicycle=yes according to this proposal.). --Tordanik 16:45, 19 March 2011 (UTC)

i consider neither "bicycle" nor "maxspeed" to be what you call base attributes, because both don't describe the physical presents of an element. both fall, more or less, under the access category ("who" vs. "how"), but in my opinion the kind of transportation weights more, because it is related to something physical, while maxspeed, opening_hours, … are just made up rules for one or all of them. there wouldn't be a maxspeed if there weren't any vehicles that go faster and need to obey such rule. if suddenly a certain kind of transportation can't use a way for some physical reason, all conditions attached to it become invalid/unnecessary at the same time too. same goes for roles. it all comes to if you want to put the person in the center of OSM or the rules. i rather go with persons, because that's who uses OSM maps and routing software and that's where all access restriction rules, one way or the other, end up to be applied to anyway. so i'd go with the user/vehicle centric approach. --Flaimo 01:57, 20 March 2011 (UTC)

replacing of access?

Whould this in some way replace the access tag? I am looking for a good way to give various restrictions of access depending on the group. Something like foot=yes rollerblades=no bicicle=restricted car=oneway hgv=limited. --Skippern 03:48, 3 February 2009 (UTC)

Tags like foot=yes do already exist. Things like "car=oneway" could be expressed as oneway:car=yes using this proposal (it's officially "motorcar", however). I haven't seen "restricted" or "limited" yet, what are they supposed to describe? --Tordanik 15:34, 4 February 2009 (UTC)

At the moment access give the following values: Yes, no, and permissive, I find this to be inadequate as it doesn't give indications of places where a hgv can enter at certain times of day, or if vehicles can enter if they have a destination within the restricted area, but not pass through. A restriction tag can be used to describe the restriction in question, and a limit tag can describe limits applied for accessing the area, and so on. The limit should not be confused with height or weight restrictions as this is something else. Feel free to work with this idea. --Skippern 11:02, 5 February 2009 (UTC)

For "vehicles can enter if they have a destination within the restricted area", we have been using the "destination" value (e.g. access=destination) for quite some time, see Key:access. I've been planning to deal with the time problem in a follow-up proposal if no one else does. --Tordanik 17:44, 5 February 2009 (UTC)

Little more documentation of interpretation and consequences?

There are some way-specific tags in this proposal, which will need reversing when a user reverses a way. Could this be explicitly documented on the main page? Additionally, how is one supposed to interpret corner cases like a way tagged

 maxspeed=20
 maxspeed:forward=100
 maxspeed:backward=60

I've done so for Proposed features/right left, saying that the more specific ones override the base tag. I think that's sound. Could this be documented somewhere? --achadwick 23:09, 15 February 2009 (UTC)

The section Evaluating "conflicting" tags on the main page states that "More specific information overwrites more general information" as rule #1. I think this applies in your example, as maxspeed:forward is more specific than maxspeed for someone moving in way direction (same for backward).

I'm going to add a note about direction dependent scopes -- should be everything containing ":forward" or ":backward" or starting with "oneway". --Tordanik 11:23, 16 February 2009 (UTC)

Request for feedback: Syntax Poll on Extended conditions for access tags

I ask everyone who has supported this proposal to have a look at the extended version. I'm interested whether a change in syntax as discussed there (using [...] instead of :...) would be supported by you -- the alternative syntax has been proposed on the mailing lists and might work better with some of the added conditions and also more recent suggestions such as left/right, but it is different from what has been used so far -- or whether you prefer to stick with the colon syntax that was used here. Other comments and suggestions are welcome, too, of course. --Tordanik 20:29, 21 June 2009 (UTC)

replacing hour_on/off

There have been some comments recently that suggest replacing hour_on/off with opening_hours. I fully agree that hour_on/off should be replaced. However, opening_hours is still limited for this purpose (it's perfectly fine for shops and similar features, though), because it can only "switch" availability, but not other attributes such as maxspeed.
That's why I have proposed to (among other improvements) allow for opening_hours values to be part of any key that can depend on current time. This is more flexible than just using opening_hours, so I consider it a preferable approach. Does this suggestion address the commenters' requirements or do you need to express some other cases? --Tordanik 18:08, 13 May 2010 (UTC)

Sorry, I misunderstood you:

Perfectly fine with me. Actually, I'm running a proposal (Proposed_features/parking:lane) that uses time intervals, too. Please have a look at Proposed_features/parking:lane#Specifying_time_intervals_.28optional.29, where the syntax of opening_hours is used to specify e.g. the duration of a payment requirement for parking. --Kay D 19:19, 13 May 2010 (UTC)

The difference to the problem I'm trying to solve is that you don't try to deal with different values depending on time. Unless I'm mistaken, your syntax could not express a (hypothetical) "maxstay 1 hour on Weekdays, 2 hours on Saturdays"?

Furthermore, calling a key "opening hours" just for the sake of similarity may be counter-productive, because it may be ambiguous. E.g. If you specify acces:no and opening_hours=09:00-17:00, should that mean access during daytime yes or no, i.e. does opening hours apply to the "non-openness" of a road or to the "openness"? Please choose a key that makes this point very very clear. --Kay D 19:19, 13 May 2010 (UTC)

My proposal suggests to add a suffix to an existing key - such as access:(09:00-17:00)=no if access isn't permitted during daytime. Therefore, there is no need to choose a key name. --Tordanik 12:38, 14 May 2010 (UTC)

I did not realize the values were to go into the keys, which just sounds and feels very wrong. Reasons for this that immediately spring into my mind are:

• Introduction of indefinite keys
• tagstat would become useless for those "keys"
• rendering with mapnik is "impossible" because the keys have to be queried

We would be better off to introduce lists (seem to have this heard before), like access=('09:00-17:00':no) or maxspeed=(Mo-Fr:80;Sa:100;Su:60) or maxstay=(Mo-Fr:1 h;Sa:2 h).

--Kay D 20:45, 16 May 2010 (UTC)

A problem with lists is that adding "details" (e.g. the maxspeed for hgv) will break a lot of existing uses of the data (in this example: the "normal" maxspeed for cars which likely more mappers will care about). Of course we could fix this by improving all the applications, just as we could deal with the problems you mentioned regarding Tagstat and Mapnik. It's just that, with lists, neither the basic nor the additional information will work anymore until applications are upgraded, which will likely lead to conflicts between mappers. With extended keys, the old-style tags will continue to work just fine, which is in line with the general idea that you shouldn't redefine the syntax of widely-used tags.

So basically, additional tags with conditions as part of the key can be added incrementally to the database and the applications. While lists might be a nicer solution, they are harder to introduce due to the lack of a binding decision process within the OSM project.

Nevertheless, I don't generally oppose the idea of using lists of conditions and associated values as value strings - you could certainly decide to risk the potential conflicts or employ a workaround (such as using access:cond=yes; 09:00-17:00 no in parallel to the normal keys while waiting for support in applications). The semantics would likely be identical to my proposal, it would mostly be a matter of defining a good value syntax. --Tordanik 20:05, 17 May 2010 (UTC)

Status

What is the status of this proposal ? Maybe we should abandon it with a short note in favour of the updated proposal ? --Skyper 11:09, 8 July 2010 (UTC)

Agreed. sletuffe 13:54, 1 November 2010 (UTC)

Unfortunately, the updated proposal is more controversial, particularly because of the use of special characters like ) or < in keys, the possibility of synonymous keys (maxspeed:wet:hgv = maxspeed:hgv:wet) and the potentially infinite number of keys that arises from the inclusion of time intervals and numeric values. --Tordanik 19:05, 1 November 2010 (UTC)

obsolete proposal

it is confusing to have so many open access proposals at once. can you please close this proposal, since you have created a follow up proposal for conditions anyway --Flaimo 12:10, 25 April 2011 (BST)

cycleway=opposite is equivalent to oneway:bicycle=no

I don't think this is a good example.

Just tagging a road which has a oneway, but has a lane the other way for buses, taxis etc, but bicycles are permitted. It is a pretty ugly road for cycling, but bicycles are legally permitted in bus lanes. However, it is misleading to tag it cycleway=opposite, when you may expect to actually have a cycleway.. Any objection if I remove this as an example? --inas 05:23, 20 May 2011 (BST)

The tag cycleway=opposite means that you do not have a cycleway - you are allowed to go through a oneway road the other way, but have to share space with other traffic. (Of course, this means that the tag is badly named. I would prefer not to use it at all, but it's much more popular than oneway:bicycle=no for historical reasons.) If there was a cycleway, it would be tagged as cycleway=opposite_lane or cycleway=opposite_track. --Tordanik 09:36, 20 May 2011 (BST)