opening hours that differ in e.g. summer are not displayed in resurvey

[mnalis]

(Opening a new issue as suggested in https://github.com/streetcomplete/StreetComplete/issues/6164#issuecomment-2731495036)

How to Reproduce

• open a node which has a more complex opening_hours which are due to resurvey (as e.g. node 1990156785 with valid opening_hours of Mo-Su 06:00-22:00; Jun-Sep Mo-Su 06:00-24:00; PH off). Note that having default opening_hours which are overriden in summer (as in that example) is common practice at least in summer-tourism-bound countries like Croatia (and is signed as such on the doors: having a regular opening hours sign, and then an additional sign with "override" for summer / holidays).
• see that resurvey quest kicks-in
• however, clicking on the quest user is presented with zeroed-out (empty) opening_hours. That is both annoying to the user (who has to engage in complex task of filling-in data from scratch) and damaging to existing data (which was likely more precise and versatile then what user will enter via SC on such resurvey).

https://github.com/user-attachments/assets/af65d4e3-7244-4309-9990-e460a7c3e5b5

Expected Behavior From more preferred at the top to less preferred at the bottom:

• ideally, I would expect the SC to parse those opening_hours, and present it for editing to user in SC-compatible format (e.g. as Oct-May Mo-Su 06:00-22:00; Jun-Sep Mo-Su 06:00-24:00; PH off in this case). That way, user could detect and correct any inaccuracies in existing UI, while the data would remain preserved.
• if that is too complex, I would expect that SC would skip resurvey on such opening_hours that are too complex for it to handle. (i.e. do not needlessly zero-out valid existing data and ask user to re-enter it from scratch)
• or, at the very least, to warn the user that it is about to nuke existing valid opening_hours if the user proceeds with updating them.

Versions affected SC 60.3, Android 14

[Peter0]

Thanks for pointing out the idea similar to #6164's one in a more detailed way.

[matkoniecz]

OK, overwrite syntax makes sense for month ranges - at least in my opinion

so I think that SC should be changed in this aspect

[westnordost]

IIRC StreetComplete UI shouldn't have a problem with displaying such opening hours. It is even possible to specify them.

[westnordost]

Hm, not quite.

It looks like

(Not specified):
--------------------
Mo-Fr 08:00 - 12:00

June-July:
--------------------
Fr, Sa 08:00 - 18:00

And it tags it using the additional rule separator. I.e. in this case, in June-July the place would be open Mo-Th 8-12 and Fr-Sa 8-18

[westnordost]

Turning it around in my head, I am not sure if one interpretation or the other can naturally always be assumed to be meant when encountering opening hours signs like e.g. this

Mo-Fr 8-12
June-August: Sa, So 10-18 

are encountered in the real world. (I.e. in June, is it open during the work week too?)

Often, I guess, the ambiguity wouldn't matter, because summer opening hours are usually more extended as during winter, so overwrite vs additional doesn't matter. But businesses could of course write it the other way round (general opening hours + more limited opening hours in winter). Then, it would matter which was it should be interpreted.

[mnalis]

are encountered in the real world. (I.e. in June, is it open during the work week too?)

If the original string was Mo-Fr 08:00-12:00; Jun-Aug Sa,Su 10:00-18:00 then I guess it might be looking suspicious to (non-AGI) existing "suspect checks" code (even it would make sense to human that this amenity only has extra working weekends in the summer); but I still think that the SC parsing it to its internal format and then displaying for editing:

September-May:
  Mo-Fr 8-12
June-August:
  Mo-Fr 8-12
  Sa-Su 10-18

would be a very nice solution for all use cases, making it both easy to spot and correct bugs, while not breaking existing opening hours. And, human would be making the decision! (I would much prefer that to what is currently happening, i.e. blank opening_hours being presented).

But, I don't know enough SC internals to know if that might be relatively easily doable 🤷

Often, I guess, the ambiguity wouldn't matter, because summer opening hours are usually more extended as during winter,

Uh, not really... For example, in Croatia, it absolutely depends on the region; i.e. In the summer here:

• working hours are hugely reduced (to the point that some amenities are completely closed!) in the continental Croatia (even in e.g. capital of Zagreb) because most people went to the vacation on the seaside - both customers and the workers! Like, 90% of all-year vacations of Croatian workers are spent in July and August for the purpose. It is so prevalent, that we even have a term "kolektivni godišnji odmor" ("whole-collective vacation") in our laws

but also

• working hours are hugely increased on the seaside (e.g. Dalmatia) as most of the Croatian citizens as well as dozens of millions of tourist are there (and people working there make more profit in a single summer month than in the whole of spring,autumn and winter combined, so it is highly profitable for them to work double or even triple shifts there)

But that could be completely reversed in some other country -- e.g. I'd guess that Swiss Alps regions have more tourists (and thus, more financial incentive to have more amenities open for longer) during winter (e.g. people going there for skiing) then during (say) autumn.

[westnordost]

But, I don't know enough SC internals to know if that might be relatively easily doable 🤷

It would require an additional step after parsing the opening hours: Canonicalizing them. I.e. transforming certain not-displayable-but-otherwise-valid opening hours in the manner you described into opening hours that mean the same but have a syntax that would be displayable in StreetComplete.

The code for opening hours parsing and validation is in the de.westnordost.streetcomplete.osm.opening_hours.parser package, OpeningHoursValidator.kt checks if the parsed opening hours are supported by StreetComplete, OpeningHoursParser.kt transforms them into a StreetComplete-internal data model for display (if they are supported by StreetComplete).

Implementing this would involve

1. adapting OpeningHoursValidator.kt to accept opening hours with overwriting rules that collide (i.e. not check at all for collision, instead, ....)
2. after validation, transform these opening hours into something that can be displayed in StreetComplete, i.e. remove all weekdays from rules that appear earlier in the string that collide with weekdays from rules later in the string. This code should best go into an own file, e.g. OpeningHoursCanonicalizer.kt or something. It requires perfect unit test coverage.