Re: [Tagging] [OSM-talk] Tag combinations: amenity and highway
(Added tagging@osm. Isn't this more of a tagging discussion all-in-all?) Should both description and note keys be encouraged especially when using atypical tags/combinations? -Jaakko --Original Message-- From: Maarten Deen To: t...@openstreetmap.org Subject: Re: [OSM-talk] Tag combinations: amenity and highway Sent: Jun 13, 2012 02:01 On 2012-06-12 22:28, Peter Wendorff wrote: 32 (tourist, bus_stop): amenity=tourist is over all only 32 times in the database, so at least I would count amenity=tourist as useless. Could it be meant as a bus stop for tourist/sightseeing busses? Regards, Maarten ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Sent from my BlackBerry® device from Digicel -- Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Reviving the conditions debate
Hi everybody, I want to revive the discussion on how to tag restrictions that depend on certain conditions. My idea is to finalize the proposal described in http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags and finally accept it. The reasons for picking this proposal: * The proposal mostly describes syntax that is already used for tagging, e.g. a maxspeed in a certain direction is almost always tagged as maxspeed:forward, maxspeed:backward * The proposal is intuitive and simple to use: the key of a tag is the base tag + a set of conditions that all have to be true for the key to apply (i.e. logical AND). * The proposal is complete: every logical formula of conditions can be expressed in it (technically, it's pretty similar to disjunctive normal form). * The proposal is consise: it follows the pattern most dominant with road restrictions, namely overriding general restrictions with special restrictions. It normally uses no more than one tag per sign. * The proposal is extensible: the set of conditions is not fixed and can be extended to new conditions. It is possible to set a sane default for new conditions that are experimental. * The proposal is easily implementable: I implemented it in a prototype already. The only real negative aspect that has been mentioned until now: * the proposal puts a lot of information into keys and theoretically allows for an unlimited set of keys. (The reality however shows that those keys tend to be the same, e.g. taginfo shows no less than 335 elements with key maxspeed:(22:00-06:00)). Competing proposals: * http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 - in my opinion a horrible and incomprehensible syntax with arbitrary distinctions, taginfo revealed almost no uses (for example, maxspeed:hgv:wet in the Extended Conditions proposal above is access:lgv?wet.speed in the Access Restrictions 1.5 proposal) Opinions? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 13.06.2012 14:35, schrieb Eckhart Wörner: Hi everybody, I want to revive the discussion on how to tag restrictions that depend on certain conditions. My idea is to finalize the proposal described in http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags and finally accept it. The reasons for picking this proposal: * The proposal mostly describes syntax that is already used for tagging, e.g. a maxspeed in a certain direction is almost always tagged as maxspeed:forward, maxspeed:backward * The proposal is intuitive and simple to use: the key of a tag is the base tag + a set of conditions that all have to be true for the key to apply (i.e. logical AND). * The proposal is complete: every logical formula of conditions can be expressed in it (technically, it's pretty similar to disjunctive normal form). * The proposal is consise: it follows the pattern most dominant with road restrictions, namely overriding general restrictions with special restrictions. It normally uses no more than one tag per sign. * The proposal is extensible: the set of conditions is not fixed and can be extended to new conditions. It is possible to set a sane default for new conditions that are experimental. * The proposal is easily implementable: I implemented it in a prototype already. The only real negative aspect that has been mentioned until now: * the proposal puts a lot of information into keys and theoretically allows for an unlimited set of keys. (The reality however shows that those keys tend to be the same, e.g. taginfo shows no less than 335 elements with key maxspeed:(22:00-06:00)). Competing proposals: * http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 - in my opinion a horrible and incomprehensible syntax with arbitrary distinctions, taginfo revealed almost no uses (for example, maxspeed:hgv:wet in the Extended Conditions proposal above is access:lgv?wet.speed in the Access Restrictions 1.5 proposal) Opinions? I think your example: access:weight5.5 = destination should be changed into something like maxweight:destination=*. This seems to be more logical and equal to your other examples. There is also an actual proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_Restrictions Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 Eckhart Wörner ewoer...@kde.org: Competing proposals: * http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 - in my opinion a horrible and incomprehensible syntax with arbitrary distinctions, taginfo revealed almost no uses (for example, maxspeed:hgv:wet in the Extended Conditions proposal above is access:lgv?wet.speed in the Access Restrictions 1.5 proposal) In my opinion the 1.5 proposal is not that horrible. The syntax is quite complicated so that no mere mortal will ever understand it and we would need quite some editor support there. But is also seems to be more flexible and powerful. However your example access:lgv?wet.speed is a good one against the 1.5 proposal. But why not combine those proposals? This would result in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the question mark) weather is WET is Sound reasonable to me. To me the 1.5 proposal shows a good idea how to introduce conditions, but I would not force everything in the access-namespace. From an academic point of view the 1.5 this would be consistent, from a practical point of view it would complicate things too much. IMO ;-) Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 13.06.2012 15:07, Martin Vonwald wrote: 2012/6/13 Eckhart Wörner ewoer...@kde.org: Competing proposals: * http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 - in my opinion a horrible and incomprehensible syntax with arbitrary distinctions, taginfo revealed almost no uses (for example, maxspeed:hgv:wet in the Extended Conditions proposal above is access:lgv?wet.speed in the Access Restrictions 1.5 proposal) In my opinion the 1.5 proposal is not that horrible. The syntax is quite complicated so that no mere mortal will ever understand it and we would need quite some editor support there. But is also seems to be more flexible and powerful. Can you give a concrete example where it is actually more powerful? Something that can be expressed with restrictions 1.5, but not with the extended conditions syntax? (Yes, it lists more of the same - more vehicle types, more groups of users, more weather conditions and so on. But that's not what I mean. These things don't have anything to do with the syntax.) However your example access:lgv?wet.speed is a good one against the 1.5 proposal. But why not combine those proposals? This would result in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the question mark) weather is WET is Sound reasonable to me. More reasonable than access:lgv?wet.speed, yes. But how is it easier than maxspeed:hgv:wet? Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 13/06/2012 14:36, David Earl wrote: http://www.frankieandshadow.com/xref/byway.jpg BTW, this means I can use this road at all times as a cyclist, even when the barrier is locked shut, whatever the other restrictions on motor vehicles are. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 Tobias Knerr o...@tobias-knerr.de: Can you give a concrete example where it is actually more powerful? For example the self-defined conditions. Not elegant in my opinion, improvable, but quite nice! Something that can be expressed with restrictions 1.5, but not with the extended conditions syntax? (Yes, it lists more of the same - more vehicle types, more groups of users, more weather conditions and so on. But that's not what I mean. These things don't have anything to do with the syntax.) However your example access:lgv?wet.speed is a good one against the 1.5 proposal. But why not combine those proposals? This would result in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the question mark) weather is WET is Sound reasonable to me. More reasonable than access:lgv?wet.speed, yes. But how is it easier than maxspeed:hgv:wet? Simply because it uses different separators for different purposes. The : is used often for subkeys. It is not a good choice here. The 1.5 uses the ? in front of the condition. So it is obvious where the condition starts. IMO a good approach. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi David, Am Mittwoch, 13. Juni 2012, 14:47:09 schrieb aighes: I think your example: access:weight5.5 = destination should be changed into something like maxweight:destination=*. This seems to be more logical and equal to your other examples. First, I did not write the proposal, someone else did a long time ago. :-) Second, in principle I fully agree with you, destination is a condition. Technically, the tag: access:(weight5.5)=destination is equivalent to these two tags: access:(weight5.5)=no access:(weight5.5):destination=yes However, destination as a value for access has been in use for quite some time, and I don't want to deprecate it (right now). The same goes for delivery, forestry, … I have written down some lines on how to interpret legacy tagging in the comments. There is also an actual proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_Restrictions I've just learnt about this proposal, which is brand new. Most parts are the same, however, it has some new ideas I really don't like: * It assumes access is the default, and e.g maxweight is a completely different beast. It isn't: maxweight=7.5 is just a shorter way of saying access:(weight7.5)=no. (Again, I don't want to deprecate the maxweight key (right now). * It invents new values, e.g. oneway[:…]=forward. The Extended Conditions proposal tries to invent as little as possible. * It tries to incorporate the lanes proposal, and I'm not sure that's a good idea. Extended Conditions are certainly a necessary building block for lane dependent conditions, but that's a different story. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 Eckhart Wörner ewoer...@kde.org: *snip* access:(weight5.5):destination=yes *snip* This is a good example of a bad choice of separators. Because (weight5.5) and destination are both conditions, but if I don't know that they are conditions, I have no chance of figuring it out. If you use a different character (like the ? in the 1.5) it would be clear where the conditions start. There is also an actual proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_Restrictions I've just learnt about this proposal, which is brand new. Most parts are the same, however, it has some new ideas I really don't like: Didn't know about that too. And it has the same problem: maxspeed:lanes:hgv:wet=60|50|40 Where does the condition begin? Again this is not obvious. Small change: maxspeed:lanes?hgv:wet=60|50|40 Now it is clear. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 13.06.2012 16:12, schrieb Martin Vonwald: 2012/6/13 Eckhart Wörnerewoer...@kde.org: *snip* access:(weight5.5):destination=yes *snip* This is a good example of a bad choice of separators. Because (weight5.5) and destination are both conditions, but if I don't know that they are conditions, I have no chance of figuring it out. If you use a different character (like the ? in the 1.5) it would be clear where the conditions start. For me the system is clear. basekey:condition_1:condition_2:...:condition_n=value. I think maxweight is an already used basekey and maximum weight is also a part of access. So it should be used like maxspeed, maxheight etc. Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 aighes o...@aighes.de: I think maxweight is an already used basekey and maximum weight is also a part of access. So it should be used like maxspeed, maxheight etc. +1 instead of access:(weight5.5)=no the established tagging is maxweight=5.5 or maxweight=5.5t cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Martin, Am Mittwoch, 13. Juni 2012, 15:47:12 schrieb Martin Vonwald: For example the self-defined conditions. Not elegant in my opinion, improvable, but quite nice! The only advantage of self-defined conditions is that you can remove some redundancy when two tags contain the same subset of conditions, e.g. applies in situations like this: maxspeed:hgv:(weight7.5):(Mo-Fr 08:00-16:00):forward=50 maxspeed:hgv:(weight7.5):(Mo-Fr 08:00-16:00):backward=30 In this case one could somehow define: heavy_trucks_during_week ≔ hgv:(weight7.5):(Mo-Fr 08:00-16:00) And then write the tags as: maxspeed:heavy_trucks_during_week:forward=50 maxspeed:heavy_trucks_during_week:backward=30 I'm not sure that's a real improvement (note that with the Access Restrictions 1.5, the definition of heavy_trucks_during_week is slightly more complex.) However your example access:lgv?wet.speed is a good one against the 1.5 proposal. But why not combine those proposals? This would result in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the question mark) weather is WET is Sound reasonable to me. More reasonable than access:lgv?wet.speed, yes. But how is it easier than maxspeed:hgv:wet? Simply because it uses different separators for different purposes. The : is used often for subkeys. It is not a good choice here. The 1.5 uses the ? in front of the condition. So it is obvious where the condition starts. IMO a good approach. The : is always used for subkeys, because that's the definition of a subkey. I'm not sure what you want to express here. About different purposes: hgv is just short for I'm driving a heavy goods vehicle, i.e. just another condition (that can be evaluated to true or false). Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 aighes o...@aighes.de: For me the system is clear. basekey:condition_1:condition_2:...:condition_n=value. How about this: http://wiki.openstreetmap.org/wiki/Key:parking:lane The basekey is parking:lane. How do you know that lane is not a condition? I think maxweight is an already used basekey and maximum weight is also a part of access. So it should be used like maxspeed, maxheight etc. Sorry, missed your point here.. ? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 13.06.2012 16:30, schrieb Martin Vonwald: 2012/6/13 aigheso...@aighes.de: For me the system is clear. basekey:condition_1:condition_2:...:condition_n=value. How about this: http://wiki.openstreetmap.org/wiki/Key:parking:lane The basekey is parking:lane. How do you know that lane is not a condition? Yes...but there is the problem? If you search for information for parking:lane, you can remove this string from the key and all conditions will left. I think maxweight is an already used basekey and maximum weight is also a part of access. So it should be used like maxspeed, maxheight etc. Sorry, missed your point here.. ? I think it isn't useful to have a new key for restriction based on weight. maxweight is already established. Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 aighes o...@aighes.de: Am 13.06.2012 16:30, schrieb Martin Vonwald: 2012/6/13 aigheso...@aighes.de: For me the system is clear. basekey:condition_1:condition_2:...:condition_n=value. How about this: http://wiki.openstreetmap.org/wiki/Key:parking:lane The basekey is parking:lane. How do you know that lane is not a condition? Yes...but there is the problem? If you search for information for parking:lane, you can remove this string from the key and all conditions will left. The problem is that you don't have a clear separation between key and condition. In my opinion it would improve readability for people (not programs) if we separate those two clearly. I think maxweight is an already used basekey and maximum weight is also a part of access. So it should be used like maxspeed, maxheight etc. Sorry, missed your point here.. ? I think it isn't useful to have a new key for restriction based on weight. maxweight is already established. That's why I missed your point: I agree with you ;-) Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 Tobias Knerr o...@tobias-knerr.de: On 13.06.2012 16:12, Martin Vonwald wrote: If you use a different character (like the ? in the 1.5) it would be clear where the conditions start. That's a valid argument, but we need to be aware that there is already a lot of existing tagging that uses a colon as the condition separator. These are usually examples with just a single condition, things like maxspeed:wet, :hgv, Correct. And for the sake of compatibility I would never-ever touch them. :forward, :backward, ... I don't think of them as conditions, but more a selection of a part of a way. Just like :lanes is to me not a condition. I also doubt whether the distinction between a subkey and a condition would always be obvious to mappers. Didn't know about that too. And it has the same problem: maxspeed:lanes:hgv:wet=60|50|40 Where does the condition begin? Again this is not obvious. Small change: maxspeed:lanes?hgv:wet=60|50|40 That's interesting, I would have assumed that the tag should look like maxspeed:hgv:wet:lanes to allow for per-lane fallbacks. Is lanes a condition? I don't think so. To me it's a subkey. So we should always have basekey:subkey1:subkey2?condition1:condition2=value For example, if there is only one lane that changes maxspeed when wet, one might want to write that as follows: maxspeed:lanes = 80|80|80 maxspeed:lanes?wet = ||50 I would instead use maxspeed=80 for the first tag. Simpler. Compatible. Yes, you could evaluate this without any knowledge about the semantics of the base key. But doing so would result in the value of 'maxspeed:lanes' is '||50' when the road is wet. That's not actually what we want - we do want the keep the '80' for the first two lanes. Actually it is what we want. Because: 1) Either the application knows, what :lanes means. Then the value of 'maxspeed:lanes' is '||50' when the road is wet means that the first two lanes don't change the maxspeed value if the road is wet, but the third changes it to 50. 2) Or the application does not know what :lanes mean. Then it also has no clue what maxspeed:lanes is and ignores it. To me it seems perfectly consistent. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Tobias, Am Mittwoch, 13. Juni 2012, 17:05:34 schrieb Tobias Knerr: For example, if there is only one lane that changes maxspeed when wet, one might want to write that as follows: maxspeed:lanes = 80|80|80 maxspeed:lanes?wet = ||50 I would go even further and mandate that lane-independent information should not be hidden in lane-dependent tagging, i.e.: maxspeed=80 maxspeed:lanes:wet = ||50 Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 Martin Vonwald imagic@gmail.com: The problem is that you don't have a clear separation between key and condition. In my opinion it would improve readability for people (not programs) if we separate those two clearly. I tend to agree with Tobias here: it is not always clear whether it is a condition or a subkey. hgv for instance could be interpreted as condition (if you are in a heavy goods vehicle) or as a subkey (vehicle class), and looking at the examples in this thread mappers do choose one of these two but not always the same. I guess in the end you won't be able to rely on this distinction. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 13.06.2012 17:07, schrieb Martin Vonwald: 2012/6/13 aigheso...@aighes.de: Am 13.06.2012 16:30, schrieb Martin Vonwald: 2012/6/13 aigheso...@aighes.de: For me the system is clear. basekey:condition_1:condition_2:...:condition_n=value. How about this: http://wiki.openstreetmap.org/wiki/Key:parking:lane The basekey is parking:lane. How do you know that lane is not a condition? Yes...but there is the problem? If you search for information for parking:lane, you can remove this string from the key and all conditions will left. The problem is that you don't have a clear separation between key and condition. In my opinion it would improve readability for people (not programs) if we separate those two clearly. Ok human readability is a good point. But works only til we have a key like foo?bar=* ;-) Also a :: would be possible. Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/13 aighes o...@aighes.de: Ok human readability is a good point. But works only til we have a key like foo?bar=* ;-) I use this key now for a year or so for various data. I'm writing an article about it in the next days ;-) Also a :: would be possible. Possible: yes. Better? Think of a:b:c:d=x and a:b?c:d=x . Where do you spot the condition faster? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 13.06.2012 17:18, Martin Vonwald wrote: :forward, :backward, ... I don't think of them as conditions, but more a selection of a part of a way. Just like :lanes is to me not a condition. I think we've discussed this several times already, and as you know I do not think this part of a way interpretation of forward/backward is appropriate. You could easily place signs with different restrictions for each direction on a one-lane road. I also doubt whether the distinction between a subkey and a condition would always be obvious to mappers. As promptly illustrated by the fact that we can't even agree that forward/backwards are conditions. Is lanes a condition? I don't think so. I don't think so either. The point I was trying to make was a different one, as I'm trying to explain below. For example, if there is only one lane that changes maxspeed when wet, one might want to write that as follows: maxspeed:lanes = 80|80|80 maxspeed:lanes?wet = ||50 I would instead use maxspeed=80 for the first tag. Simpler. Compatible. Yes. Simpler, compatible and all that, but irrelevant for the example. Yes, you could evaluate this without any knowledge about the semantics of the base key. But doing so would result in the value of 'maxspeed:lanes' is '||50' when the road is wet. That's not actually what we want - we do want the keep the '80' for the first two lanes. Actually it is what we want. Because: 1) Either the application knows, what :lanes means. Then the value of 'maxspeed:lanes' is '||50' when the road is wet means that the first two lanes don't change the maxspeed value if the road is wet, but the third changes it to 50. [...] To me it seems perfectly consistent. This means I didn't explain well enough. Let's update the example to make this more clear: maxspeed=80 maxspeed:lanes = 60|80|80 maxspeed:lanes?wet = ||50 First step: Evaluate the conditions without regard for the semantics of the rest of the keys. wet is true, so this tagging changes to maxspeed=80 maxspeed:lanes = ||50 for the purpose of further evaluation. Remember: We did not take the semantics of maxspeed:lanes into account here, instead we relied on the ? separator to treat the front part of the keys in a generic way. This means that the maxspeed for the first lane will be 80 - there is no lane-specific value, so the road's general maxspeed is used. But it should of course be 60. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
For some reason everyone seems determined to come up with the most complex system imaginable, instead of taking successful ideas from the rest of the world. This trait is what causes many projects to fail. Let's not look at this as simply a discussion about access tags, but an opportunity to extend the syntax of the current key-value pair system to include flexible extensibility. How about something like access:expr=expression, where the expression is in some simple syntax and can reference pseudo-variables like time, day, weather, weight, height etc. Why not use a javascript-compatible syntax? Or a bit of XML? No point in re-inventing the wheel. Colin On 13/06/2012 14:35, Eckhart Wörner wrote: Hi everybody, I want to revive the discussion on how to tag restrictions that depend on certain conditions. My idea is to finalize the proposal described in http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags and finally accept it. The reasons for picking this proposal: * The proposal mostly describes syntax that is already used for tagging, e.g. a maxspeed in a certain direction is almost always tagged as maxspeed:forward, maxspeed:backward * The proposal is intuitive and simple to use: the key of a tag is the base tag + a set of conditions that all have to be true for the key to apply (i.e. logical AND). * The proposal is complete: every logical formula of conditions can be expressed in it (technically, it's pretty similar to disjunctive normal form). * The proposal is consise: it follows the pattern most dominant with road restrictions, namely overriding general restrictions with special restrictions. It normally uses no more than one tag per sign. * The proposal is extensible: the set of conditions is not fixed and can be extended to new conditions. It is possible to set a sane default for new conditions that are experimental. * The proposal is easily implementable: I implemented it in a prototype already. The only real negative aspect that has been mentioned until now: * the proposal puts a lot of information into keys and theoretically allows for an unlimited set of keys. (The reality however shows that those keys tend to be the same, e.g. taginfo shows no less than 335 elements with key maxspeed:(22:00-06:00)). Competing proposals: * http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 - in my opinion a horrible and incomprehensible syntax with arbitrary distinctions, taginfo revealed almost no uses (for example, maxspeed:hgv:wet in the Extended Conditions proposal above is access:lgv?wet.speed in the Access Restrictions 1.5 proposal) Opinions? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 13.06.2012 um 17:45 schrieb Tobias Knerr o...@tobias-knerr.de: This means I didn't explain well enough. Let's update the example to make this more clear: maxspeed=80 maxspeed:lanes = 60|80|80 maxspeed:lanes?wet = ||50 First step: Evaluate the conditions without regard for the semantics of the rest of the keys. wet is true, so this tagging changes to maxspeed=80 maxspeed:lanes = ||50 for the purpose of further evaluation. Remember: We did not take the semantics of maxspeed:lanes into account here, instead we relied on the ? separator to treat the front part of the keys in a generic way. This means that the maxspeed for the first lane will be 80 - there is no lane-specific value, so the road's general maxspeed is used. But it should of course be 60. To me your evaluation is correct and your tagging is wrong. Any :lanes-tag specifies the values for all lanes for the basekey. If a lane value is omitted the general (i.e. non-lane) value applies. So the tagging should be: maxspeed=80 maxspeed:lanes = 60|80|80 maxspeed:lanes?wet = 60|80|50 or using default values: maxspeed=80 maxspeed:lanes = 60|| maxspeed:lanes?wet = 60||50 And finally: don't get me wrong! I really don't care a lot if it is a:b:c=x or a:b?c=x or whatever. As long as most people can live with it, use it and applications support it I'm fine with everything. I just throw my opinions in the ring, hope that many join and we find a good and accepted solution. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 13.06.2012 um 18:11 schrieb Colin Smale colin.sm...@xs4all.nl: For some reason everyone seems determined to come up with the most complex system imaginable, That's simply because everyone has a solution that is better than all other solutions ;-) Let's not look at this as simply a discussion about access tags, but an opportunity to extend the syntax of the current key-value pair system to include flexible extensibility. That's also what I hope we can achieve here. How about something like access:expr=expression, where the expression is in some simple syntax and can reference pseudo-variables like time, day, weather, weight, height etc. Why not use a javascript-compatible syntax? Or a bit of XML? No point in re-inventing the wheel. Can you provide one or two examples? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 13/06/2012 18:23, Eckhart Wörner wrote: Hi Colin, Am Mittwoch, 13. Juni 2012, 18:11:53 schrieb Colin Smale: For some reason everyone seems determined to come up with the most complex system imaginable, instead of taking successful ideas from the rest of the world. This trait is what causes many projects to fail. Let's not look at this as simply a discussion about access tags, but an opportunity to extend the syntax of the current key-value pair system to include flexible extensibility. How about something like access:expr=expression, where the expression is in some simple syntax and can reference pseudo-variables like time, day, weather, weight, height etc. Why not use a javascript-compatible syntax? Or a bit of XML? No point in re-inventing the wheel. my sarcasm detection seems to be broken - are you seriously suggesting JavaScript or XML? Or are you suggesting that the proposal is too complex? Yes, yes, and yes. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 13.06.2012 23:48, Colin Smale wrote: Taking the access discussion to a higher level of abstraction, and without abandoning the key-value pair paradigm, I believe we are looking for a way of giving a tag a value which depends on all kinds of variables. *IMHO* we need a way of making expressions, with operators to combine basic values in different ways. These basic values might be literals, other tags, runtime values or function calls. These functions might be built-in (or assumed) for the most basic stuff, but it would be good if we could define additional user-defined functions. Whatever syntax is used, the *primary* requirement is that it is usable by programs - editors, renderers, routers etc. followed by a secondary requirement that it be understood by humans. Any condition syntax needs to be parsed by programs, this much we should all be able to agree on. As for the secondary requirement, I think that keeping the number of different basic constructs small can help a lot. The resulting micro-language can then be easier to read, and also easier to wrap into a GUI than a language construct that gives the user a lot of freedom. So when we talk about requirements, we should also consider whether there are things we _don't_ need. And imo there are several, such as: - Or operators. Maxspeed is 80 if it's wet or Sunday can be rephrased as Maxspeed is 80 if it's wet. Maxspeed is 80 if it's Sunday. IOW, these can be modelled by using two tags instead of one. - Not operators. These can also modelled by using two tags, and common tagging idioms like access=no + x=yes even do this already. - Brackets for expressions. If we limit ourselves to just and operators, evaluation order doesn't matter. Pseudo-Javascript: (!is_motor_vehicle(vehicle_type)) || ((vehicle_type='hgv') (time'10:00' || time'20:00') intention='loading') So starting from your Pseudo-Javascript example quoted above, we could get to something like is_motor_vehicle(vehicle_type) - no (vehicle_type='hgv') (time'10:00' || time'20:00') intention='loading') - yes It has fewer language constructs, but expresses the same thing - and still fulfils all the requirements. Another aspect to consider is that some of the problems we are trying to solve here have already been tackled elsewhere in OSM. This includes: - defining a syntax for time intervals (opening_hours) - defining a subset hierarchy of vehicle categories (such as motor_vehicle including hgv as a subset) Probably it would make sense to re-use these existing building blocks. This could be done with a small change to the example above: in_vehicle_category('vehicle_type') - no in_vehicle_category('hgv') in_time_interval('20:00-10:00') intention='loading') - yes So how do the existing proposals fit in here? Well, the primary difference between the example above and extended conditions is that the latter aims for for short, manually editable strings by letting literals for vehicle classes, weather conditions etc., as well as time intervals, stand for themselves - based on the assumption that a parser will be able to unambiguously identify them. If we chose to do this for our returning example, it might look like this: motor_vehicle - no hgv 20:00-10:00 loading - yes And that differs from extended condition just in superficial details: motor_vehicle = no hgv:(20:00-10:00):loading = yes Maybe this explains some of the motivations behind the current proposals, and the goals and assumptions and they are based on. Because, yes, understanding these high-level motivations is a necessary first step. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging