[OSM-talk] [RFC] restriction=school_zone (second email)

[Roy Wallace]

On Sat, Aug 8, 2009 at 1:24 AM, Lars Aronsson<lars at aronsson.se> 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.