[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