check_date für 2018

Moin!

ich habe einige Overpass-Abfragen mit Kartendarstellung für check_date und deren Alternativ-Tags.

Diese habe ich nun für 2018 angepasst.

Vielleicht sind diese für den einen oder anderen von Interesse:

Telephone

http://overpass-turbo.eu/s/uo3

Postkasten - Icon

http://overpass-turbo.eu/s/uo6

Postkasten – ohne Icon

http://overpass-turbo.eu/s/uo8

Check-Date allgemeine

http://overpass-turbo.eu/s/uo9

Tankstellen – Checkdate

http://overpass-turbo.eu/s/uoa

Grß Jan

Schön, dass du solche Karten bereitstellst.
Im Wiki sind noch eine mehr Tags mit gleicher Bedeutung aufgeführt, z.B. das weitaus häufiger verwendete survey:date (mittlerweile fast 400.000-mal verwendet). Kannst du bitte deine Abfragen entsprechend anpassen?

Survey:date ignoriere ich, weil nach meinem Kenntnisstand die meisten über ein Tool bei der Erfassung entstanden sind.

Check_date und seine Varianten entstammen aber den wirklichen Überprüfungen.

Jan

Die Begründung verstehe ich nicht: jeder von uns benutzt doch ein Tool bei der Erfassung oder schreibt jemand mit dem Finger die Daten in die Datenbank?

Ich verstehe die Begründung schon: er hat die Befürchtung, dass survey:date automatisch an ein Element hinzugefügt wird, unabhängig davon ob es tatsächlich überprüft wurde oder nicht.

Ach so, jetzt ist es mir klar.
Das bringt uns wieder zur Frage, welcher Schlüssel denn nun generell für die Überprüfung der Daten zu nehmen ist. Ich erinnere mich, dass man sich mal im Lübecker Stammtisch auf lastcheck oder checkdate geeinigt hätte, aber das ist ja nun mal nicht für die gesamte OSM-Community bindend und aus der zitierten Wiki-Seite gehen Jans Befürchtungen auch nicht hervor. Welcher Schlüssel ist denn jetzt der allgemein akzeptierte Gold-Standard?

Woher weißt du das?
Ich benutze survey:date und ändere das Datum, wenn ich die Öffnungszeit oder die Leerungszeit mal wieder
überprüft habe. Welches tool schreibt denn survey:date in des Datensatz?

https://wiki.openstreetmap.org/wiki/Keypad-Mapper_3
Wobei man da nicht direkt hochladen kann, sondern es wird eine .osm-Datei erzeugt, die man dann mit z.B. JOSM weiter verwursten muss. (Ich persönlich entferne bei diesem Schritt das survey:date tag)

Ich verwende survey:date - für das Erkundungsdatum von surface und smoothness von highways - weil das zu Beginn das meist verwendete Tag dafür war.

Grüße aus Oberschwaben

Das ist damit gleich dem Datum vom changeset Version 1.

Jan

Was ist damit gleich?

Noch mal ganz langsam:
Man sollte direkt ein tag an den node/way schreiben, ob unterwegs auslesen zu können, ob bestimmte Werte, wie Öffnungszeiten, Leerungszeiten oder andere Dinge, die sich relativ oft ändern, noch aktuell sind, um sie gegebenenfalls zu korrigieren.

Ich nutze dafür OSMAND, weil ich die Software sowieso auf dem Smartphone habe und andere Mittel AFAIK dafür nicht geeignet erscheinen.
Mit OSMAND kann man, wenn man einen entsprechenden node aufruft, über dieses tag sehen, wann zum letzte Mal jemand diesen node geändert hat bzw. geguckt hat, ob die Daten noch stimmen. Die Daten werden von OSMAND direkt aus der Datenbank ausgelesen (funktioniert deswegen nur online).
Wenn ich das tue, ändere ich einfach die entsprechenden Werte und/oder das Datum.
Damit kann sich jeder, der ein gleiches oder ähnliches Werkzeug benutzt, von der Aktualität überzeugen.

Was passiert anderes bei check_date? Was qualifiziert check-date gegenüber survey:date?

Die Handlungen, die derjenige, der die Werte überprüft, vornehmen sollte, sind prinzipiell gleich. Wie die Werte in die DB kommen, ist dabei unerheblich. Wichtig ist allein, dass jemand die Daten überprüft hat und diese mittels eines Datums in der DB dokumentiert.

Der Vorteil, den ich bei survey:date sehe, ist die wesentlich größere Anzahl der Werte in der Datenbank.

Gibt es auch ein Tag um zu markieren, dass ein bestimmter Tag, z.B. die smoothness dann und dann überprüft wurde? (Also nicht sämtliche Eigenschaften einer Straße sondern nach Tag)

Als wir Ende 2016 auf Anraten hier in Forum beim Hamburger Stammtisch für uns beschlossen haben, nun auch einheitlich “check_date” zu verwenden, entsprach Jans Aussage auch den von uns gemachten Beobachtungen. Die größere Anzahl von “survey:date”-Tags entstammte in erster Linie Edits an Häusern und Flächenobjekten, die hoffentlich auch wirklich vorher einmalig überprüft worden sind, aber wohl auf absehbare Zeit sich wenig ändern werden.
Dagegen waren sich rasch ändern- oder verschwinden könnende Objekte - wie z.B. Postkästen, Telefone u. Recycling - mehrheitlich mit Varianten von “lastcheck” und “check_date” versehen.
An diesem Verhältnis hat sich hier im Norden nicht entscheidend etwas geändert. Daher plädiere ich (!) dafür, es bei “check_date” zu belassen und nicht jedes Jahr eine neue Kuh durchs Dorf zu treiben.

Hallo Tobias,

natürlich kannst du auch die einzelnen Tags separat mit einem Prüfdatum versehen, z.B.
check_date:smoothness=2018-01-17
( https://wiki.openstreetmap.org/wiki/Key:check_date ).
Allerdings stellt sich mir dann schon die Frage, wenn du das in deine App einbauen willst, ob es dann nicht ein wenig zu viel des Guten wird und man nicht lieber ein Gesamtüberprüfungsdatum nutzen sollte.

LG