Re: [Tagging] Reviving the conditions debate: first summary
Has this discussion died now and awaits re-revival in another two, three years? ;-) Martin 2012/6/15 Eckhart Wörner ewoer...@kde.org: Hi everybody, let me try to summarize some parts of the discussion up to now. Hopefully this won't become too biased: * most people agreed that the syntax of the competing Access Restrictions 1.5 proposal is quite complicated * some people argued that it is important to separate syntax for vehicles (hgv, bicycle, …) and other conditions, however, other people pointed out that hgv could as well represent the condition in a hgv and the distinction between vehicles and other conditions is arbitrary. * most people agreed that every proposal must be complete, i.e. every boolean formula of conditions can be expressed in it * most people agreed that proposal should make the common case easily taggable for humans, however, some people said that editor support is required anyway and therefore the readability for humans does not really matter * some people argued that putting conditions into keys is a bad idea because it allows for an unlimited set of keys, however, other people argued that putting conditions into values is a bad idea because it pollutes the values and might lead to ambiguities, since a value could be anything, including an identifier * some people argued that conditions syntax should look similar to human language, however, other people argued that this would trick mappers into thinking that human language can be used without paying attention to syntax, and others pointed out that that a parser that has to be liberal about what he accepts cannot spot errors anymore * some people argued that any proposal should take existing tagging into account * most people argued that tagging should be human-readable * some people argued that the syntax has to be similar to existing programming languages, however, other people argued that this would just make the syntax more error-prone My favorite: * a lot of people agreed that the Extended Proposals is ... already used...intuitive and simple to use...complete...consise...extensible I would also like to ask people not to blindly start new proposals, because otherwise we'll inevitably end up with hundreds of proposals and no conclusion at all. 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
Colin, Martin, if it walks like a duck and quacks like a duck, then it had better be a duck... What I mean with this, is if the grammar is so English-like such that people are tempted to use constructions which are not (or not quite) supported by the grammar, or if the way it works is contrary to how the English language would interpret it, then errors will occur. Now, the primary intention was to allow to transfer conditions from sign-posted information as natural as possible. Due the fact that space is limited and people must be able to read it during driving, they use a extremely simplified language - mostly nouns plus words like except, if, when, on, then... You don't get a Nobel Prize for Literature for text like except vehicles less than 5m long (also in several variants, e.g. except vehicles with length5m). But nevertheless your point is valid. If we give the impression computer understands sentences, soon or later we will find things like tracktype:cond = grade2 if weather was good for more than 3 days, grade3 after a day of rain, grade4 after a thunderstorm. I haven't taken this into account. Plus, of course, that the majority of users will not have English as their first language, and we have to make this accessible to the man-in-the-street and not allow it to become so obfuscated that only PhD's need apply. As I said, for information (exceptions, conditions) typically sign-posted, you typically don't need a PhD. The parser can understand quite amazing amount of signs just with the nouns we have already defined for vehicles plus the properties (length, weight - plus variants like long) and a few the date and time (Su or Sunday, etc) things also described for other tags. For mappers that are not familiar with the English language, the benefit of the proposal is clearly massively reduced. [...] If you start with the premise that the answer must be expressed in ANTLR and shouldn't include brackets, that's putting the cart before the horse. The objective was to be able to understand sign-posted sentences. I picked ANTLR to play around - but no must. I also said I want to avoid to use brackets just for solving precedence problems - thus mappers shouldn't have to add brackets if they are not used on the sign. But one clear issue is the lack of a bigger amount of examples. Human language is sadly not very precise: except taxis AND bicycles does not mean, you must be in a vehicle that is both (it means if not taxis AND if not bicycles), The human language here is extremely precise to any fluent English-speaker. It means what it says. Yes, no ambiguity here. Picked a bad example. If I were king I would be looking for a system that: Huh, a new condition, added it to the parser. maxspeed:cond = 200 if your are king ;-) * makes common cases easy * makes complex cases possible * makes each rule as standalone as possible (one sign - one rule) * does not rely on the user's fluency in English grammar (knowledge of a set of specific words, e.g. tags and functions, is fine) Signs use extremely simplified language. Thus almost every word on the sign has an essential meaning and has to be translated into a system also using English nouns. But I haven't forgot your valid point - if people think that it is free-text English, then we will soon or later see fancy conditions. * uses grammatical constructions which are familiar to most people, or easily learnt The normal form is not easy to learn - this has to be made in addition to the own language - English translation. But translating simplified text from one language to a simplified English may also be a problem. Thus no major advantage here for the alternative proposal. However, looking to most signs, you will see combinations of one or two attributes plus time related information only. In this case the normal form is no challenge (but same is true for the simplified sign-language English). Outlook: Yet the parser cannot parse complex conditions, the extensibility requirements is therefore not fulfilled. Thus there is no alternative sign-language proposal yet. And it looks like it is not feasible with reasonable effort or unreasonable restrictions/rules (then we better stick to the normal form). IMO, the work done may be helpful for an editor: People can enter the sign-text and the editor converts it to normal form with standardized nouns and conditions. This tool may support several languages instead of just English. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural goods:forward:(Mo-Fr 16:00-18:00) = yes motor_vehicle:backward:(Mo-Fr 16:00-18:00) = agricultural goods:backward:(Mo-Fr 06:00-09:00) = yes This is the point where I think it would be worth to start prefixing the expression by access (I would use the chance of the new proposal). The fact that access is omitted, has mainly historical reasons. hgv=yes actually is just a shortcut for access:hgv=yes, which would be more consistent with the remaining tagging system, e.g. maxspeed:hgv. access:(Mo-Fr 06:00-09:00)=yes access:female=no ... instead of (Mo-Fr 06:00-09:00)=yes female=no martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate: first summary
* some people argued that conditions syntax should look similar to human language, however, other people argued that this would trick mappers into thinking that human language can be used without paying attention to syntax, and others pointed out that that a parser that has to be liberal about what he accepts cannot spot errors anymore Human language - no My proposal you are referring to was mainly to directly tag the (simplified!) language posted on the signs - not full human language. But meanwhile I changed my mind about my own idea. I would propose a new approach regarding human language: - We should offer a way to tag what they see on the signs, but not intended to be understood by machines. This way we can keep mappers happy that do not want to learn a technical language (normal form, logical transformations, etc.) for expressing conditions, for example by offering a tagging schema like: maxspeed:posted = 80 except HGV more than 10m long maxspeed:posted:DE = 80 ausgenommen LKWs mit mehr als 10m Länge It's not thought through, e.g. what happens if there are multiple additional signs with conditions. It also acts as kind of source information - or could be used by navigation software to display the condition as human readable text. And it allows other mappers to identify errors (inconsistencies) in the translation. - The tagging itself should follow stricter rules. Validators or other tools may be used to spot untranslated information of point 1) and mappers familiar with the condition tagging can transform it into the machine friendly form. Here we should continue improving the proposal(s) on the wiki. * most people argued that tagging should be human-readable I would interpret this as: Understandable without wiki lookup for the majority of cases (=mostly intuitive). * most people agreed that proposal should make the common case easily taggable for humans, however, some people said that editor support is required anyway and therefore the readability for humans does not really matter I think we should distinguish between writing conditions and reading conditions. - Writing - editor support - Yes, agree (see also below) - But for reading, editor support is more tricky, because translating it back into human readable language form is in principle possible, but ambiguous (several posted text variants can result in the same tagging). Thus I would strongly prefer that the tags itself are understandable - see above. I would also like to ask people not to blindly start new proposals, because otherwise we'll inevitably end up with hundreds of proposals and no conclusion at all. I will cancel my proposal due lack of support and missing benefit (what I wanted to achieve - and what was intended to be the benefit - does not work so far). For me it makes more sense now to: 1) Provide a option to document posted conditions, but not trying to make it machine readable (in the language of the mapper) 2) Provide editor support (with a parser, maybe based on the work I have done so far on the proposal) to allow semi-automatic translation of posted information into conditions directly in the editor (helping people to learn conditions). This can be provided for different languages (e.g. also in German, French...), maybe also local variants, because text conditions posted on signs have a typical structure 3) Use a machine friendly (=stricter rules) - but human readable tagging for the conditions 4) Think about a tool that spots missing translations of 1) My favourite is clearly the extended conditions proposal. But it needs - as stated - some further development from an idea to a complete proposal - but I will do that directly in the wiki. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Eckhart, On 15/06/2012 01:08, Eckhart Wörner wrote: Hi Colin, Am Freitag, 15. Juni 2012, 00:24:18 schrieb Colin Smale: If I were king I would be looking for a system that: * makes common cases easy Extended conditions: ☑ * makes complex cases possible Extended conditions: ☑ * makes each rule as standalone as possible (one sign - one rule) Extended conditions: ☑ * does not rely on the user's fluency in English grammar (knowledge of a set of specific words, e.g. tags and functions, is fine) Extended conditions: ☑ * uses grammatical constructions which are familiar to most people, or easily learnt Extended conditions: ☑ * has a grammar allowing for a user-extensible function repertoire Extended conditions: ☑ * allowing user-defined functions to be stored in an external file (accessible at entry and run time) I'm not sure I get that one, but it sounds to me like you're trying to mix specification and implementation, which is just a bad idea. You might be right about this. Of course it would be best to only use the specification at entry time. What I had in mind was the ability to share functions with the world without having them replicated millions of times through the database, which is what will happen if you put a function in a tag so you can reuse its value. Using an external file (i.e. not in the database - analogous to how mapnik/mkgmap style sheets are handled) will also not impose any standards on anybody so as not to anger a significant majority of OSM users. Editors can pick the files up dynamically and use what they choose to use. Maintaining a strict division between specification and implementation would require some kind of packaging. Languages like perl and python allow pre-compiled packages, but they also allow you to share scripts and execute them directly. * fits comfortably with the key-value-pair paradigm of OSM Extended conditions: ☑ * can produce a result in a variety of data types including at least boolean, number, string Please provide a use case. The bulk of the discussion up to now has been about access type tags, producing a boolean value: can I or can't I use this road under the given conditions. Why limit it to boolean? Why not address the use case of what is the maximum speed for vehicle X under these conditions (returning a number) or what are the opening hours of this amenity on a given date (returning a string which can be parsed as a date, or returning an object containing some more date objects if you want to go further)? * can use the value of other tags as variables That's just a desaster waiting to happen. Why do you think that would be such a disaster? * can use other variables supplied at run time (e.g. weather, time, vehicle type) Extended conditions: ☑ * supports the usual comparision and numeric operations Which usual comparison operations? '12 knots' '35 mph' ? The comparison operator here is which is definitely usual. Thanks for adding unit conversions to the list! * supports string concatenation operation name = (lang == 'de' ? 'Bahnhof von ' : 'Gare de ') + 'Lyon' Please provide a use case. Well, this specific example is already adequately covered in current tagging practise (name:fr=Gare de Lyon). It's more for completeness - if it wasn't there, I am sure someone will miss it. I wouldn't like us to paint ourselves into a corner by only supporting boolean operations. I wonder if this discussion could also be useful to the lanes discussion in some way? Use cases for routers like how many lanes does this road have, am I allowed in lane 2 etc etc also need to be dynamic and show a lot of similarity to the basic road-level access business. 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
On 2012-06-15 09:07, Colin Smale wrote: The bulk of the discussion up to now has been about access type tags, producing a boolean value: can I or can't I use this road under the given conditions. Why limit it to boolean? Why not address the use case of what is the maximum speed for vehicle X under these conditions (returning a number) or what are the opening hours of this amenity on a given date (returning a string which can be parsed as a date, or returning an object containing some more date objects if you want to go further)? To my understanding, the Extended conditions proposal isn't in any way limited to boolean values. In fact, even the examples have numerical values: maxspeed:hgv = 120 maxspeed:hgv:(Sa,Su) = 80 Also opening_hours already implements a complex value-string for multiple values. Using Extended conditions would make it a bit more clear to read, though. For example: opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00; Dec 20-Jan 06 Mo-Fr 12:00-18:00; Dec 20-Jan 06 Sa 12:00-14:00; Jan 01 off could become something like opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00 opening_hours:(Dec 20-Jan 06) = Mo-Fr 12:00-18:00; Sa 12:00-14:00 opening_hours:(Jan 01) = closed or even opening_hours:(Mo-Fr) = 8:00-16:00 opening_hours:(Sa) = 12:00-16:00 opening_hours:(Dec 20-Jan 06 Mo-Fr) = 12:00-18:00 opening_hours:(Dec 20-Jan 06 Sa) = 12:00-14:00 opening_hours:(Jan 01) = closed Though the given example is unusually complex, so it's not a good example of a common case. And as a sidenote I'm not sure OSM database is even the right place for such detailed opening hours, but that's a whole other discussion. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
as the one who drafted Extended conditions I would like to make some comments. The proposal should not compete with Access restriction 1.5 (or similar proposals). My proposal aims to consolidate and unify existing tags instead of proposing a complete new way of tagging -see the one example at the beginning of the proposal. Extended conditions will not change any of the existing access restriction tags and also not change the existing : separator for compatibility reasons. This can not be done without some dirty workarounds like defining [access] and [all] as default values but it would be compatible with existing and generally accepted tagging. Access restriction 1.5 would change many of widely used tags and as such require a much more complex, long discussion and evaluation. So I suggest to differ between i) making some smaller changes to the existing tagging very soon to enable people to tag some common cases like maxweight=12 maxweight:destination=none or maxspeed:hgv:wet=80 ii) discussing the future of access restrictions which will also replace i) once agreed. -- View this message in context: http://gis.19327.n5.nabble.com/Reviving-the-conditions-debate-tp5712480p5712901.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Pieren, Am Donnerstag, 14. Juni 2012, 12:10:49 schrieb Pieren: condition1=wet maxspeed:lgv=120 or 80 in condition1 I read this as if condition1 applies, the maxspeed is 120 or 80 - I'm pretty sure this is not what you wanted to express. If we consider that a special parser is required as soon as one of the keywords condition, or , and , in , not is present in the value, we could even reduce the amount of tags: What would your parser do to existing tagging like name = Ministere a la condition femininne - decide that femininne is an unknown condition and therefore name = Ministere a la does not apply? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Peter, Am Donnerstag, 14. Juni 2012, 13:10:44 schrieb Peter Wendorff: A key access:weight is okay IMHO and can contain weight-related access restrictions. access:length, access:time and so on - okay. but the specific weight a restriction belongs to should be part of the value, not the key. The problem is that different restrictions combine different conditions that may exist more than once. E.g. there are roads where access restrictions depend on several different weights, different times, and any combinations of them. access:length, access:time, … is by no means sufficient. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Thomas, Am Freitag, 15. Juni 2012, 02:03:31 schrieb ThomasB: as the one who drafted Extended conditions I would like to make some comments. The proposal should not compete with Access restriction 1.5 (or similar proposals). My proposal aims to consolidate and unify existing tags instead of proposing a complete new way of tagging -see the one example at the beginning of the proposal. Extended conditions will not change any of the existing access restriction tags and also not change the existing : separator for compatibility reasons. even if you don't want it to, your proposal *does* compete with Access restrictions 1.5 and everything else mentioned here, because it is the most logical generalization of existing tagging. :-) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
(Sorry for a possible double-post, this message I sent earlier today (7:52:26 UTC) hasn't yet appeared for some reason.) On 2012-06-15 09:07, Colin Smale wrote: The bulk of the discussion up to now has been about access type tags, producing a boolean value: can I or can't I use this road under the given conditions. Why limit it to boolean? Why not address the use case of what is the maximum speed for vehicle X under these conditions (returning a number) or what are the opening hours of this amenity on a given date (returning a string which can be parsed as a date, or returning an object containing some more date objects if you want to go further)? To my understanding, the Extended conditions proposal isn't in any way limited to boolean values. In fact, even the examples have numerical values: maxspeed:hgv = 120 maxspeed:hgv:(Sa,Su) = 80 Also opening_hours already implements a complex value-string for multiple values. Using Extended conditions would make it a bit more clear to read, though. For example: opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00; Dec 20-Jan 06 Mo-Fr 12:00-18:00; Dec 20-Jan 06 Sa 12:00-14:00; Jan 01 off could become something like opening_hours = Mo-Fr 8:00-16:00; Sa 12:00-16:00 opening_hours:(Dec 20-Jan 06) = Mo-Fr 12:00-18:00; Sa 12:00-14:00 opening_hours:(Jan 01) = closed or even opening_hours:(Mo-Fr) = 8:00-16:00 opening_hours:(Sa) = 12:00-16:00 opening_hours:(Dec 20-Jan 06 Mo-Fr) = 12:00-18:00 opening_hours:(Dec 20-Jan 06 Sa) = 12:00-14:00 opening_hours:(Jan 01) = closed Though the given example is unusually complex, so it's not a good example of a common case. And as a sidenote I'm not sure OSM database is even the right place for such detailed opening hours, but that's a whole other discussion. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate: first summary
+1 to the summary and especially to: Am 15.06.2012 um 16:41 schrieb Eckhart Wörner ewoer...@kde.org: I would also like to ask people not to blindly start new proposals, because otherwise we'll inevitably end up with hundreds of proposals and no conclusion at all. I would even prefer to have only one, single proposal which evolves during the discussion. But, well, we all know this will never happen ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/15 Eckhart Wörner ewoer...@kde.org: What would your parser do to existing tagging like name = Ministere a la condition femininne - decide that femininne is an unknown condition and therefore name = Ministere a la does not apply? well, it would probably not parse names at all, so that's rhetorical. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Martin, Am Freitag, 15. Juni 2012, 20:35:39 schrieb Martin Koppenhoefer: 2012/6/15 Eckhart Wörner ewoer...@kde.org: What would your parser do to existing tagging like name = Ministere a la condition femininne - decide that femininne is an unknown condition and therefore name = Ministere a la does not apply? well, it would probably not parse names at all, so that's rhetorical. Sometimes streets are renamed, and name = Street A name:(2013 Jan 1+) = Street B shows the advantages of conditional tagging even on the name tag. In this case, an automatic validation tool could detect in 2013 that the condition will always evaluate to true, and suggest appropriate actions. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 15.06.2012 00:51, schrieb Eckhart Wörner: Hi martinq, Am Donnerstag, 14. Juni 2012, 22:19:06 schrieb martinq: and many other variants. It is almost impossible to tag it wrong. I'm sorry, but every time I've heard a statement similar to you cannot get it wrong it just boiled down to the computer cannot tell you that it's wrong. This is the price you pay for mimicking human language, and I'm not sure I'm willing to pay that price. However, the author struggled with the same basic problem, e.g. there is a (non-intuitive) difference between using ',' and ';' now. Also, except for a basic time restrictions it is impossible to tag and also difficult to read these expressions. Clearly powerful, but too compressed for casual mappers. Can you read this? Dec 25-Su-28 days - Mar Su[-1]: 22:00-23:00 I cannot read it for a simple reason: the specification does not tell the meaning of : inside that expression. The : is defined by an implementation, which just shows the problem of not standardizing properly. However, I believe we should not make time domains part of this discussion at all. open:cond = yes if time is 10:00-18:00 Your example suggests that you have a problem with defining what the if actually means: Does open:cond=yes if time is 10:00-18:00 tell a) open from 10:00-18:00, not open from 18:00-10:00 or b) open from 10:00-18:00? 2) Value vs. key I think value side conditions would be more intuitive, because the value depends on the condition. I think key side conditions would be more intuitive, because the validity of the key depends on the condition. ;-) Also, it easier to filter the things in the database, especially if left/right forward/backward is also mixed into the conditions (or should we simple go the next step and see them as condition too?). The Extended Conditions proposal already treats forward/backward as conditions. Normal form is nice to parse - but do you think everybody can map it? Non-normal form is not so nice for machines - thus I cannot promise that I achieve to parse it - and the discussion is theoretical until I can prove it (with reference implementation). Except that this kind of normal form is the way signs are written normally (that's why it's called normal form ;-) ), see http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg for an example: access:motor_vehicle:(10:00-18:00)=no (first sign) access:motor_vehicle:(10:00-18:00):(length5)=yes (second sign) (How would you tag this?) I'm sure that 95 per cent of the time you won't get more than one tag per sign. I also see no reason why an application may not be able to treat this as equivalent: hgv = yes(shortcut for:) access:hgv = yes (which is a valid expression also in the proposed extension) access:cond = yes [hgv] The Extended Conditions proposal treats the first two as equivalent. But why do you want to mix two ways of tagging (second + third)? Just for fun? Well, probably to support different applications that understand different subsets only. The comparison of combinations between amenity and highway I posted yesterday (or on Wednesday? not sure) shows that ambiguous tagging on the same object often occurs; and it's not the question, if that's necessary or not: Sometimes it's I tag what I know, sometimes it's tagging for maximized compatibility. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Am 15.06.2012 16:29, schrieb Eckhart Wörner: Hi Peter, Am Donnerstag, 14. Juni 2012, 13:10:44 schrieb Peter Wendorff: A key access:weight is okay IMHO and can contain weight-related access restrictions. access:length, access:time and so on - okay. but the specific weight a restriction belongs to should be part of the value, not the key. The problem is that different restrictions combine different conditions that may exist more than once. E.g. there are roads where access restrictions depend on several different weights, different times, and any combinations of them. access:length, access:time, … is by no means sufficient. Why is it a problem? If - as some of you here discuss currently - introduce a really complex grammar for access values nevertheless, why not doing it a little bit more complex to put everything in one tag? If it's already hard to understand as complicated:tag:with:conditions:and:whatever=complicated:value, then why not doing a simplekey=set:of:complicated:conditions:values? The opening hours key IMHO is manageable by humans for the usual case. It get's difficult already when dealing with seasons (summer different from winter, holidays, days before holidays and so on), I fear, too difficult for some people - but well, let's accept that. At least it's one tag, and a mapper may decide not to touch that one tag. To introduce variable tags is worse: * For mappers the attribute list get's long, and I have to ignore more tags than before. * For common data usage applications like osm2pgsql, osmosis and so on filtering has to be done on substring operations on keys - much more complex than on whole keys only, to deal with exceptions; while a value is a simple string that can (for the first run) simply be copied. * Tags relying on each other (as proposed somewhere in this thread as a matter of use other tags as variables) is error prone * Software that put's different attributes into different columns of a table (like, but not restricted to mapnik) for easier search and index functionality has to introduce more - and even worse: variable table columns to support this tagging scheme. On the other hand one tag with a incredible complex value grammer could be used simply by copy and paste, and, if necessary, interpreted and processed to fill different columns or even tables by that interpretation step (e.g. a timetable for opening hours or sth. like that). To conclude: I really don't see any benefit in creating variable keys over creating fixed keys with a variable, slightly more complex (compared to the already complex one) value scheme. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 15.06.2012 23:38, Peter Wendorff wrote: To conclude: I really don't see any benefit in creating variable keys over creating fixed keys with a variable, slightly more complex (compared to the already complex one) value scheme. There's one immediate problem: The 255 character limit for values. When you take the most complex example from http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt2 and put it all into a single value like access:conditional = motor_vehicle:(Mo-Fr 16:00-18:00):forward no; agricultural:(Mo-Fr 16:00-18:00):forward yes; goods:(Mo-Fr 16:00-18:00):forward yes; motor_vehicle:(Mo-Fr 06:00-09:00):forward no; agricultural:(Mo-Fr 06:00-09:00):forward no; goods:(Mo-Fr 06:00-09:00):forward no then you already exceed the limit. You could change the syntax for that one a bit so it would still fit (e.g. omitting the :00), but I expect that there will be a few cases where 255 characters are definitely not enough. Other issues are: * While it's easier to _ignore_ one tag than several, we want mappers to be able to _edit_ them, and one tag will grow to un-editable size more quickly than multiple tags. * Key-based conditions are already being used. It would still be possible to define a value-based approach, though - with some kind of fallback if the value gets too long - and I agree that there are benefits for applications. So ultimately the issue with value-based approaches like the occasionally-suggested maxspeed:conditional = 80; [hgv][wet] 60 style or other similar variants is that nobody did get around to properly defining it yet. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Tobias, thanks for your constructive response.
On 14/06/2012 03:22, Tobias Knerr wrote:
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.
Fully agree.
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.
My concern with this is that it may become unwieldy and cumbersome with
anything beyond fairly trivial cases such as your maxspeed example. Then
the debate will erupt again, and PhD's in boolean algebra will point out
that it *can* be done... In the mean time everyone has to learn a new
grammar and mistakes will be made. and, or and not are the
building blocks of boolean logic and are easily understood by computers.
For the human audience who can't grasp it yet there are millions of
books and websites. The way it is presented in map editors will be
extremely critical in any case. Also, let's not forget to peek beyond
the boundaries of the current discussion about access (i.e. routing)
to see how the conclusion here would fit in other domains.
Here's a test case. No motor vehicles mon-fri between 1600-1800 except
agricultural vehicles and good vehicles *in this direction*. Going the
other way the sign is similar but the times are between 0600 and 0900.
This is a short stretch of narrow road and the restrictions are intended
to stop commuters using it as a rat-run, while at the same time allowing
work to carry on as usual on the farms and businesses along that road.
http://goo.gl/maps/ymvt
motor_vehicle:forward:expr=vehicle_type==agricultural ||
vehicle_type==goods || weekday == SATURDAY || weekday == SUNDAY ||
time16:00|| time18:00
motor_vehicle:backward:expr=vehicle_type==agricultural ||
vehicle_type==goods || weekday == SATURDAY || weekday == SUNDAY ||
time06:00|| time09:00
What would this look like using only AND operators?
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
Re: [Tagging] Reviving the conditions debate
Hi! Maybe someone can help me defining the following access restriction using the 1.5 proposal: http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg Right now I'm pretty lost. :-( Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
I think I found a solution using a self-defined rule: access:motor_vehicle!rule.time=10:00-18:00 access:motor_vehicle!rule.width=5+ access:motor_vehicle?rule=no Can this be simplified somehow (using the 1.5 proposal)? 2012/6/14 Martin Vonwald imagic@gmail.com: Hi! Maybe someone can help me defining the following access restriction using the 1.5 proposal: http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg Right now I'm pretty lost. :-( Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
With the access 1.5 and default opening_hours syntax it would look like this: define the rules for forward and backward: • access!forwardrule.time=Mo-Fr 16:00-18:00 • access!forwardrule.direction=forward • access!backwardrule.time=Mo-Fr 06:00-09:00 • access!backwardrule.direction=backward apply them to motorized vehicles: • access:motorized?forwardrule=no • access:motorized?backwardrule=no define a more specific mode+role combination which outweights the rules applied to motorized • access:motorizedagricultural=yes • access:motorizeddelivery=yes flaimo Message: 8 Date: Thu, 14 Jun 2012 08:38:52 +0200 From: Colin Smale colin.sm...@xs4all.nl To: tagging@openstreetmap.org Subject: Re: [Tagging] Reviving the conditions debate Message-ID: 4fd986fc.5070...@xs4all.nl Content-Type: text/plain; charset=ISO-8859-1; format=flowed Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. This is a short stretch of narrow road and the restrictions are intended to stop commuters using it as a rat-run, while at the same time allowing work to carry on as usual on the farms and businesses along that road. http://goo.gl/maps/ymvt ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
I tried to express this with the other proposal. I got this: motor_vehicle:(Mo-Fr 16:00-18:00):forward=no agricultural:(Mo-Fr 16:00-18:00):forward=yes goods:(Mo-Fr 16:00-18:00):forward=yes motor_vehicle:(Mo-Fr 06:00-09:00):forward=no agricultural:(Mo-Fr 06:00-09:00):forward=no goods:(Mo-Fr 06:00-09:00):forward=no I assume here, that agricultural and goods are more specific than motor_vehicle. Any chance of simplifying this? Martin 2012/6/14 Flaimo fla...@gmail.com: With the access 1.5 and default opening_hours syntax it would look like this: define the rules for forward and backward: • access!forwardrule.time=Mo-Fr 16:00-18:00 • access!forwardrule.direction=forward • access!backwardrule.time=Mo-Fr 06:00-09:00 • access!backwardrule.direction=backward apply them to motorized vehicles: • access:motorized?forwardrule=no • access:motorized?backwardrule=no define a more specific mode+role combination which outweights the rules applied to motorized • access:motorizedagricultural=yes • access:motorizeddelivery=yes flaimo Message: 8 Date: Thu, 14 Jun 2012 08:38:52 +0200 From: Colin Smale colin.sm...@xs4all.nl To: tagging@openstreetmap.org Subject: Re: [Tagging] Reviving the conditions debate Message-ID: 4fd986fc.5070...@xs4all.nl Content-Type: text/plain; charset=ISO-8859-1; format=flowed Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. This is a short stretch of narrow road and the restrictions are intended to stop commuters using it as a rat-run, while at the same time allowing work to carry on as usual on the farms and businesses along that road. http://goo.gl/maps/ymvt ___ 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
On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale colin.sm...@xs4all.nl wrote: Back to my idea to move all 'variables' to the value : Let say we create a new access keyword : condition (or access_condition, cond, expr or whatever_you_like) suffixed by a number, eg. condition1, condition2, etc (unlimited but easy to parse; separator unnecessary). Then conditions are combined using a plain text language, not using ||, , ~, $ or any symbols only known by software programmers (important for readability by wide audience) eg. and , or , not , in like SQL. Examples: Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. access=yes (this implies agricultural=yes and goods=yes) condition1=Mo-Fr 16:00-18:00 condition2=Mo-Fr 06:00-09:00 motor_vehicle:forward=not condition1 motor_vehicle:backward=not condition2 no motor vehicles except for loading/unloading by hgvs between 8pm and 10am access=yes motor_vehicle=no condition1=loading // improving current 'destination' condition2=10:00-20:00 hgv=condition1 and not condition2 Short, readable and easy, no ? Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Yes, short and readable (IMO), but how would you express a conditional maxspeed? I suggested something similar some time ago, but people didnt seem to be very happy with it. It was something like: condition:name=expression anykey:conditional(name)=value The obvious drawback is, that you always need at least two tags. Martin 2012/6/14 Pieren pier...@gmail.com: On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale colin.sm...@xs4all.nl wrote: Back to my idea to move all 'variables' to the value : Let say we create a new access keyword : condition (or access_condition, cond, expr or whatever_you_like) suffixed by a number, eg. condition1, condition2, etc (unlimited but easy to parse; separator unnecessary). Then conditions are combined using a plain text language, not using ||, , ~, $ or any symbols only known by software programmers (important for readability by wide audience) eg. and , or , not , in like SQL. Examples: Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. access=yes (this implies agricultural=yes and goods=yes) condition1=Mo-Fr 16:00-18:00 condition2=Mo-Fr 06:00-09:00 motor_vehicle:forward=not condition1 motor_vehicle:backward=not condition2 no motor vehicles except for loading/unloading by hgvs between 8pm and 10am access=yes motor_vehicle=no condition1=loading // improving current 'destination' condition2=10:00-20:00 hgv=condition1 and not condition2 Short, readable and easy, no ? Pieren ___ 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
I created a (still very small) table showing some examples for both proposals: http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt2 If you have any signposts or can provide a currently missing solution please feel free to update this page or send me the link to the signpost/a description and I'll add it. Martin 2012/6/13 Eckhart Wörner ewoer...@kde.org: 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
On Thu, Jun 14, 2012 at 11:44 AM, Martin Vonwald imagic@gmail.com wrote: Yes, short and readable (IMO), but how would you express a conditional maxspeed? You mean: access:lgv.speed=120 access:lgv?wet.speed=80 condition1=wet maxspeed:lgv=120 or 80 in condition1 If we consider that a special parser is required as soon as one of the keywords condition, or , and , in , not is present in the value, we could even reduce the amount of tags: maxspeed:lgv=120 or 80 in wet Or about one of the previous examples: Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. access=yes motor_vehicle:forward=not (Mo-Fr 16:00-18:00) motor_vehicle:backward=not (Mo-Fr 06:00-09:00) Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 14/06/2012 11:19, Pieren wrote: On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale colin.sm...@xs4all.nl wrote: Back to my idea to move all 'variables' to the value : Let say we create a new access keyword : condition (or access_condition, cond, expr or whatever_you_like) suffixed by a number, eg. condition1, condition2, etc (unlimited but easy to parse; separator unnecessary). Then conditions are combined using a plain text language, not using ||, , ~, $ or any symbols only known by software programmers (important for readability by wide audience) eg. and , or , not , in like SQL. I fully agree that the complexity should be principally in the value, not the key. Sounds good. I think parentheses (or some equivelent) will still be necessary however for grouping, so you can say A or (B and C) or D as A or B and C or D would not do the right thing (using conventional precedence rules). As I understand it you are proposing that the operands be variables (syntactically speaking). It's only a small jump from there to allow literals, and add a couple of operators like equals/not equal/greater than etc. Like that the definition of the conditions as separate tags could be redundant in many cases, but it would allow for reuse of common subexpressions. I am sure that users will be able to get their head around something like this - I hope so, because they will have to. The users will have to learn a new trick anyway, whether it be this expression syntax or the access 1.5 proposal or its competitors. Which approach will give least problems? Can they be understood unambiguously by humans and computers? Or are we going to get lots of bad data due to people misunderstanding/misinterpreting the rules? The set of operators is limited (basically just comparison operations plus and/or/not), and the editors can support the users by presenting the logic represented by the expression in some kind of more natural language if required. Examples: Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. access=yes (this implies agricultural=yes and goods=yes) condition1=Mo-Fr 16:00-18:00 condition2=Mo-Fr 06:00-09:00 motor_vehicle:forward=not condition1 motor_vehicle:backward=not condition2 I think there should be an explicit way of identifying condition1 and condition2 as time constraints. There will also be conditions based on other dimensions such as weight, length, etc. no motor vehicles except for loading/unloading by hgvs between 8pm and 10am access=yes motor_vehicle=no condition1=loading // improving current 'destination' condition2=10:00-20:00 hgv=condition1 and not condition2 Short, readable and easy, no ? Definitely readable. Could be shorter. Easiness is a rather subjective measure. How do these alternatives score? motor_vehicle:expr=(vehicle_type==hgv) ((time20:00)||(time10:00)) (intention==loading) motor_vehicle:expr=(vehicle_type=hgv) and ((time20:00) or (time10:00)) and (intention=loading) One small point though: loading is not the same as destination, although this may vary by jurisdiction. You can't park in a parking bay marked for loading just because you want to visit someone nearby. Pieren ___ 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
Message: 2 Date: Thu, 14 Jun 2012 10:31:17 +0200 From: Martin Vonwald imagic@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Reviving the conditions debate Message-ID: cakjckynqkfsxhltureutycfm9drjwmcxbx9sgocgy61qw2s...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 I think I found a solution using a self-defined rule: access:motor_vehicle!rule.time=10:00-18:00 access:motor_vehicle!rule.width=5+ access:motor_vehicle?rule=no Can this be simplified somehow (using the 1.5 proposal)? 2012/6/14 Martin Vonwald imagic@gmail.com: Hi! Maybe someone can help me defining the following access restriction using the 1.5 proposal: http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg alternate version: access:motorized.time=Mo-Su 00:00-10:00,18:00-24:00 access!shortvehicle.length=5 access:motorized?shortvehicle.time=24/7 Message: 4 Date: Thu, 14 Jun 2012 10:53:33 +0200 From: Martin Vonwald imagic@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Reviving the conditions debate Message-ID: cakjckymigho-wu20ya8wvco7u8pjrds7+ngickdotvvvufk...@mail.gmail.com Content-Type: text/plain; charset=windows-1252 I tried to express this with the other proposal. I got this: motor_vehicle:(Mo-Fr 16:00-18:00):forward=no agricultural:(Mo-Fr 16:00-18:00):forward=yes goods:(Mo-Fr 16:00-18:00):forward=yes motor_vehicle:(Mo-Fr 06:00-09:00):forward=no agricultural:(Mo-Fr 06:00-09:00):forward=no goods:(Mo-Fr 06:00-09:00):forward=no I assume here, that agricultural and goods are more specific than motor_vehicle. Any chance of simplifying this? this notation has the same flaw as the current access scheme. it mixes transportation modes and user roles. motor_vehicle is a transportation mode. agricultural is a user role. not everywhere on this planet agricultural automatically means motor_vehicle. that is what the 1.5 proposal tries to solve. flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/14 Flaimo fla...@gmail.com: Maybe someone can help me defining the following access restriction using the 1.5 proposal: http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg alternate version: access:motorized.time=Mo-Su 00:00-10:00,18:00-24:00 access!shortvehicle.length=5 access:motorized?shortvehicle.time=24/7 Thanks. My first impression of the 1.5 proposal is that one needs quite often self defined rules, which results in quite a lot of tags. I assume here, that agricultural and goods are more specific than motor_vehicle. Any chance of simplifying this? this notation has the same flaw as the current access scheme. it mixes transportation modes and user roles. motor_vehicle is a transportation mode. agricultural is a user role. not everywhere on this planet agricultural automatically means motor_vehicle. that is what the 1.5 proposal tries to solve. Very true. The question is: should we mix a solution for conditional tags with a cleanup of the current access scheme? Or should we try to do it step by step? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 14.06.2012 08:38, Colin Smale wrote: My concern with this is that it may become unwieldy and cumbersome with anything beyond fairly trivial cases such as your maxspeed example. For me, the goal is to make the common cases *easy*, and the rare complex cases *possible*. For the human audience who can't grasp it yet there are millions of books and websites. The way it is presented in map editors will be extremely critical in any case. It's far easier to build a visual editor if you only need to support a limited subset of boolean logic. For example, the filter editor in my mail client (Thunderbird) is limited to a subset of boolean logic as well, for the same reason. Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. What would this look like using only AND operators? motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural goods:forward:(Mo-Fr 16:00-18:00) = yes motor_vehicle:backward:(Mo-Fr 16:00-18:00) = agricultural goods:backward:(Mo-Fr 06:00-09:00) = yes Again using Extended conditions for access tags. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi. I'm a little bit afraid about the discussion here and would like to point out that a key IMHO should be different than a value. I like the idea of namespaces for keys, to be able to group tags that belong together, but I think, even namespaced stuff should belong keylike. A key access:weight is okay IMHO and can contain weight-related access restrictions. access:length, access:time and so on - okay. but the specific weight a restriction belongs to should be part of the value, not the key. It's true: mappers are free to introduce new keys where these are necessary or wanted; but i oppose to encourage the definition of placeholder-keys for arbitrary key-strings following a pattern. Let's code these to the value. if the KEY structure for access keys get's that complicated alone, the problem isn't any more users who don't know how to code the value, but how to code the key itself. Let's keep keys well defined and as simple as possible (while staying well defined of course) to keep at least the task of ignoring non-understandable tags easy. regards Peter 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? 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
On 14/06/2012 12:53, Flaimo wrote: this notation has the same flaw as the current access scheme. it mixes transportation modes and user roles. motor_vehicle is a transportation mode. agricultural is a user role. not everywhere on this planet agricultural automatically means motor_vehicle. that is what the 1.5 proposal tries to solve. I would say that according to current usage motor_vehicle is a class of vehicles. The tagging is intended to represent restrictions enacted by laws and indicated by signs. A large proportion of the countries in the world adhere more-or-less to the UN (ECE?) standards for road signs, which is why the sign for no motor vehicles is so ubiquitous. There are minor variations in the exact definition of motor vehicle for these purposes (does it include mopeds? mowing machines?) but within a traffic law jurisdiction its definition will be consistent. There have been many debates on whether or not to document OSM defaults or assumptions for each jurisdiction. I don't expect there to be total agreement about agricultural either. There are signs for no agricultural vehicles, which in my experience refer to the type of vehicle and not what it is being used for at that moment. But this again may vary per jurisdiction. If a farmer uses his combine harvester to go to the shop for some sugar, is that agricultural? Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi fellow mappers! Disclaimer: I'm a relative newbie to OSM, so feel free to take my opinions as such. (I'm not a newbie to usability, data structure definitions or programming though.) On Wed, 13 Jun 2012, Colin Smale wrote: 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. If the human aspect was primary, then using a free-text field would be enough as humans are capable of incredible inference - something which normal computers still find challenging. I don't understand your logic here. If the human aspect was the *only* requirement, *then* a free-text field would be enough. Nothing to do with it being a primary requirement, since nobody was saying the tags shouldn't *also* be computer readable - that's why they're kept in a structured format instead of free text. I consider human understandability to be primary. That means, human understandability without any assisting programs (other than maybe direct key/value semantic reference lists for some conformity). I consider computer readability to be secondary. It being secondary does *not* make it *unimportant*. It is still a requirement, just like the human understandability. Why? Mostly becuse OSM seems to be built in that way. Moving away from that looks to me to be a *major* deviation. It's of course still possible it is the right way to go, but it's not how OSM is right now. And it seems to work for OSM.- What I like about the Extended conditions proposal of simply having and-conditions separated by a colon (:) is that it doesn't try to be anything complex that requires you to read any documentation to understand it. You can learn it completely by example, fast. It also matches with the current way of specifying special conditions (subtags) (note that subtags are used for other purposes as well). It really seems to be the OSM way of doing things. The only problem is that it does push data into the keys, but I don't see a good way out of that - bloating the value seems like a bad suggestion as well, and having the As to the conditions vs. subtags differentiation - I don't see there being that big of a difference between them. I do understand the difference, though, but becuse it's often not a clear and intuitive issue, separating conditions from subtags probably shoudn't be done. Introducing a new rather non-intuitive character (?) to mark a difference that isn't in many common context very clear will, in my opinion, cause too much confusion compared to the benefits. Editors can be extended with an expression builder and for advanced users they can be taught to check the syntax before comitting a change. But would this actually happen? Would we get good, understandable expression builders in editors, and would anyone use them? I do doubt it. Having complex laguage that relies on editor support (for most users) doesn't seem like a realistic approach, from what I've seen. But I admit I may be wrong here, since I'm not all that familiar with OSM development history. Next point is that we really shouldn't be spending all our time discussing which delimiter to use and other similar aspects of the physical representation of the data. That's only if we abandon human intuitive understandability. The physical representation does matter if we want humans to type in these conditions. That's why it's being discussed. But if we *do* go into the direction that some tags (these conditions, then probably lanes too) are written as computer-intuitive programmer-understandable instead of humanmapper-intuitive computer-understandable then I would suggest these tags or values could always be prefixed with something (eg. special:, code:, computer:, extended:). That way editors could know to only display them via a special editor, instead of plaintext (unless requested by user). I really would hate to see xml, json or anysuch jumping at a mapper's eyes in some tag/value list - that might have a deterring effect on editing. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 14/06/2012 13:00, Tobias Knerr wrote: On 14.06.2012 08:38, Colin Smale wrote: My concern with this is that it may become unwieldy and cumbersome with anything beyond fairly trivial cases such as your maxspeed example. For me, the goal is to make the common cases *easy*, and the rare complex cases *possible*. Difficult to argue with that! The second part makes a flexible grammar essential, as you cannot predict what these rare complex cases might look like. It's far easier to build a visual editor if you only need to support a limited subset of boolean logic. For example, the filter editor in my mail client (Thunderbird) is limited to a subset of boolean logic as well, for the same reason. Sure, it's limited to match all/match any and a fixed list of operators. But Thunderbird is not trying to represent something in the physical world here, only to help the user. Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. What would this look like using only AND operators? motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural At first glance this looks like a motor vehicle going forward between those times is considered agricultural. It doesn't feel very intuitive, based on the established key=value paradigm. I thought of the following, based on the premise that the class motor_vehicle can be partially overridden by a subclass such as hgv or agricultural: motor_vehicle=yes motor_vehicle:forward:(Mo-Fr 16:00-18:00)=no motor_vehicle:backward:(Mo-Fr 06:00-09:00)=no hgv=yes agricultural=yes Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 14.06.2012 13:30, Colin Smale wrote: motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural At first glance this looks like a motor vehicle going forward between those times is considered agricultural. It doesn't feel very intuitive, based on the established key=value paradigm. Putting a group of users into the value is not my own invention, that's established tagging. Mappers are using things like motor_vehicle=agricultural or access=destination right now. Look at the distribution of values of motor_vehicle, for example: http://taginfo.openstreetmap.org:8001/keys/motor_vehicle#overview I agree that it is not a particularly nice solution, and you could of course split this into separate tags with yes and no as the values. But I don't think it's useful to exclusively focus on the one thing that is not new at all when discussing an example. motor_vehicle=yes motor_vehicle:forward:(Mo-Fr 16:00-18:00)=no motor_vehicle:backward:(Mo-Fr 06:00-09:00)=no hgv=yes agricultural=yes Unfortunately, this doesn't work with the conflict resolution approach currently defined by Extended Conditions. These state that the most specific rule counts (in terms of boolean logic, the one that implies the others). In this case, there's sometimes no most specific rule. When you compare motor_vehicle:backward:(Mo-Fr 06:00-09:00)=no hgv=yes then for an hgv at 08:00, the time is more specific on the first rule, but the vehicle class is more specific on the second. This means that the most restrictive value is relevant, which is no. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
2012/6/14 Colin Smale colin.sm...@xs4all.nl: each jurisdiction. I don't expect there to be total agreement about agricultural either. There are signs for no agricultural vehicles, which in my experience refer to the type of vehicle and not what it is being used for at that moment. But this again may vary per jurisdiction. If a farmer uses his combine harvester to go to the shop for some sugar, is that agricultural? in Germany the usual occurence of agricultural is positive: motor_vehicle=no, agricultural=yes (additional sign mostly on tracks to allow agricultural traffic, usually including forestal traffic). This is referring to the intention of the traffic. If a farmer uses a bike or a motorbike to go to his field, it would be agricultural, while your example of the combine harvester going to buy cigarettes would not qualify (of course this is theoretical, because he could always pretend he was working when he takes his combine harvester to a bbq party on the field). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
The other usage of the term agricultural is the type of vehicle. In the UK agricultural vehicles are prohibited on motorways due to their slow speeds. But a farmer could use his Land Rover on a motorway as it is a car being used for agriculture. Phil -- Sent from my Nokia N9 On 14/06/2012 14:22 Martin Koppenhoefer wrote: 2012/6/14 Colin Smale colin.sm...@xs4all.nl: each jurisdiction. I don't expect there to be total agreement about agricultural either. There are signs for no agricultural vehicles, which in my experience refer to the type of vehicle and not what it is being used for at that moment. But this again may vary per jurisdiction. If a farmer uses his combine harvester to go to the shop for some sugar, is that agricultural? in Germany the usual occurence of agricultural is positive: motor_vehicle=no, agricultural=yes (additional sign mostly on tracks to allow agricultural traffic, usually including forestal traffic). This is referring to the intention of the traffic. If a farmer uses a bike or a motorbike to go to his field, it would be agricultural, while your example of the combine harvester going to buy cigarettes would not qualify (of course this is theoretical, because he could always pretend he was working when he takes his combine harvester to a bbq party on the field). cheers, Martin ___ Tagging mailing list colin.sm...@xs4all.nl http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Martin, if it walks like a duck and quacks like a duck, then it had better be a duck... What I mean with this, is if the grammar is so English-like such that people are tempted to use constructions which are not (or not quite) supported by the grammar, or if the way it works is contrary to how the English language would interpret it, then errors will occur. Plus, of course, that the majority of users will not have English as their first language, and we have to make this accessible to the man-in-the-street and not allow it to become so obfuscated that only PhD's need apply. Bottom line: I question whether making it kind of pseudo-English-like is the right goal to aim at. A simple grammar which is (mis)understood equally over the whole world might be better. Your post below is full of examples supporting my point. The grammar should be derived from what you are trying to model, just as a (descriptive) grammar for English is reverse-engineered from the way the language is used. If you start with the premise that the answer must be expressed in ANTLR and shouldn't include brackets, that's putting the cart before the horse. Please feel free to carry on with your experimentation to see if you can make a grammar on this basis, but remember that humans have to read and write this stuff (which does not detract from my earlier assertion that machine-readability is a slightly higher priority than human-readability) and they often need clear boundaries to make the most of their creativity. If you put a child in the middle of an infinitely large field with no boundaries obvious to the child, they won't move far from where you put them. If you put the same child in a large fenced enclosure, they will explore every inch. Give a child a paintbrush in front of a huge blank wall and you will get a small picture. Mark out a frame on the wall and say paint in this and it will all get used. Give a mapper no limits on tagging, and many things will not get tagged (because of inner doubts about how to do it). Give the same mapper a menu of 100 tags which can be used, and he will use many more of them. Human language is sadly not very precise: except taxis AND bicycles does not mean, you must be in a vehicle that is both (it means if not taxis AND if not bicycles), The human language here is extremely precise to any fluent English-speaker. It means what it says. It's the IT-based interpretation of the word AND which leads to the grammar misinterpreting the intention. Think of the expression: a * b + c * d To the untrained eye this may appear ambiguous or be interpreted differently to how a compiler will interpret it. Nonetheless it's valid code and no compiler will complain. However style-wise there is a school of thought that such constructions are unsafe because a bug caused by precedence problems is difficult to find by a quick inspection. My mandating the use of parentheses to make the programmer's intentions clear to a code-reviewer helps to detect bugs early, and has the desirable side-effect of making the programmer think just a little bit harder about how it's going to work out. Prevention is better than cure: anything making it less likely that coding errors make it into the database is most definitely a Good Thing To Have. Grammars which allow just about everything are a pain because they frustrate this error checking and delay error detection considerably, often relying on a user to report an anomaly, triggering all kinds of incident management and problem management processes and costing thousands of times more to fix than if the input validation had stopped the error occurring in the first place. If I were king I would be looking for a system that: * makes common cases easy * makes complex cases possible * makes each rule as standalone as possible (one sign - one rule) * does not rely on the user's fluency in English grammar (knowledge of a set of specific words, e.g. tags and functions, is fine) * uses grammatical constructions which are familiar to most people, or easily learnt * has a grammar allowing for a user-extensible function repertoire * allowing user-defined functions to be stored in an external file (accessible at entry and run time) * fits comfortably with the key-value-pair paradigm of OSM * can produce a result in a variety of data types including at least boolean, number, string * can use the value of other tags as variables * can use other variables supplied at run time (e.g. weather, time, vehicle type) * supports the usual comparision and numeric operations * supports string concatenation operation Colin On 14/06/2012 22:19, martinq wrote: Hi, sadly this discussion was restarted before I could establish a reference implementation for a less technical way of tagging conditional values (for those who are interested: it is a ANTLR grammar, hopefully with built-in evaluation code). The reference implementation is for me
Re: [Tagging] Reviving the conditions debate
Hi martinq, Am Donnerstag, 14. Juni 2012, 22:19:06 schrieb martinq: and many other variants. It is almost impossible to tag it wrong. I'm sorry, but every time I've heard a statement similar to you cannot get it wrong it just boiled down to the computer cannot tell you that it's wrong. This is the price you pay for mimicking human language, and I'm not sure I'm willing to pay that price. However, the author struggled with the same basic problem, e.g. there is a (non-intuitive) difference between using ',' and ';' now. Also, except for a basic time restrictions it is impossible to tag and also difficult to read these expressions. Clearly powerful, but too compressed for casual mappers. Can you read this? Dec 25-Su-28 days - Mar Su[-1]: 22:00-23:00 I cannot read it for a simple reason: the specification does not tell the meaning of : inside that expression. The : is defined by an implementation, which just shows the problem of not standardizing properly. However, I believe we should not make time domains part of this discussion at all. open:cond = yes if time is 10:00-18:00 Your example suggests that you have a problem with defining what the if actually means: Does open:cond=yes if time is 10:00-18:00 tell a) open from 10:00-18:00, not open from 18:00-10:00 or b) open from 10:00-18:00? 2) Value vs. key I think value side conditions would be more intuitive, because the value depends on the condition. I think key side conditions would be more intuitive, because the validity of the key depends on the condition. ;-) Also, it easier to filter the things in the database, especially if left/right forward/backward is also mixed into the conditions (or should we simple go the next step and see them as condition too?). The Extended Conditions proposal already treats forward/backward as conditions. Normal form is nice to parse - but do you think everybody can map it? Non-normal form is not so nice for machines - thus I cannot promise that I achieve to parse it - and the discussion is theoretical until I can prove it (with reference implementation). Except that this kind of normal form is the way signs are written normally (that's why it's called normal form ;-) ), see http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg for an example: access:motor_vehicle:(10:00-18:00)=no (first sign) access:motor_vehicle:(10:00-18:00):(length5)=yes (second sign) (How would you tag this?) I'm sure that 95 per cent of the time you won't get more than one tag per sign. I also see no reason why an application may not be able to treat this as equivalent: hgv = yes(shortcut for:) access:hgv = yes (which is a valid expression also in the proposed extension) access:cond = yes [hgv] The Extended Conditions proposal treats the first two as equivalent. But why do you want to mix two ways of tagging (second + third)? Just for fun? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Colin, Am Freitag, 15. Juni 2012, 00:24:18 schrieb Colin Smale: If I were king I would be looking for a system that: * makes common cases easy Extended conditions: ☑ * makes complex cases possible Extended conditions: ☑ * makes each rule as standalone as possible (one sign - one rule) Extended conditions: ☑ * does not rely on the user's fluency in English grammar (knowledge of a set of specific words, e.g. tags and functions, is fine) Extended conditions: ☑ * uses grammatical constructions which are familiar to most people, or easily learnt Extended conditions: ☑ * has a grammar allowing for a user-extensible function repertoire Extended conditions: ☑ * allowing user-defined functions to be stored in an external file (accessible at entry and run time) I'm not sure I get that one, but it sounds to me like you're trying to mix specification and implementation, which is just a bad idea. * fits comfortably with the key-value-pair paradigm of OSM Extended conditions: ☑ * can produce a result in a variety of data types including at least boolean, number, string Please provide a use case. * can use the value of other tags as variables That's just a desaster waiting to happen. * can use other variables supplied at run time (e.g. weather, time, vehicle type) Extended conditions: ☑ * supports the usual comparision and numeric operations Which usual comparison operations? '12 knots' '35 mph' ? * supports string concatenation operation name = (lang == 'de' ? 'Bahnhof von ' : 'Gare de ') + 'Lyon' Please provide a use case. 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
