[Tagging] Retagging open_hours:last_check to check_date:opening_hours

s8evq s8evqq at runbox.com
Sun Nov 28 12:00:26 UTC 2021


It's a great idea. I think option 2 or 3 would be the best, in my opinion.


On Sun, 28 Nov 2021 09:48:32 +0100, Johannes Rössel <osm-tagging at hypftier.de> wrote:

> Good morning, list.
> 
> Recently while updating opening hours from photos I took, I came across 
> opening_hours:last_check (which was way outdated). I first chose to 
> update it to the current date, but for the next POI there actually were 
> both opening_hours:check_date (way in the past) and a somewhat more 
> recent check_date:opening_hours. So that got me thinking whether there 
> should actually be two tags here.
> 
> Most of the oh:cd date from around 2016. Most of the cd:oh (at least the 
> conflicting ones in this dataset) were created by StreetComplete (which 
> also uses them to determine when to re-check opening hours). Digging 
> around a bit, it seems that the :last_check and :lastcheck suffixes were 
> eventually folded into the check_date: prefix.
> 
> So would it be okay to re-tag both
> 
> opening_hours:last_check (about 130 instances) and
> opening_hours_lastcheck (about 1300 instances)
> 
> to check_date:opening_hours? I've actually got an uncommitted changeset 
> for the first one lying around here. And there are two things I've noticed:
> 
> 1. The tag is frequently out of date. Not only because StreetComplete 
> ignores it, but also because manual mappers often ignore and don't 
> update it.
> 2. Stemming from StreetComplete ignoring it, there are sometimes both 
> oh:lc and cd:oh when opening hours are resurveyed.
> 
> Thinking about it a bit more since yesterday there are probably four 
> ways this could be done:
> 
> 1. Do nothing.
> 
> 2. Change the two tags to check_date:opening_hours with the actual date 
> the opening hours have last been updated.
> 
> 3. Change to check_date:opening_hours only if there has been resurveying 
> of the opening_hours and the last check date is newer than the actual 
> opening_hours change and remove the tag otherwise. This is basically the 
> result of what StreetComplete usually does, as far as I can tell 
> (check_date is only added when resurveying and nothing has changed). 
> However, it's unlikely to appear from what I've seen so far, as the old 
> tags are rarely updated.
> 
> 4. Only resolve the conflicts between oh:lc and cd:oh where both appear 
> and keep cd:oh with the newest date. This only affects 17 objects, though.
> 
> 5. Do nothing now, but implement checks and fixes for JOSM/iD/Osmose/...
> 
> In terms of how this could be done ... I'm not sure I'd really want to 
> ot 10× the objects by hand, at least not alone. Options 2 and 3 could be 
> scripted. It requires looking at the history, but is a fairly mechanical 
> process. Other options would be MapRoulette to get it done fairly 
> quickly. Or let StreetComplete clean up the old tags when updating an 
> object (this may take quite a while, but the SC maintainers may not like 
> to implement such things that are likely a one-time global fix if done 
> differently). And there's always option 5 if a global change if deemed 
> to destructive. Although it mostly seems to affect Southern Germany and 
> little outside of that area.
> 
> Any opinions?
> 
> Regards,
> Johannes
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging





More information about the Tagging mailing list