In Poland, most of the shops are required by law to be closed on most Sundays. But not all shops, and not all Sundays. I know that this law is present not only in Poland - Germany, Belgium, and many other countries have similar restrictions. In Poland, Sundays in which shops can be opened are called shopping Sundays.
The problem with the current opening_hours syntax is that it doesn’t consider shopping Sundays and people have different ways of tagging them, and none of them are perfect - the result is - the same thing is tagged in a few different ways, but none of them rendered correctly in all the renderers.
My proposition is to a add new symbol to the opening_hours syntax. There is already PH and SH for public and school holidays, let’s add SSu for shopping Sunday.
They shouldn’t be tagged as “Su”, but if we are tagging public and school holidays, why wouldn’t we tag these “special” Sundays? Most of the shops here in Poland have set regular opening hours (displayed on the door) for these “special” Sundays, unlike for public and school holidays.
It sounds like Germany has some similar things. Once I saw a bakery which was closed on Good Friday, and added easter - 2 days off to the opening_hours to map that. Technically that’s valid OH syntax. Would that approach be useful here?
Some of them could be written as:
opening_hours=easter -7 days XX:XX-XX:XX; Jan,Apr,Jun,Aug Su[-1] XX:XX-XX:XX
But we currently can’t cover “next two Sundays preceding Christmas Day”.
Still, this is so complicated syntax, which most people won’t understand and would probably freak out a shop owner who is not familiar with OSM and just wants to change the opening hours for his own shop.
Seem to remember they have shopping Sunday “koopzondag” in places of Holland like the first or last Sunday of the month and certain Sundays before Easter or Xmas. Certainly types of shops can always be open on Sunday. I’d be surprised if they have not already developed syntax for that. It’s at city/town level regulated. Brief search, a site even Koopzondag - Alle koopzondagen in Nederland. Look up community of interest and you’ll know.
I couldn’t find anything on the Dutch forum. It would be great to hear from someone from a country with similar restrictions (for example from the Netherlands, Germany, Belgium or other) how it’s tagged in these countries.
By the same concern, you will still break the already complicated opening_hours= syntax that may yet not be fully supported by everyone. Users will have to check the syntax, or editing software have to support it widely, when most aren’t even GUI. And let’s not talk about non-Gregorian calendars, and festivals based on them…
Do you mean last two preceding, or next two subsequently? Use =Dec Su[-1,-2,-3] 10:00-18:00 "if before Xmas" first. (unfortunately this is already unsupported in implementation as the tool shows “can not use more than one constrained weekday in a month range”)
Maybe it can be patched in by combining and expanding the syntax eg opening_hours:conditional=Su 10:00-18:00 @ date + 14 days <= Dec 25
Or f it is as easy as adding a <shopping_sunday> with SS to <holiday> with the program, it is more doable. However, PH is not even defined for many countries yet. GitHub - opening-hours/opening_hours.js: Library to parse and process the opening_hours tag from OpenStreetMap data
Actually there is a getMovableEventsForYear in opening_hours.js/index.js at master · opening-hours/opening_hours.js · GitHub with a 'variable_date': nextWednesday16Nov example in opening_hours.js/README.md at master · opening-hours/opening_hours.js · GitHub that might be reusable. So why don’t you ask this on Github? That’s where the syntax is anyway.
In The Netherlands the shopping streets are extremely boring in their opening times and as a result you won’t find a whole lot of places where they are tagged.
Places where opening times are tagged are the non-standard places. Food places and such.
In response to the general point, I think this proposal makes a lot of sense. Especially for Poland, a bit less for The Netherlands. But it will be useful overall based on the simple problem that today its not really standardized at all.
Also, you could use syntax like opening_hours=Mo-Sa 08:00-17:00; Su "only some shopping Sundays 08:00-14:00"
That is supported syntax (check it on opening_hours evaluation tool), and clients are supposed to show the message in quotes to user for that days (Sundays). OsmAnd at least does AFAIK.
Alternatively, one could try specifying specific Sundays. But that has other disadvantages (like needing update at least once every year, and also 255-character tag limit). E.g. opening_hours=Mo-Sa 08:00-17:00; Su off; Jul 30 08:00-12:00; Aug 6 08:00-12:00; Dec 3 08:00-12:00
The problem with this, and any proposal that suggests additional tokens that are not algorithmically determinable, is that just as PH and SH, will require external data to be actually useful for evaluation. Further the OH grammar is already overly complex and full of problems, a hand wavy
is just going to cause more issues. For example the PH and SH tokens can appear in two different contexts, only one of those is likely to make sense for a “shopping Sunday”.
I’m not sure if we’re on the same page? “Shopping Sundays” as an EU concept does not mean you can shop there every Sunday. In fact, it meant almost exactly the opposite: just a 3-7 Sundays in the whole year is the place open on Sunday, on all other Sundays it must be closed (by law).
Saying Mo-Sa 08:00-17:00; Su 08:00-12:00 would be very wrong, as in 90% of days it is actually Mo-Sa 08:00-17:00; Su off and only in remaining 10% is it Mo-Sa 08:00-17:00; Su 08:00-12:00.
The difficulty lays in how to tag on which Sundays it is Su off and on which Sundays it is Su 08:00-12:00.
Looking at raw opening hours syntax would make a shop owner freak out any day of the week.
By “rendering”, do you mean a detail display when selecting a POI on a map or in search results? If so, yet another alternative is to explain the situation in a comment string, such as …; Su noon-17:00 "shopping Sundays" (translated into Polish, of course). It isn’t ideal, but at least the relatively few applications that understand opening hours syntax will handle it reasonably well.
Blue laws in the U.S. also vary by state, county, or even city. For the most part, these laws are uniform across the jurisdiction and throughout the calendar year, so I think mappers either tag them like normal opening hours rules or ignore them as implicit defaults. It sounds like it’s more complicated and a bigger deal in other countries though.
Unfortunately, in general, I don’t think U.S. mappers have been able to pay this much attention to whether opening hours are rock-solid in all the possible edge cases. Even the distinction between public holidays and school holidays is far too simplistic. In most places, a “public holiday” only means government employees and public school students get the day off, while private businesses and schools decide which holidays they want to observe.
This isn’t the kind of information you can gather by taking a photo of the store window on a random day of the year. Larger shops may advertise their upcoming holiday hours in the local news, while mom-and-pop stores might take off for vacation one week every summer without telling anyone in advance. Even the local commuter railway only announces their holiday schedule a few weeks in advance. I assume it gets reflected in their GTFS feed. Maybe we need a feed format for Shopping Sundays too.
Well, we do have opening_hours:url=*, so if a site have a RSS (or whatever) feed, it can be put there too. I doubt that many do, however; much less that they are in some standardized machine-parsable format