On Sat, Aug 8, 2009 at 1:24 AM, Lars Aronsson<[email protected]> wrote: > John Smith wrote: > >> For general time based restrictions you can still do it in one >> line if you must, without needing to parse variable information >> in the key section: >> >> maxspeed:time=12:00-23:59;tu,th;50 >> hh:mm-hh:mm;[dd,dd,dd|dd-dd];speed > > > The second sign in this page > http://sv.wikipedia.org/wiki/Datumparkering > > says parking forbidden on Wednesdays 9-15 o'clock > but only between December 1 and May 15 (snow removal season).
This is very interesting. Question: does a "school zone" restriction or a "snow removal season" restriction need to be explicitly marked as such, or is it only important that the applicability (e.g. dates/times) and effect (e.g. maxspeed) be specified? If it doesn't need to be explicitly marked, I would suggest the following, as I did before, to cover both of these cases (and others that may arise in future): <X>:<K> = <L>;<V>, where the format of <L> depends only on <K>. The beauty of this scheme is that for BOTH RESTRICTIONS: <K> = time (meaning the tag is only applicable at certain times), and <L> = <time range>[,<time range>]* (note you don't need a separate date range - it's all wrapped up in the time range) (NOTE: I think I've got the format of time ranges below correct according to opening_hours, but please, someone check this. The specification of an OSM time range is an important yet separate issue, anyways.) Now, within this framework, for the snow removal restriction: <X> = no_parking (is there actually a no_parking restriction yet? Regardless, it does/would fit into this framework perfectly) <V> = yes (meaning no_parking=yes) <L> = Dec 01-May 15 We 09:00-15:00 On one line: no_parking:time = Dec 01-May 15 We 09:00-15:00;yes For the school zone: <X> = maxspeed <V> = 40 (i.e the maxspeed in kmph) <L> = school_terms school_days 07:00-09:00,14:30-15:30 On one line: maxspeed:time = school_terms school_days 07:00-09:00,14:30-15:30;40 And yes, you can see that the specification of "time range" needs to allow not only for explicit date ranges, but also labels like "school_terms" and "school_days". But this IMHO is a nicer way to deal with things - i.e. if what you're actually doing is introducing a new kind of label for a date range and a new way to infer the actual values from administrative boundaries, document this fact as such, separate from any particular new tag. It's no more complicated than the current proposal, looks great on a single line IMHO, and can be extended very nicely. _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
