Set key check_date:opening_hours after confirmation or change of key opening_hours

[urk58]

Idea: After a positive check of opening hours, regardless of whether the key was set first time, changed or even confirmed, an already existing key "check_date:opening_hours" shall be updated or - if not yet available - added with the current date.

[mnalis]

I agree it would be good idea, as that is very variable information and the use knowing it freshness is important¹

It seems that check_date:opening_hours is added (or updated) when we resurvey opening hours (regardless if the answer is same of new), but not when "Opening hours" is answered the first time -- in that case, only opening_hours is added (without check_date:opening_hours). Code

I too would suggest that in case of opening hours, check_data:opening_hours is always added.

Video:

small_Screen_Recording_20250914_003809_StreetComplete.mp4

Footnotes

1. having to search OSM history for entries when opening_hours was first added is not realistic to be done by most users/data consumers, while looking at check_date:opening_hours=* is much easier (and some data consumers support warning of that automatically, e.g. CoMaps. ↩

[urk58]

It seems that check_date:opening_hours is added (or updated) when we resurvey opening hours

I have different experience: Yesterday I checked opening hours with SC and changed them: https://www.openstreetmap.org/changeset/171862064
After that here is no check_date:opening_hours to be seen in the data set.

[mnalis]

After that here is no check_date:opening_hours to be seen in the data set.

Ah, yes, it seems it happens in some cases, particularly:

If check_date:opening_hours=* was set before, it would be updated when we changed the answer, but if it wasn't set, it won't be added for changed answer. It will be updated/added if:

• we indicate that the opening hours haven't changed (always), or
• we indicate that the opening hours have changed, and there already exists check_date:opening_hours=* or check_date=*

code

StreetComplete/app/src/commonMain/kotlin/de/westnordost/streetcomplete/osm/ResurveyUtils.kt

Lines 46 to 54 in fe300e9

	fun Tags.updateWithCheckDate(key: String, value: String) {
	val previousValue = get(key)
	set(key, value)
	/* if the value is changed, set the check date only if it has been set before. Behavior
	* before v32.0 was to delete the check date. However, this destroys data that was
	* previously collected by another surveyor - we don't want to destroy other people's data.
	*/
	if (previousValue == value || hasCheckDateForKey(key) || hasCheckDate()) {
	updateCheckDateForKey(key)

I agree with you that it would be best to update/add check_date:opening_hours=* in all cases when opening hours in particular¹ has been verified. But that is just me 🤷‍♂️

I think this message indicates why such conservative usage of check_date:opening_hours was implemented. In short, one would need to start a community discussion and see how wider OSM community feels about the idea.

If there are no objections, then it could be implemented. Would you @urk58 be interested in starting such proposal? Or someone else? (please do put link here if you do start the discussion, so other interested parties might join in).

Footnotes

1. i.e. I would not apply that practice to all tags/quests, but only for Opening Hours Quest, as that is the one which has very clear benefits applicable to end data consumers, and not only to mappers (which can, and should, always peruse history database). ↩

[urk58]

Before starting a community discussion I prefer to go through previous discussions about that topic.
Unfortunately the above link to "this message" does not work for me:
[Not Found

The requested URL was not found on this server.
Apache Server at lists.openstreetmap.org Port 443]

What do I need to do in order to get access?

[mnalis]

sorry, I dropped the "l" in that ".html". Fixed link https://lists.openstreetmap.org/pipermail/tagging/2020-July/054281.html (the rest of the thread is informative too, of course)

[matkoniecz]

See also #1836 #1651

[urk58]

Thank you, I did effort to look for already existing similar cases, but failed.

[matkoniecz]

it is much easier when you know for sure that some exist, so you can keep searching until something is found :)