Should/does SC remove duplicate pre- and postfix check_date/last_check tags?

[joshinils]

Use case
If an object has a check_date:opening_hours I may update the opening_hours via the existing quest.

What if the object also has an opening_hours:check_data, opening_hours:last_check, last_check:opening_hours or plain last_check or check_date?

• Should SC remove any of these tags and only use a single one?
• Should SC update two or more of these at once?
• Only the ones pertaining to the answered quest?

Proposed Solution
Remove duplicate tagging of the same thing and only use one tag for the checked tag(s). Thus removing any ambiguity.

[ygra]

There has been some discussion here regarding opening_hours:lastcheck before: #314

To clarify: this originated from a question of mine in the OSM DACH telegram group whether it'd be okay to just change opening_hours:last_check to check_date:opening_hours, as there are not many instances of that. And I noticed that

• Most mappers that update opening hours don't bother updating the :lastcheck tag as well
• StreetComplete adds a check_date:opening_hours when resurveying opening hours without them having changed, resulting in one outdated and one current tag

Most of that is trivial to fix by hand if one stumbles over it. Personally I don't believe it's StreetComplete's responsibility to fix up undocumented tagging silently.

[matkoniecz]

What if the object also has an opening_hours:check_data, opening_hours:last_check, last_check:opening_hours

Is it an existing problem or just suspected? I have faint memory that it is handled already.

Can you link changeset where this problem happens?

If you have any ability at all to read code I would grep for check_data etc through source code.

If you suspect such problem and you miss ability to read source code you can:

• disable automatic uploading in settings
• fetch data in area with such object
• solve quest
• undo edit and note which tags were changed
• undo the first step

[joshinils]

This came up in the German OSM-Telegram Group:
https://t.me/OSM_de/68779

[ Image with
check_date:opening_hours=2020-11-08 and
opening_hours:last_check=2017-02-04 ]
Sowas kriegt man dann auch gelegentlich. Und üblicherweise ist der Tag auch schon lange nicht mehr aktuell, weil die meisten Mapper das nicht aktualisieren und StreetComplete auch ignoriert.

[matkoniecz]

https://www.openstreetmap.org/node/186040985/history is the affected object

On checking: SC is ignoring opening_hours:last_check. Maybe it should be removed on such edit?

[matkoniecz]

On the other hand there is like 135 of such objects. If I would be fixing it then I would fix it by retagging such objects rather than by adding extra code to SC. I started from https://www.openstreetmap.org/changeset/114301124 and in this edit I removed over 1% of occurrences of this tag.

See https://taginfo.openstreetmap.org/keys/opening_hours%3Alast_check https://taginfo.openstreetmap.org/keys/check_date:opening_hours

So I would advice to retag such objects given extremely low rate of use.

[ygra]

It seems that the :last_check has been renamed to eventually become the check_date prefix: osmandapp/OsmAnd#10304 (comment)

[ygra]

opening_hours:lastcheck actually got a bit more usage at around 1300 instances. I've got an uncommitted changeset for changing all opening_hours:last_check to check_date:opening_hours, but I'm not sure I want to do that manually to 10× the number of entities.

Currently in the process of asking on the tagging ML how to proceed there. I can see three options, basically:

1. Do nothing. The remaining old tags and conflicts get cleaned up one by one eventually.
2. Change them to check_date:opening_hours with a date when the opening hours were indeed last updated.
3. Change them to check_date:opening_hours only when the date is indeed newer than the changeset that last updated the opening hours and remove the tag otherwise. This would match what StreetComplete currently does when updating opening hours, I think (at least it doesn't generate a check_date:opening_hours tag in that case.

The latter two options are possibly candidates for StreetComplete cleaning things up one by one (although that would still take a while ... I didn't find that many places where :last_check was outdated and StreetComplete users later changed or resurveyed the opening hours – it's a time-consuming quest compared to »what is the road surface here?«). MapRoulette would also be an option to clean that up a bit quicker, or just scripting it once.

[matkoniecz]

I would support mechanical edit replacing it - so (2). But many people are disliking bot edits for various reasons (including "it requires modifying objects what changes their last modification timestamp").

Also, note https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

[westnordost]

When a new check_date:<key> is set, StreetComplete deletes all previous

• <key>:check_date
• check_date:<key>
• <key>:lastcheck
• lastcheck:<key>
• <key>:last_checked
• last_checked:<key>

so, true, last_check:<key> and <key>:last_check are not removed. Because they practically do not exist. There is some last_check, but not really anything with last_check:<key>.

check_date etc. key, i.e. keys with no :<key> are not removed because the check_date is so unspecific that it may refer to not only the existence but a(n unknown) number of other tags that have been checked. So removing that tag would potentially destroy other information and/or other surveyor's workflows.

So, I think there is nothing to do here, it was a question anyway and it has been answered now.

[matkoniecz]

https://taginfo.openstreetmap.org/keys/opening_hours%3Alast_check is now gone :)

[ygra]

https://taginfo.openstreetmap.org/keys/opening_hours%3Alast_check is now gone :)

Yep, that was me recently, after I got positive feedback on that plan from the tagging mailing list. I haven't touched opening_hours:lastcheck, though, since StreetComplete will clean that up in time.