Proposal talk:Extended conditions for access tags

From OpenStreetMap Wiki
Jump to navigation Jump to search

Curly bracket

Resolved

One question: Why do you use curly bracket instead of normal ones? Has that a special reason? --AndreR 13:47, 11 March 2009 (UTC)

No, it hasn't. Remotely inspired by the "set of time intervals" idea, but it is mainly an attempt to choose some notation that does not cause conflicts with anything else -- which rules out [], as some people are suggesting to use that for simulating tag hierarchies etc, but probably not (). So you would prefer normal brackets then? --Tordanik 14:14, 11 March 2009 (UTC)

Bad idea

This kind of syntax is really a bad idea. The key is not the place to put something like the opening hours. It has to be a value of a key, and I understand that you want to have multiple conditions for a certain access tag, but we've had something that can combine tags for a long time now: relations. --Eimai 18:14, 19 March 2009 (UTC)

The only workable way of putting opening hours into a tag's value part would be hierarchical tags, which are currently not directly supported by the api. They can be simulated using array-index-like solutions, relations or similar constructs, but these don't qualify as nice syntax either, require more effort to enter manually and are error-prone. If you can convince the api devs to introduce tag hierarchies, that might indeed be a nice way of adding conditions to access tags.
About relations: Relations don't combine tags, they connect objects. Even if relations can theoretically be used as tag containers, that's not the original purpose of relations. Relations are also hard to create without dedicated editor support (that does not exist even for some really widely-used relations yet) and have been observed to be hard to understand for mappers (especially when you violate the "group of objects" semantics). I can't really comment on your suggestion of using relations because you didn't specify how you'd utilize them to meet the requirements of this proposal, but the general problems with relations will inevitably apply. --Tordanik 19:24, 19 March 2009 (UTC)
I've given all my ideas at Proposed_features/Access_restrictions already. It's actually less error-prone than using tags like you propose, as there's only one place where the tags are defined if your street is divided up into many ways. --Eimai 19:36, 19 March 2009 (UTC)
Well. I could of course select all ways of my street and edit them all at the same time (and be sure that nobody has reused my relation for something at the other end of the city). I still don't particularly like that "reuse" aspect of relations.
Your concept does, however, have its merits (like working with key usage statistics, not putting value-like things into keys, thus allowing for easier syntax checking, etc. I also imagine that it would be easy to build some ui dialog for that.). What I don't like is the effort that is required for adding information for restrictions at the "maxspeed:hgv=70" level of complexity -- adding that tag is far less effort than a creating a relation when done manually. --Tordanik 20:45, 19 March 2009 (UTC)
As I've mentioned several times on that page: I don't want to hold back tags like "hgv:maxspeed=70". But that's as far as it can go in my opinion though. If you just keep adding more and more to the tag it'll be very complicated to actually read and understand it. In Potlatch for example you can only see this small piece of the tag and have to "scroll" it to read it all.
And it really isn't abusing relations in any way. It's a very valid thing to do and actually does what you want: combine ways with the same access rules. They can also have more data in the relation as well that could be useful. Maxspeed zones for example usually have names and id's over here which can be useful.
It's also semantically more beautiful to have a thing like a "zone 30" or a "zone maxweight 5ton except deliveries" represented as one entity (being a relation) in OSM and as such makes it easier to maintain. --Eimai 21:03, 19 March 2009 (UTC)
Well, it's not that I insist on maxspeed:hgv (or hgv:maxspeed ...). In fact, I prefer a unified solution to having two ways of expressing things (except simple one-tag-stuff like bicylce=yes). If it were only about what I'd like to have in the database, I wouldn't see a problem with your solution. However, I'm still worried about editing. If you (or someone else) could offer a proof of concept implementation of high-usability editor support for relation-based conditional restrictions, I'd be much more confident that it could work. --Tordanik 19:25, 21 March 2009 (UTC)
I've been looking at various UK roadsigns in the last few days, and access tags which support times would be really useful in many cases (such as no motor vehicles between 9am and 4pm except for goods vehicles (un)loading and buses). Looking at the opening_hours syntax they have the option of specifying "off", so something like "motor_vehicle=09:00-16:00 no" would be much simpler than day_on, day_off, time_on, time_off, probably qualified as motor_vehicle:time_on etc. I don't think they should be part of the key though, which is why I like the option of adding the time range to the value (you could similarly have "bicycle=10:00-18:00 yes", and so on). --EdLoach 14:42, 25 March 2009 (UTC)
This doesn't have anything to do with the suggestion of using relations, does it?.
How would you describe something as "delivery access for vehicles over 3.5 t only between 6:00 and 10:00"? --Tordanik 15:11, 25 March 2009 (UTC)

Units

Resolved

This is useless unless it is made sure that SI-units are used (meter, kilogramme, etc.) --Lulu-Ann 17:02, 10 June 2009 (UTC)

SI units are default. Otherwise, people need to state otherwise as they'd need to do for maxheight etc. I've tried to make this clearer. --Tordanik 17:14, 10 June 2009 (UTC)

Knows syntax

Resolved

In onway streets for "backwards" the common solution is _opposite, see bicycle tracks. Can we change it to "_opposite" instead of "backwards" ? --Lulu-Ann 12:20, 28 July 2009 (UTC)

My opinion is that "forward"--"backward" is a better pair than "forward"--"opposite". For cycleway, this does not matter as no "forward" is required there. By the way, the forward/backward terms have also been used in OSM, see Relation:route. --Tordanik 15:09, 28 July 2009 (UTC)

Personal conditions

Resolved

Not only the vehicle conditions can have influence on the routing, also the personal condition. Like Mikel Maron mentioned at the SotM09, it can change your routing for hundereds of kilometers if you don't have a visum for the state you need to cross. Also there might be areas or routes where you are not allowed to go if you take a dog or other animal with you. Some routes ask for toll, so drivers might want to exclude them. How can we offer tags to make all these things configurable for navigation software. --Lulu-Ann 07:50, 29 July 2009 (UTC)

I don't think there is a single answer for all of your examples.
  • The visum problem requires finding out what state a street belongs to. You can use country borders for this (or is_in, or something entirely different).
  • You can use dog=yes/no/leashed to find out whether a dog is allowed on the way.
  • I'm sure there is a tag for tolls, but I haven't used it yet.
Conditional tags, as suggested by this proposal, probably are not required for the first two cases, and can be used if the tolls depend on time/vehicle/$somethingelse. This proposal is about situations where a tag's value depends on something. In your examples, the way's usability depends on something, which simply requires additional tags - and, of course, applications that actually use the tags. Once you have a tag definition and the data available, it's easy for navigation software to incorporate the feature (of course, it's not so easy if you still want a simple user interface). You need two things:
  • User input that defines the vehicle, the user's preferences and rights, etc.
  • Information about the way (mostly tags).
The steps of evaluation are:
  1. get concrete values for everything expressed with conditional tags. To do this, you evaluate the conditions using the user input (for example, you need to find out whether the normal or hgv tolls apply). As a result, you will have unambiguous information about the way (toll amounts to 2,61€).
  2. use the user input again (as well as the information about the way determined in step #1) to find out whether the way is usable and whether it is desirable. For example, you compare the way's toll with the maximum amount the user is willing to spend.
These steps need to be performed for all criteria relevant for desirability and usability of a way (access restrictions, clearance and width of the way, etc.).
To sum this up: Your examples are about adding additional criteria, whereas this proposal is about introducing the additional evaluation step #1. --Tordanik 18:45, 29 July 2009 (UTC)

Move parameters from key to value

To me it seems much more logical to put parameters into the value. This would mean that programs using the data suddenly don't have to try to interpret all the tags, but just have one tag to get all the data from. I'm thinking along the lines of: maxspeed=70;[time=07:00-12:00]50 (maximum speed is 70, except between 7 and 12 o'clock, then it's 50) or maxweight=[goods]7.5 which would be equivalent with goods=[weight=+7.5]no (or even access=[goods and weight=+7.5]no), but the latter could allow more like goods=[weight=+3.5]delivery;[weight=+7.5]no. But this is quickly thought out syntax, it may have problems.

But it just fits much better in the key=value tag syntax compared to putting the values in the keys.

Other random examples: oneway=yes;[bicycle or moped]no when a street isn't oneway for bicycles or mopeds. maxspeed=120;[wet]90. overtaking=[weight=+3.5]no.

The only downside I can think of is that programs now have to be able to read such a value. But I actually don't see that as a downside, because when you keep the basic key=value tag like maxspeed=50, and programs would discard all other tags with extra modifiers, it would in many cases display wrong information. --Eimai 12:55, 30 July 2009 (UTC)

I understand why you think this is a good idea, and I have to admit that it is more in line with key-value semantics.
However, there is something that needs to be considered, too: Ease of editing. Using keys has the advantage that information can be split to several tags, whereas the values created by your suggestion will be very long, such as
maxspeed = 200; [hgv]120; [hgv][Sa,Su 8:00-18:00]80
(or something else depending on syntax, the problem is the same for all solutions that require a single tag to be used for all maxspeeds)
I personally find this hard to read. We also need to consider that editors tend to limit the length of keys/values displayed at once, whereas displaying mulitple tags is usually possible with the UI. It's important for me to make this concept as easy to use as possible without any editor support. I believe that this is the only possiblity of establishing the proposal as a consistently used solution.
I might be wrong, of course, so I'd like to hear your honest opinion: Do you believe that your suggestion will achieve the same ease of use for mappers without advanced editor support that is possible with my key-based solution? --Tordanik 13:18, 31 July 2009 (UTC)
I personally don't consider all-in-one isn't harder to read. An editor could as well easily miss one if it's done with multiple tags. Given the readability I consider them at the same level.
My concerns with the "key[parameters]=value" syntax is that:
(a) without the support to read those values, programs will often get plain wrong data, given there will most likely stay a basic key=value tag as well where it doesn't need parameters. (Unless we solve that by adding an empty condition like maxspeed[]=50 of course when there are other conditional tags on the road...). And given there will stay a basic key=value I doubt that many programs will even try to support the tags with conditions, whereas a syntax with on tag would obviously enforce handling it to get it used.
(b) I'm wondering about conflicts with several key[parameter]=value at the same level. What if there are two tags with parameters that apply to a certain vehicle and the first forbids access while the second one allows it? If everything is in one tag like I propose, there's a given order of tags that can be used to solve the precedence of the values (e.g. the value of the last condition that applies to the vehicle is taken). Where with parallel keys one would think about rules like "the biggest restriction applies" (which doesn't work, or you'd have to very carefully adjust all conditions in some cases) or "the value of the tag with the 'most specific' condition that applies, applies" (define 'most specific', and doesn't work either as you can probably only make a partial order for specificity, and no total order, i.e. some condition wouldn't be more or less specific than another condition).
But I agree here that the tag structure we have now already allows for a lot of ambiguities (maxweight=7.5 and bus=yes for example, so are all buses allowed because it's an exception to the maxweight rule, or only those under 7.5 tons, and was bus=yes just an unnecessary tag?). That last example is on the other hand a nice situation where a conditional tag would solve the ambiguity: maxweight=7.5;[bus]none.
I guess I get to a nice point here with which I'm not happy: because I basically think the current access tags desperately need formal definitions of what they mean exactly. Conditions are nice and all, but a proposal like this doesn't do enough in my eyes to clean up the basic structures it's making use of: the plain access tags. Otherwise we'll make the pile of ambiguities much worse, and if we'd do some formalization later on we'd could end up seeing in future that we didn't pick a good syntax for all of this.
But I think I digress a little bit here now... --Eimai 13:31, 1 August 2009 (UTC)


I don't see (b) as a problem as much as you do. I think that the two rules in the "Evaluating conflicting tags" section of the proposal work well, and I believe that they are in line with the common interpretation of the existing tags: They state independent restrictions, and a road becomes unusable if you fail a single one. (So your example would indeed exclude busses above the maxweight, imo, and any attempts to use "bus=yes" as an exception are simply symptoms of the lack of conditional tagging.) The "exception" to this are, of course, the vehicle classes, because for them, a hierarchy can be defined. I therefore tend to think of them as (disguised) conditional access tags (where motorcar=yes is actually a short form of access[motorcar]=yes).
I fail to see why you think that 'most specific' as a criterion does not work. Interpreting the conditions as simple AND-connected boolean terms, you can easily define "a is more specific than b" as "the conditions of a imply the conditions of b". Of course that's only a partial order, but that's why rule #2 exists. If rule #2 does not result in what's correct for the situation at hand, you need to add an additional tag (for example, if the maxspeed for hgv on a wet road isn't the minimum of maxspeed[hgv] and maxspeed[wet] for some reason, you need to set maxspeed[hgv][wet], which is more specific than both).
As far as (a) goes, this a disadvantage of your suggestion, imo. Overwriting existing values that are "almost correct" will cause unnecessary conflicts between mappers, which will reduce the concept's acceptance. Applications will not support conditions from the start (and some even cannot support them, because they rely on existing software - such as the Garmin maps). And many conditions are, after all, irrelevant for an average motorcar or even bicycle user, so for them, the current values aren't "wrong". The conditions are, from that perspective, additional details, and additional details should never "break" simpler applications if it can be avoided.
About the "formal definitions" topic: I fully agree that unambiguous definitions for access evaluation are very desirable (even if I think that human-readable definitions + a reference implementation with test cases would be much more useful than a formal definition). However, while I'd be willing to help create such definitions, this isn't an easy task and would require a coordinated effort as well as support of developers of major routing applications. --Tordanik 18:01, 1 August 2009 (UTC)

Lighting condition

Resolved

It would make more sense to me to extend the opening_hours syntax for this, rather than making it a special category here. Opening_hours would then profit from it as well and it would make this proposal a tiny bit lighter. Other possible values for opening_hours would include "sunset", "sundown", "night", "day". I've seen paths in parks here that have opening hours like "two hours before sunrise to two hours after sunset", so that's only possible with some opening_hours syntax. --Eimai 19:24, 2 August 2009 (UTC)

This is a good idea. opening_hours should allow for those cases, simply because they exist in reality - even though it will become even harder to fully support opening_hours in applications. (I've recently attempted to implement opening_hours evaluation, but postponed it because it was taking too long; it's already quite complex.) And if opening_hours supports them, it's of course not necessary for this to have its own category here, so once there is a proposal for an opening_hours extension, I'll link to it instead.
Are you going to set up the proposal for this? --Tordanik 15:46, 4 August 2009 (UTC)

Seasonal

What about seasonal access? There are a lot of roads/cycleways/footways etc that can't be used during winter, for example. Sometimes this is indicated by a sign, sometimes not but is obvious. Also, sometimes access tags change for the winter when footway can only be accessed by skis or snowmobiles etc.

Depends on how you define "seasons". Do you refer to time intervals (e.g. December to February) or weather/road condition (e.g. snow)? Time intervals are covered by #time. For road conditions, we would need to find some appropriate new entries for #road condition besides wet. --Tordanik 09:05, 22 August 2009 (UTC)

Syntax Poll (Archived)

Resolved

As a first step, let's find out whether the colon syntax (:) or bracket syntax ([...]) is more popular. Please add your signature (--~~~~) to the appropriate section.

I prefer the colon syntax

  1. --Markus 21:45, 17 June 2009 (UTC) The colon is much more usual, and less costly.
  2. --josias 19:56, 28 July 2009 (UTC)

I prefer the bracket syntax

I prefer something else

  • I prefer a real relational DB, or at least real hierarchical tags --Markus 07:24, 18 June 2009 (UTC)
    • Hierarchical tags, now that's also an interresting idea! In the OSM file format (which is XML) tags are already elements, so they could easily have child tags. So you would be "tagging the tags" :-) --Renaud 21:21, 31 July 2009 (UTC)
  • Keys should be constant, and values should tagged as values --abunai 19:34, 20 June 2009 (UTC)
    • I agree with abunai. And, for the keys, I prefer the colon version. --Sebastiaan 14:01, 19 August 2009 (UTC)
    • i second that. if there are time based conditions, the time period should first be defined in a separate key/value entry and then be referenced in the condition entry itself. see my take on a new access/conditions scheme --Flaimo 12:16, 25 April 2011 (BST)
  • aren't you mixing keys and values? why not colon for keys and braquets for values > eg. maxspeed:hgv=100 > eg. maxspeed:hgv[22:00-06:00]=90 > eg. maxspeed[wet]=80 --Sergionaranja 18:52, 28 July 2009 (UTC)

I don't care

Maybe some lower level solutions for time conditions?

I see that there problem with time conditions. I don't know much about backend of OSM, but i think some extended conditions could be implement in lower level of system and be much more effective. For example tags time of activation and deactivation, this would not only work for restriction, but also for example:

  • Time conditions for restrictions (duh?)
  • Planed road closings for constructions and there openings (by time conditioning of construction = yes tag)
  • Openings and shot demolitions or mark them as unused of buildings
  • Practically everything that is planned to happen in future

I seen that map data is based on XML something like that: 

<tag key="here" value="here" />

Time solution would add additional time attributes to this tag, here few examples: 

<tag key="here" value="here" valid_from="02.02.2010" valid_to="06.03.2010" />
<tag key="speedmax" value="60" hour_on="10:00" hour_off="16:00" />
<tag key="speedmax" value="60" valid_only_in="Friday" />

....and i would allow to add more tag available on specific timings. Something like that. This could not only used for tag but also members, tags, nodes, ways, areas etc.

Rendering software would ignore currently invalid data it or put as part of data for regular time conditions (depending on keys, effect tag would be rendered but marked as temp.) as or use that invalid data as historical data (Eventually this would allow to build historical maps!), as placing on objects creation date from past as validation start attribute.

As i said i don't know much about OSM back-ends and i know it's very deep topic to discuss, but i only throw solution idea for time conditions -Shadowriver 00:22, 10 February 2010 (UTC)

I don't doubt that, by changing the API, it would be possible to implement conditions more elegantly. The proposal is designed to work with current API abilities - if you manage to convince the API developers to add attributes for tags, tag groups, or a similar feature, I'd be happy to use it for condition tagging. However, I'm not able to change anything about API, and I don't think anyone who is able to do so reads this talk page.
About your concept: I'm not convinced that time is anything special when it comes to OSM tagging. You could use similar arguments for adding useable_by_bicycle="yes" attributes to tag elements, for example. Why does time require special handling? --Tordanik 13:17, 10 February 2010 (UTC)
Well all condtions could be moved to new hendling :) -Shadowriver 15:07, 11 February 2010 (UTC)
This would require a change to the API each time someone defines a new condition. The OSM format is, however, intentionally designed to allow users to invent new tagging schemes on their own, without a central authority that checks and implements them. Integrating certain features directly into the API would therefore be a fundamental paradigm shift - it's unlikely that this will happen, especially for something as new and rare (in comparison) as conditions. --Tordanik 18:28, 12 February 2010 (UTC)
Ehhh whatever, imo i think tag is not enough here, software might have problem even with tag conditions -Shadowriver 22:37, 12 February 2010 (UTC)

If the API (and the database scheme!) will be changed why not introducing "composite tags" or "tag groups" similar to the concepts of the "composite attributes" in GDF where time and vehicle type dependencies are combined with various attributes? A tag group can combine all restrictions as a series of tags, e.g., can combine the access restriction with a time restriction and a vehicle type restriction. If there are more combinations, more tag groups can be given. To simplify the transition of the current "flat tagging" scheme and this extended scheme, a single tag can be handled as if there is a logical tag group around it. The example above: 

<taggroup>
  <tag key="here" value="here" />
  <tag key="valid_from" value="02.02.2010" />
  <tag key="valid_to" value="06.03.2010" />
</taggroup>
<taggroup>
  <tag key="speedmax" value="60" />
  <tag key="hour_on" value="10:00" />
  <tag key="hour_off" value="16:00" />
</taggroup>
<taggroup>
  <tag key="speedmax" value="60" />
  <tag key="valid_only_in" value="Friday" />
</taggroup>

This allows any possible combination of tags. --BerndR 08:38, 29 April 2010 (UTC)

Tag groups would be a good solution for the problem this proposal is trying to solve. Unlike Shadowriver's attributes for tags, they would be flexible enough to allow various uses - for example, they could also be useful for lanes.
So if you manage to convince the API devs to include that feature, I'd support using them for conditional restrictions. Until then, we will have to use a syntax like the one from this proposal - however, it would be possible to automatically convert it into tag groups when those are available. --Tordanik 10:25, 29 April 2010 (UTC)
I'd say that we already have a structure for tag groups: relations. But relations can go further and have more than one way in it with those tags -- and that's also a good thing if you have a lot of ways with the same restrictions. So I'd say we really don't need a new thing called tag groups, just better handling of relations in the editors. --Eimai 10:52, 29 April 2010 (UTC)
See Relations/Proposed/Composite Tag for this proposal to use relations for grouping tags. --BerndR 13:54, 29 April 2010 (UTC)
The problem is that we have been waiting for "better handling of relations in the editors" for quite some time now, and relation handling is still horribly complicated. Personally, I believe that relations are too powerful to be displayed in an user-friendly way.
For example, we could theoretically replace ways with relations. That's because the features of ways are a subset of the features of relations: contain an ordered sequence of nodes and carry tags. But that wouldn't be a good idea at all, because precisely due to their limited features, ways can be naturally displayed in an editor as a line between two-dimensional points, whereas a general relation cannot be displayed in that manner. Similarly, a tag group can easily be integrated in a GUI (e.g. as a foldable list of tags), which likewise isn't possible if you have to deal with the other features of relations. That's why identifying certain useful subsets of relations' features and intentionally using these less powerful tools could solve the usability problem caused by relations. --Tordanik 14:19, 29 April 2010 (UTC)
Yes, relations are very powerful, and editors don't want to hide any of that power away yet (and they shouldn't anyway if a mapper doesn't want it to be hid). What needs to happen is special handling of different relation types. And this tag group idea would just be another relation type. It's not worth it to redesign the entire database structure, if the current structure can handle it all very well already. It would be way too much trouble if the only thing you want is forcing editors to handle this concept in a user-friendly way. It's much easier to just change the editors so they would show the tag group relations as a foldable list of tags without having to change the entire database structure, and consequently everything else that does something with OSM data. --Eimai 10:50, 30 April 2010 (UTC)
If a tag group is just a convention, rather than something enforced by the API, the editor will have to deal with tag groups that don't fit the convention. What would you expect the editor to do with a tag group relation that e.g. assigns roles to the members? Delete that information without notice? Block the user from editing the tag group? Break the user-friendly façade and confront the user, who might not be aware of the internal representation of tag groups at all, with confusing error handling? I don't know a good way to deal with that.
It's also understandable that we don't want to change every tool using OSM. However, this means that the model presented to the user will be inconsistent: Only some tools will support the convention. For example, not modifying the history tools will mean that a change to a tag group will not show up in the object's history, whereas changes to individual tags, of course, will. The same can be said for all other tools used by mappers - if there are tools that treat tag groups like any other relation, then the representation of tag groups isn't just an implementation detail, but part of the user interface.
Of course it might be a good idea to prove the usefulness of tag groups using a relation-based implementation before debating API level support. --Tordanik 15:48, 30 April 2010 (UTC)
How do the special editors I've heard about (but never used) for restriction relations handle it when they encounter a relation that doesn't follow the convention? Probably the only way possible would be to fall back to raw relation editing -- the person who edited the relation so it doesn't comply with the convention anymore was editing it the raw relation as well, since the specialized tools wouldn't allow it.
The argument about having to change the history tools: well, that's a problem of relations, and should be fixed anyway. It's not a specific problem for a tag group relation.
Also, everything you say would just apply to other relation types as well, like route relations, or multipolygon relations for example: they also have conventions. So if you want tag groups as a special database structure, why would these relations not have their own structure as well instead? It would certainly help reducing broken route relations, but if we go that way, where does it stop? And if someone comes up with a new relation type, we can start modifying the entire OSM tool chain again to cater for it? --Eimai 11:35, 1 May 2010 (UTC)

Name

Resolved

I am not happy with condistion as name because I think it is to close on weather conditions and does not cover access-restrictions based on daytime or date. --Skyper 11:45, 8 July 2010 (UTC)

As I've also explained on the tagging mailing list[1], the name doesn't have anything to do with weather conditions. It is based on a different meaning of "condition": logical phrases that can either be true or false. If the road is wet, then :wet is true, otherwise it's false. If it is Saturday or Sunday, then :Sa,Su is true, otherwise it's false, and so on. When evaluating these tags in software, you would search for tags where all the conditions are true. --Tordanik 15:18, 8 July 2010 (UTC)

Merge with restriction=school_zone

Resolved

I think we should try to merge this proposal with Proposed_features/Tag:restriction=school zone. Anyway please add a link. --Skyper 11:45, 8 July 2010 (UTC)

I don't even understand the reason for creating the school zone proposal - what's so special about that single use case? Everything restriction that can be expressed with "school zone" can easily be expressed with this proposal, but definitely not the other way round. My current suggestion for "merging" the proposals would therefore be to close the school zone proposal and use extended conditions instead. --Tordanik 15:19, 8 July 2010 (UTC)
That solution would be alright for me. Maybe, we can give the relation a name to better distinguish between several. This could be "school_zone [<schoolname>]" for example.--Skyper 15:19, 11 July 2010 (UTC)

Splitting conditions and values

I want to suggest a more generic approach, which would allow to specify conditions for all existing keys and would not end up with endless keys or values. Lets put the condition in a separate tag: 

 conditional=<condition>

If we have more than one condition we give them names or numbers: 

 conditional(1)=<condition>
 conditional(name)=<condition>

(Maybe something else than brackets would be preferable)

If we need a conditional key/value we could write as follows: 

 <key>:conditional=<value>

Or again, if we have more than one condition: 

 <key>:conditional(1)=<value>
 <key>:conditional(name)=<value>

A "condition" could look like this: 

 conditional=<type>(<value>)

For example: 

 conditional=time(08:00-16:00)

If we want to combine conditions we could use special types and therefore stay consistent: 

 conditional(combined)=and(conditional(1), conditional(2))


This would introduce a generic way to specify conditional key/value pairs, which could be useful in many ways. --Imagic 07:11, 23 February 2012 (UTC)

I added an example for time-dependent lanes in my :lanes proposal. --Imagic 08:51, 23 February 2012 (UTC)


I fail to see how this is "more generic". You would at least need to show an example of something that cannot be expressed with my approach. Currently, all I can see is that your proposal is overly complex and looks more like programming language syntax than something designed for use by normal mappers.
Compare the "maxspeed for hgv on wet road" example.
My proposal:
maxspeed:hgv:wet = 60
Your proposal:
maxspeed:conditional(combined) = 60
conditional(combined) = and(conditional(1), conditional(2))
conditional(1) = vehicle(hgv)
conditional(2) = weather(wet)
I think it's apparent from this simple example that your style of tagging introduces unnecessary complexity, and that you pay for limiting the total length of the tags with drastically increasing the number of tags per element. --Tordanik 11:19, 23 February 2012 (UTC)
It was critized, that the condition is included in the key. A criticism I fully support. As you use shortcuts in your scheme, it would also be valid to use it in my suggestion:
 maxspeed:conditional=60
 conditional=and(hgv,wet)
This is still the same suggestion. Yes, you have one tag more, but you don't crowd the condition and the key or value together. If you don't like the and(,) you could of course also use conditional=hgv,wet, but is this now hgv AND wet or is it hgv OR wet? This is not as obvious as and(,). I'm pretty sure, that this can be further improved, because I came up with it in about 20 seconds. --Imagic 12:25, 23 February 2012 (UTC)
Allowing mappers to use values like "hgv" directly as conditions makes your suggestion a bit more realistic.
However, one of the reasons why conditions within the key were criticized was: There would no longer be a finite number of keys relevant for a given application (and could e.g. be filtered for during a database import). The same criticism also applies to your solution of adding index values to keys, because then there would again no longer be a finite number of keys.
If "clean" keys are a major concern, wouldn't a syntax such as
  maxspeed:conditional = [hgv][wet] 60
that has been proposed elsewhere be the best choice anyway? It has a finite number of keys, and all special characters (such as brackets) are in the value. --Tordanik 22:56, 23 February 2012 (UTC)
That's a point - filtering would be harder. Your last suggestion would solve this problem. But I don't like the brackets. What if we need to specify a condition that contains a bracket? Or the value itself contains brackets? It would be hard to read. How about separating (real) value and condition somehow? Something like this:
 maxspeed:conditional = 60 condition:hgv,wet
We introduce the same problem as with the brackets (what if "condition:" is in the value?), but if we define that the conditions start after the last "condition:" the value could contain this text, but the conditions couldn't. But in my opinion, the latter is a much smaller problem then the former.
We still have the problem that we only support "and" conditions. What if we need a condition that applies to hgv OR buses? One solution would be to write out the condition:
 maxspeed:conditional = 60 condition:hgv or bus
I'm not sure if I like this, but it would be very flexible. --Imagic 08:37, 24 February 2012 (UTC)
One more thing: you do know my :lanes proposal. Conditional values are very important when we think of tagging properties for each lane. Using any "one-key approach" we have a serious problem. Actually each value should be present for each lane, so this would result in the following (based on your last suggestion):
 maxspeed:conditional:lanes = [hgv][wet] 60|[hgv][wet] 60|[hgv][wet] 50
Not funny! Now think of more even more lanes.... We could of course specify, that the condition should only be added once, before/after the lanes value:
 maxspeed:conditional:lanes = [hgv][wet] 60|60|50
Very misleading and inconsistent! Now step back and have a look at the two-key approach:
 maxspeed:conditional:lanes=60|60|50
 conditional=and(hgv,wet)
In my opinion this is now clear and consistent. If we need different conditions for each lane, this could be consistently done with:
 maxspeed:conditional:lanes=60|60|50
 conditional:lanes=and(hgv,wet)|hgv|wet
I'm sure that you will run into the same problem, no matter how you solve the "lanes-issue". So I suggest, that we should think of a solution for the conditional keys, which also support lane-tagging. --Imagic 09:22, 24 February 2012 (UTC)
Regarding your first comment: I was mostly illustrating the concept of adding the condition to the value, and was using one of the syntax variants that has been proposed so far. If there are any brackets in the value, then it's of course hard to parse - just like your lane proposal would be problematic if there were any values with "|" in them. But as far as I know, neither | nor [] can usually be found in values.
You have mentioned "or" conditions multiple times now, but we do not need those. Just add two separate conditions that lead to the same value ("if hgv then 60, if bus then 60"). It is always possible to express "or" conditions like that, because of the possibility to transform any boolean expression to Disjunctive normal form.
You can do this, I can do this. Can the casual mappers do this? Or does they even want to? Never forget them. --Imagic 13:36, 1 March 2012 (UTC)
As for lanes: Your example involves conditional maxspeeds for lanes, where each lane's value depends on the same condition, but the actual values for these same conditions are different per lane. This does not seem like a particularly frequent situation. For rare cases like that, it's enough that it is possible to express them, and that's the case here: Either use
  maxspeed:conditional:lanes = [hgv][wet] 60|[hgv][wet] 60|[hgv][wet] 50
as you suggested, or alternatively
  maxspeed:conditional = [hgv][wet] 60
  maxspeed:conditional:lanes = | | [hgv][wet] 50
The last variant also scales well to a higher number of lanes, unless they have yet another different maxspeed (even more unlikely imo!). If tagging is somewhat more verbose in exotic cases like these, but makes handling common cases (where only a single conditional value applies to the entire road) even a bit easier, then it's still a good tradeoff. --Tordanik 03:49, 1 March 2012 (UTC)
What do you think about this:
 maxspeed:conditional = 60 [hgv,wet]
Now we specify, that the condition can be found within the last appearance of square brackets, i.e.
 <anykey>:conditional = <anyvalue, even with []> [condition]
In case of lanes, it would be the last appearance of square brackets within each lane, i.e.
 <anykey>:conditional:lanes = <anyvalue> [condition] | <anyvalue> [condition]
Now square brackets are still possible in the value.
How about creating a proposal with a more fitting name? We are not only talking about access tags here, but about conditions for all keys. --Imagic 13:36, 1 March 2012 (UTC)
Inspired by some of the ideas in this section I have created a new proposal based on constant keys using a ":conditional" suffix. See Proposed_features/Conditional_restrictions. Please comment on the talk page of that proposal. --polderrunner 13:37, 2 August 2012 (BST)

Access key mapping

I'd like to add the following to the proposal:

The proposal primarily applies to the following base keys:

The proposal also applies to other keys which actually map to the access=* base key:

Comments? -- Eckhart 19:50, 10 June 2012 (BST)

It's true that many situations could beexpressed with conditions instead of additional base keys. However, including this list would probably make the proposal more confusing. --Tordanik 17:04, 13 June 2012 (BST)

Parentheses

Resolved

To improve readability and consistency, I'd recommend adding parentheses to all time and vehicle property conditions. i.e.

-- Eckhart 20:35, 10 June 2012 (BST)

Makes sense imo. --Tordanik 16:07, 13 June 2012 (BST)
Okay, I've added them. -- Eckhart 16:38, 13 June 2012 (BST)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Extended_conditions_for_access_tags&oldid=2513794"