Wozu sollte das gut sein? Soll jeder Mapper auf “seine” x Objekte aufpassen und jeden Tag dran schreiben, dass sie sich nicht geändert haben? Welchem Anwender nutzt das? Gibt es eine Anwendung, die nur solche Daten verwendet, die in den letzten n Tagen geändert wurden?
Weiß ich nicht, aber es gibt Anwendungen, die einen darauf hinweisen, wenn ein Objekt, vor allem solche genannten wie Bänke, Mülleimer, Telefone seit x Jahren nicht mehr angefasst wurden.
2 Likes
Dann kannst Du herausfinden, ob eine Information noch aktuell ist oder nicht. Sei es für Dich als Datenverwender (“Gibt es den Bäcker wirklich noch, der vor 15 Jahren das letzte Mal bearbeitet wurde?”) oder für QA. Somit können veränderliche Daten nach bestimmten Zeiträumen überprüft werden. So fragt SC jemanden, der dort vorbei kommt, ob es z.B. noch die Sitzbank gibt oder nicht. Ich halte das für sehr sinnvoll. Auch für andere veränderliche Daten wie die Wegoberfläche.
6 Likes
OK, die App SC speichert also in OSM Daten, die sie benutzt, um besser zu funktionieren. Für andere, die SC nicht benutzen, sind diese Daten eher störend. Sollte SC da nicht besse eine andere (eigene)Datenbank benutzen?
2 Likes
Also check_date & Co. ist jetzt keine Erfindung von SC!
Und ich möchte die Info, ob ein Datum aktuell ist oder nicht schon in der OSM-DB vorfinden können.
5 Likes
I find the check_date* data useful in other editors too.
Perhaps instead someone might make a feature request for JOSM to implement Advanced Preference named ignore_tags where user might specify regex for tags that they don’t want ever to see, so people who find it annoying might happily ignore them?
5 Likes
I can’t see how that would work. Let’s assume I have such a filter installed in JOSM and I update the surface of a road or the smoothness or whatever and someone added a tag like check_date:surface or whatever. Would JOSM then remove the check_date* tag(s) because they are considered invalid? Or would they be updated automatically without me knowing them?
Kannst Du mir erklären, wie / wobei Du das nutzt?
There are few ways to go. Advanced preference ignore_tags=^check_date(:.*)? might for example just skip showing such tags in Tags pane.
For data consistency issue that you mention (and orthogonal to the ignore_tags - i.e. would be useful even if ignore_tags is not implemented!), JOSM could (should!) include a Validator that warns (and offers to Fix by removing it) when tag xxxx has been changed by JOSM, but check_date:xxxx exists on that element and has not been changed.
Wenn ich wissen möchte, wann ein Wert überprüft wurde/ wie aktuell ein Wert ist, sehe ich nach welches Datum bei check_date(:*) eingetragen wurde. Dann kann ich die Aktualität von dem Wert einschätzen.
Wenn es den Tag nicht gibt, versuche ich das über die History nachzuvollziehen, wann der Wert gesetzt wurde bzw. wann das Objekt mit survey angepasst wurde und ob der Wert aktuell sein könnte. Das ist dann aber mehr Methode Glaskugel.
Mir ging es mehr um die Frage, wann man sich dafür interessiert, wann etwas eingetragen wurde.
Ich interessiere mich nur dafür, wenn z.B. eine Straße in OSM mit surface=sand eingetragen ist, ich aber eine gut asphaltierte Straße langgeradelt bin. Dann schaue ich manchmal in der Historie nach, wie lange da schon der alter Wert drin steht. Wenn ich dann sehe, dass das erst vor kurzem passiert ist, dann werde ich vorsichtig, ob vielleicht die Straße länger ist als gedacht. Da hilft mir aber so ein check_date auch nicht weiter, weil ja nicht klar ist, welches Ende vorher betrachtet wurde.
Bezogen nur auf surface oder allgemein?
Allgemein. Ich sehe einfach keinen Mehrwert in den Extra Tags. Jetzt, wo sie noch ganz neu sind, mögen sie ja halbwegs mit den erfassten Daten übereinstimmen, aber wenn mal ein paar Jahre ins Land gezogen sind, dann findet man vermutlich Updates am Objekt, die das check_date nicht geändert haben. Umgekehrt gibt ein nicht vorhandenes check_date doch keinerlei Auskunft darüber, wann da jemand zuletzt die Realität mit OSM abgeglichen hat.
1 Like
Gerade am Wochenende als Datennutzer wieder erlebt: opening_hours veraltet und ich stand vor verschlossener Tür. Ein check_date:opening_hours hilft mir einzuschätzen, ob eine Angabe aktuell ist oder nicht.
Eine Anwendung könnte diese Information z.B. anzeigen:
Bäckerei Meyer
Öffnungszeiten:
Mo-Sa 06:00-18:00 Uhr
So geschlossenStand: 13.03.2023
6 Likes
Und wenn das “Stand 13.03.2023” fehlt, gehst Du davon aus, dass die Daten vermutlich falsch sind?
Ja. Dann oder wenn check_date sehr lange zurück liegt, würde ich z.B. dort vorher anrufen, auf der Webseite nachsehen etc.
Als Mapper schaue ich mir auch ab und zu das OSM-Objekt an. Wann wurde es erstellt, letzte Bearbeitung etc… So etwas machen meine Eltern nicht. 
Beim Mappen, verschwende ich keine Zeit für Informationen, die erst kürzlich überprüft wurden. Da achte ich sehr auf check_date & Co. Es hilft mir auch Änderungen und Daten zu beurteilen. z.B. bei Konflikten (surface vs. track_type habe ich z.B. oft): Ein track_type=grade4 + surface=asphalt (seit 10 Jahren) + check_date:surface=vor ein paar Wochen wäre sehr hilfreich.
6 Likes
Wenn man sich das Mitbewerber Produkt vom großen G ansieht steht bei den Öffnungszeiten auch gelegentlich “wurde am … von Besitzer aktualisiert” . So einen Aussage weckt vertrauen das die Daten so in Ordnung sind.
Ganz ähnlich könnte unser check:date sein, so wie von @OSM_RogerWilco oben aufgeführt.
Ich wäre natürlich auch froh, wenn ich allen Daten in OSM vertrauen könnte. Aber ich finde es ziemlich absurd, jetzt nur den Daten zu trauen, die mit der SC App erfasst wurden. Da überlege ich mir, ob ich überhaupt Öffnungszeiten erfassen soll (habe ich allerdings eh nicht oft gemacht, eben weil die sich seit Corona so oft ändern)
check_date wird ja nicht nur von SC verwendet. Aber SC trägt in manchen Gegenden sehr dazu bei, dass die Daten vor Ort überprüft werden und - ganz wichtig! - diese Kontrolle auch dokumentiert wird.
3 Likes
ganz richtig. Z. B. kann man das mit OSMGo! ebenfalls. Der Unterschied ist jedoch, dass OSMGo! den ganzen Poi abfragt und nicht nur einen einzelnen Aspekt. Und bei OSMGo! kann man zwischen check_date und survey:date auswählen.