opening_hours:lastcheck

[OSMmapper]

Hallo,

ich habe die Tage ein paar Öffnungszeiten mit StreetComplete hinzugefügt.
Wenn ich dies normal via JOSM erledige, füge ich immer noch den "lastcheck" hinzu.

Daher meine Frage / Anmerkung ob es möglich wäre, bei einem Öffnungszeiteneintrag automatisch auch den "opening_hours:lastcheck" Stempel mit dem aktuellen Datum zu setzen.

Beste Grüße

[matkoniecz]

opening_hours:lastcheck is very rarely used and has no wiki page https://taginfo.openstreetmap.org/keys/opening_hours%3Alastcheck#wiki

there is https://wiki.openstreetmap.org/wiki/Key:check_date that may or may not be more popular

[derfasthirnlosenick]

Also needed for #112
Sadly, there seems to be no consensus on the tags used. survey:date is the most popular, but only indicates the survey of the entire object - not neccessarily a single aspect thereof such as opening hours. Since this is what we're doing with StreetComplete, check_date might be more appropriate.

I'd say that there not being a clear consensus shouldn't deter from using one of the tags as the usefulness is quite high.

[westnordost]

I kinda do not like to put data like this into the map itself. I thought putting things like source=GPS survey was a thing of the past? lastcheck, check_date etc. seems like the same thing in green.

You can get the last edit date of any such tags by digging through the element history, JOSM has this feature. Of course, I have to admit that it is unnecessarily complex. I'd rather much like an OSM API addition that simply adds a last_edited field to every tag. But then again, waiting for an API change is not that a good idea to get something done.

... So, I don't know.

Perhaps add a checkdate tag after all and hope that this will somehow be added to the api later (as it had been done with the introduction of changesets) when power users complain about being swamped by checkdate tags enough?

In any case, this ticket should be about adding a check_date for ALL changes that are made through StreetComplete.

[westnordost]

Thinking about it, I think one could conclude from looking at the last edited date of any element whether an element requires re-survey in general (regardless of specific tags) or not. I.e. if a node tagged with shop=bubbletea lays rest for a year with no changes, it is something that needs to be resurveyed because perhaps it vanished altogether.
This assuming that anyone who visits the place and edits any tag and/or the location of it will also have had a look at the other values. This is not always the case, but if a closed bubbletea shop stays unnoticed for another year, that is also not that bad. It will eventually be found.

[derfasthirnlosenick]

I guess for the time being, there's only a handful of things that would warrant a timestamp of the last survey:

• Opening hours (yearly? Half yearly?)
• Construction sites (monthly?)

As you said, existence of a business probably could be done by last change to the node instead of a survey date.

Construction sites would be a new quest ("is this site still under construction?"), so only for hours the current behavior would change.

For everything else, there's almost no downside to not having the tag. If OSM allows us to put the last changeset of the parameter, that'd be fine I guess. If this isn't possible, adding survey dates for a few select parameters might be the most sensible option.

[derfasthirnlosenick]

Thought about it once more and figured out my old rationale again.
If a shop is resurveyed, there are two options:

1. There are changes -> update indicated by changeset date
2. There are no changes -> no changesset, therefore noone knows if the info is current or not.
   https://wiki.openstreetmap.org/wiki/Key:check_date specifically mentions construction sites, opening hours and collection times and recommends mapping parties for elements with potentially outdated info.

Existence of a shop would be covered by this as well, since the check would issue a changeset.

[matkoniecz]

Main problem is that app starting to use nonstandard tag will be certainly controversial (complaints will mention littering in tag properties, using weird tags and claim that it is undiscussed mass edit/import/evil).

I am not sure is it a good idea, though currently there is no good way to differentiate between stable and outdated opening hours.

[westnordost]

One thing to consider: It should be possible to "touch" elements by uploading them into a changeset without any actual change. This will change the version number and last edited date. Whether this technique is preferable or not is open for discussion. Am 14. Juni 2017 08:20:46 MESZ schrieb derfasthirnlosenick <notifications@github.com>:

…

Thought about it once more and figured out my old rationale again. If a shop is resurveyed, there are two options: 1. There are changes -> update indicated by changeset date 2. There are no changes -> no changesset, therefore noone knows if the info is current or not. https://wiki.openstreetmap.org/wiki/Key:check_date specifically mentions construction sites, opening hours and collection times and recommends mapping parties for elements with potentially outdated info. Existence of a shop would be covered by this as well, since the check would issue a changeset. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #314 (comment)

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[westnordost]

Will reconsider for next release

[westnordost]

Alright, I thought about this once more, also because I got the feature request from my local community to add check_date when adding the collection times for post boxes because someone actually got a script that checks for that and shows post boxes that have long not been checked for updated collection times.

I decided that this app will not add check_date to post boxes / opening hours.

The reason is that such scripts which look for possibly outdated information will need to not only look for elements with check_date / lastcheck older than X but also for elements that do not have this tag set but haven't been changed for time X, anyway. After all, the vast majority of opening hours and collection times are not annotated with check_date. Even if StreetComplete started to always add this tag, it would not change the situation for such tool writers, because StreetComplete is just one editor of many.

It is now possible with Overpass, to filter by changed date, so it is technically relatively easy to do.

I think it very much makes sense to tag check_date on e.g. post boxes that already had collection times set when you resurvey the place (and find that they haven't changed). However, this is something that one can currently not do in StreetComplete, only new tags can be added. But when StreetComplete will gain this ability, then it will also tag check_date unless there is a better solution available by that time.