Opening Hours, a tale about over-engineering
OpenStreetMap collects the information at which time a place is open, e.g. when can I shop at that place. This is not uncontroversial in the community, as the data takes a lot of human effort to maintain.
Another problematic thing about this is: We’re dealing with time here, and that’s a special kind of pain in software development, though there are good examples of dealing with time conveniently. Nevertheless OSM sometimes has unusual approaches, because it’s a data structure on the one hand and on the other it’s something that even non-geeks need to read and write without much thought.
Version 1
The original approach was simple as efficient. Just write the days of week in blocks and add a time range after each block. One example of that:
Mo-Fr 08:00-16:00; Sa 09:00-12:00
But as always, there is one issue: Reality, which doesn’t fail to demonstrate that simple things as time spans can become nasty. Thankfully, developers sometimes are able to find the right amount of abstraction, notably the Public Holiday field.
Mo-Su 12:00-14:00; PH 12:00-13:00
Easy and clear: Everyday open from 12:00 to 14:00, except on public holidays, then it’s 12:00 to 13:00. The consumer of this information will probably know that it’s a public holiday anyway, you don’t need to encode that data.
We need to go deeper
We could stop here, state that the limit of good readability is reached and anything more would be too much. We could introduce another field that doesn’t interfere with the existing data and is only for human consumption. We could go for the wheelchair:description approach, which separates clearly.
But bright people with too much time on their hands can be the worst enemy of simplicity. More features become an obsession. And that is exactly what happened. Fair enough, I guess at this point I should be thankful that at least there is some documentation.
Wait, what?
Mo-Fr 08:00-01:00, Sa 12:00-02:00
“That looks like a mistake. This should be a semicolon, but there is a comma.” You could think. But no, the Heads of Overengineering declared that this is now the correct way. What is compatible to other software doesn’t matter! Let’s fork it! The world is yours!
Apparently the example above shows the distinction that rules separated by semicolon are overwriting and those which separate by comma extend those. Wait, what!? Sure, in a technical sense it might be correct. But in reality? Who needs that? Just for sake of defining a five page long specification?
Interpreting such a field differently, this is normal business in OSM. But what’s not normal: Performing a mechanical edit, because the development team of one library thinks it should break all existing software. Effectively forcing everyone to use their implementation.
Doesn’t stop here
Mo-Su,PH 15:00-03:00; easter -2 days off
God, why? Why is this even a thing? By the time of the next easter holiday, the opening hours will likely change. Who wants to actually maintain this madness? Who wants to implement parsers for things that no one needs. This is a pure demonstration of how clever someone thinks they are.
We don’t need another complicated thing. We need tools and structures that are approachable by many. If we wanted atrocious standards that are way too long for what they need to do, we would be doing enterprise GIS and not OpenStreetMap.
