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] reservoir_type=tailings
I've only heard tailings used to refer to the waste from mining. Regarding wastewater treatment, I'm assuming other reservoir_types discussed were things like sedimentation and aeration? Brad On Thu, Jun 14, 2012 at 7:39 AM, Martin Koppenhoefer wrote: > Today we had a discussion on talk-de how to map the different pools > and reservoirs in a wastewater treatment plant. One of the tags that > came up was reservoir_type=tailings, referenced from this page: > http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir > > It is not completely clear, if this tag really was intended for > specific baisins inside a wasterwater treatment plant, or if this is a > feature in conjunction with mining ( > http://wiki.openstreetmap.org/wiki/Proposed_features/Mining ). Maybe > we should be more specific here in the wording? IMHO we should try to > find a definition to put into the wiki which is in line with current > use of this tag in OSM. > > I also noticed that NHD uses the word tailings pond for the SHP keys > 43604 and 43605: > http://wiki.openstreetmap.org/wiki/National_Hydrography_Dataset > for Reservoir (Disposal-Tailings Pond Earthen) and Reservoir > (Disposal-Tailings Pond Unspecified) > > Cheers, > Martin > > ___ > 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
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
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):(length<5)=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
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 imp
Re: [Tagging] Reviving the conditions debate
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 a key for acceptance, because the less technical to tag, to more difficult to parse. And we all agree that it should be possible to parse it - but not necessarily easy. Objective of my proposal: As less rules as possible - as close as possible to the sign-posted information. The proposal page does not contain a lot of information, because I adapt the "grammar" based on what is feasible. Sadly cannot spend a lot of time in continuing with the reference my implementation at the moment. I will comment based on what I have already figured out: > - "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. This is in fact the biggest challenge in the current state of my parser (in combination with fuzzy & context related precedence). 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), "except HGV AND weight>7.5t" is by most humans interpreted differently (if not (HGV AND weight>7.5t). There are lot of other examples for amgiguities, eg. "except Fr, 10:00-18:00" does not mean complete Friday and the other days, etc. However, in this case the preliminary parser has no problem to understand following different expressions: maxspeed:cond = 80 if wet or Sunday Easy tagging, isn't it? But the grammar is flexible. Instead of 'if' I also support 'when' and '[' ']' (I am not sure about the brackets yet - they are clearly not as intuitive as 'if' or 'when'). maxspeed:cond = 80 [wet] maxspeed:cond2 = 80 [Su] Also understood by the parser: maxspeed:cond = 80 when weekday is Sunday and condition is wet or maxspeed:cond = 80 weekday=Su or condition=wet or maxspeed:cond = 80 [wet]; 80 on Sundays and many other variants. It is almost impossible to tag it wrong. > - Brackets for expressions. If we limit ourselves to just "and" > operators, evaluation order doesn't matter. This is something I really want to avoid. Brackets for precedence purposes are a purely technical artefact and I not seen them on the signs with the information we want to tag... However, the *precedence* is the major problem in the current parser. Thus I don't think I can write a parser without any rule helping the parser and restricting the mappers. But brackets will just be introduced if I have no other option. >> Pseudo-Javascript: (!is_motor_vehicle(vehicle_type)) || >> ((vehicle_type='hgv')&& (time<'10:00' || time>'20:00')&& >> intention='loading') == side note == A assume, this is access related. Side-note: The current access tags are IMO just abbreviations, nowadays we would write instead of hgv=yes --> access:hgv=yes. With the conditional value proposal it could be tagged as access=yes if hgv maxweight=x is an example for (vehicle) access = no if weight>x, even though it can also be a non-conditional property of an object (e.g. a bridge may have a intrinsic maximum acceptable weight, but we don't have to go into details now). == side note end == I interpreted your code as your example as access=yes access:cond1 = no if motorized or "no if motor vehicle" or "no if vehicle is motorized" access:cond2 = delivery if hgv from 10:00-20:00 or "delivery if vehicle is a hgv and time is 10:00-20:00 or many variants more... If the evuation part of my parser works (yet I still working on the grammar), I may also be able to create a kind of "normalized" JavaScript expression out of the "fuzzy" human tags [but I don't have implemented a normalized attributed tree yet]. > - defining a syntax for time intervals (opening_hours) By using on/off, this is already the first tag which moved the condition into the value. By using off/on, it reads like off if ... on if ... 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 In this case I would stick to human readable expressions like "last Sunday in March" and put the load to evaluate it onto the parser/application. > - defining a subset hierarchy of vehicle categories (such as > "motor_vehicle" including "hgv" as a subset) Applications must know which vehicle you drive to evaluate certain conditional values (mainly access, speed limits and also parking conditions). Unlike the current acc
[Tagging] access agricultural, WAS Re: Reviving the conditions debate
2012/6/14 Philip Barnes :
> 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.
Yes, unfortunately instead of discussing the issue there was repeated
wiki fiddling on this issue. I tried to dig into this and am
presenting the results here:
agricultural was introduced 25 Dec. 2007, but without further definition:
http://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess&action=historysubmit&diff=66244&oldid=14009
on 4 Feb. 2009 there was a definition added: *
{{Tag|access|agricultural}} ''Only for agricultural traffic.''
http://wiki.openstreetmap.org/w/index.php?title=Key:access&diff=next&oldid=218932
(this might have been intended as a use condition, because otherwise
it would have been "agricultural vehicle", but actually the wiki was
still not very clear, because in the following time it listed use
classes (hazmat, emergency, hov) together with vehicle classes
(motor_vehicle, hgv). This is also reflected by the diagram that was
added on 23 Feb. 2009:
http://wiki.openstreetmap.org/w/index.php?title=Key:access&diff=prev&oldid=231676
and amended on 11 March 2009:
http://wiki.openstreetmap.org/w/images/e/e9/Access_modes.png
on 20 Aug 2009 there was a contradiction introduced, agricultural was
still defined as agricultural traffic but the same time lower in the
page there was added this (still there was no distinction between use
cases (hazmat, emergency) and vehicle types): agricultural=*
(agricultural motor vehicles, e.g. tractors, that have additional
restrictions, e.g. a 25km/h speed limit). The diagram was replaced.
5 days later this was relativated by separating "by use" and vehicle
classes, keeping the class definition for agricultural in parenthesis
though:
http://wiki.openstreetmap.org/w/index.php?title=Key:access&diff=prev&oldid=327300
This situation was kept until 5 Jan 2012, when "agricultural" was
moved from "by use" to "double tracked vehicles".
http://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess&action=historysubmit&diff=720329&oldid=720323
Which is where we are now. The beginning of the page still states that
agricultural is a tag for agricultural traffic.
How can we resolve this? It seems obvious that we need either 2 tags
for agricultural (according to the legislation, either a vehicle class
or a use case is intended), or we accept that the same tag has
different meanings in different legislations/countries. Personally I
am in favour of an additional tag. We could also have 2 new tags:
"agricultural_use" and "agricultural_vehicle" to make it unambiguous,
and to deprecate the unclear agricultural.
What do you think?
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 : > 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
2012/6/14 Colin Smale : > 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
[Tagging] reservoir_type=tailings
Today we had a discussion on talk-de how to map the different pools and reservoirs in a wastewater treatment plant. One of the tags that came up was reservoir_type=tailings, referenced from this page: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir It is not completely clear, if this tag really was intended for specific baisins inside a wasterwater treatment plant, or if this is a feature in conjunction with mining ( http://wiki.openstreetmap.org/wiki/Proposed_features/Mining ). Maybe we should be more specific here in the wording? IMHO we should try to find a definition to put into the wiki which is in line with current use of this tag in OSM. I also noticed that NHD uses the word tailings pond for the SHP keys 43604 and 43605: http://wiki.openstreetmap.org/wiki/National_Hydrography_Dataset for Reservoir (Disposal-Tailings Pond Earthen) and Reservoir (Disposal-Tailings Pond Unspecified) Cheers, Martin ___ 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
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
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 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. 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 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
2012/6/14 Flaimo : >>> 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
> Message: 2 > Date: Thu, 14 Jun 2012 10:31:17 +0200 > From: Martin Vonwald > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Reviving the conditions debate > Message-ID: > > 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 : >> 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 > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Reviving the conditions debate > Message-ID: > > 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
On 14/06/2012 11:19, Pieren wrote: On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale 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") && ((time>"20:00")||(time<"10:00")) && (intention=="loading") motor_vehicle:expr=(vehicle_type="hgv") and ((time>"20:00") or (time<"10: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
On Thu, Jun 14, 2012 at 11:44 AM, Martin Vonwald 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
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 : > 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
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:= :conditional()= The obvious drawback is, that you always need at least two tags. Martin 2012/6/14 Pieren : > On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale 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
On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale 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
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 : > 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:motorized&&agricultural=yes > • access:motorized&&delivery=yes > > flaimo > >> Message: 8 >> Date: Thu, 14 Jun 2012 08:38:52 +0200 >> From: Colin Smale >> 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
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:motorized&&agricultural=yes • access:motorized&&delivery=yes flaimo > Message: 8 > Date: Thu, 14 Jun 2012 08:38:52 +0200 > From: Colin Smale > 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 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 : > 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
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
