Wenn man im JOSM die (interne) History eines Objekts aufruft sieht man seit welcher Version der Tag zuletzt so gesetzt wurde. Und dies funktioniert im JOSM ohne die check_date:* Tags.
Sowas sollte auch bei SC möglich sein.
2 Likes
Und wie soll das funktionieren, wenn der Wert sich nicht ändert und man die Korrektheit des Wertes dokumentieren möchte?
3 Likes
Vielleicht ist es gar nicht so sinnvoll oder nötig die Korrektheit ener Angabe zu dokumentieren. Solange ein Mapper nicht vor Ort vorbei schaut und prüft ob z.B.: 'ne Bank oder wie jetzt aktuell die Telefone der Telekom noch vorhanden ist. Ganz im Enst man braucht die check_date:* Sache nicht. Gerade bei den Telefonzellen wurden einige vor Jahren abgeabaut. Das hat auch jahrelang keinem interessiert.
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.