Some real world objects change behaviour over time:
- Shops and facility are opened only at certain times,
- ferrys run at certain times,
- there may be night only speed limit for streets,
- letterboxes are cleared at certain times,
- busses depart at certain times.
The OpenStreetMap-Database stores such time specifications with keys informal description of the allowed values and their meanings.
Based on this description I designed a
Without any effort you can evaluate time expressions and become acquainted with their capabilities:
Three maps show the objects from the OSM database using time specifications and mark erroneous ones:
- Map: opening_hours (erroneous one only – quality assurance), ways only, relations only, only objects which are open just now)
- Map: collection_times (erroneous one only – quality assurance), ways only, relations only, point in time today, point in time this week)
- Map: service_times (erroneous one only – quality assurance), ways only, relations only, point in time today, point in time this week)
Changes and extensions:
Objects having erroneous
opening_hours-values are marked by a red circle on the
map. I fixed a big number of them and got quite an overview on what the users store under this
key and how. From this I derived some extensions to the proposal:
- Cooperative values:
A common mistake was coding additional times in a way that they became interpreted as exclusive times: evaluating the value
following the proposal, the opening on wednesday ist afternoon only.
Mo-Fr 08:00-12:00; We 14:00-18:00
I allow additional times separated by
,and interprete the comma as and also:
is evaluated to what the user really wants.
Mo-Fr 08:00-12:00, We 14:00-18:00
- Time is not optional any more:
The proposal defines
Monday to friday the whole day. But this is wanted very seldomly. Therefore I made the time specification obligatory:
is not allowed any more and must be written as:
I found quite a lot of time ranges like
spanning midnight. The proposals solution is spliting it into two time ranges, one ending at
24:00on the first day, the other starting at
00:00on the next day.
This is error prone and in case of complicated date conditions a real mess. Therefore I implemented these
Daywraps: if the second time of a time range is lower than the first time, it is assumed to be on the next day.
- Date ranges:
Date ranges must be terminated now with a
:. This prevents difficult to resolve ambiguities.
- Plain text information:
Opening hours can depend on conditions, which cannnot (easily) be evaluated. Lets assume a public pool, which usually is open from 12:00 to 18:00, but closes earlier on bad weather conditions.
To represent such conditions, I add to the status values
closeda third value
unknown, which must be used with a plain text comment.
Addtionally you can use informal only specifications like
during the asparagus season.
- Error tolerance:
Some errors are quite common: names of weekdays and months are written in other languages or not abbreviated, hours and minutes are separated by
.and not by
I fix this kind of errors and evaluate the fixed expression, but return the result together with an error message.
The evaluation functions can return
erroneousat the same time. In the maps this is displayed by circles of two colors.
- Holidays (
Public holidays and school holidays depend on the location. I need additional information to select the right rules. I.e. we could use
SH(de.nrw)to select school holidays in state North Rhine Westphalia of Germany.
The current implementation evaluates
PHto the public holidays of Germany; school holidays are not defined at all.
Currently I use
I got started with an halfway comprehensible explanation, but would like somebody else to complete this work. Because I'm too deeply involved into the internals of time value evaluation, I can't take the plain users point of view anymore.