Ich habe gerade erst festgestellt, dass es einen check_date:surface-Tag gibt, der von StreetComplete durch die AddRoadSurface-Quest gesetzt wird. Siehe z.B. Way 416771368 aus Changeset 131539769.
Wie ist hier so die Meinung dazu?
Bei häufig veränderlichen Tags wie z.B. opening_hours oder collection_times verstehe ich einen check_date-Tag ja noch. Aber bei Straßenoberflächen?! Gibt es bald auch ein check_date:ref, check_date:highway, check_date:lanes an allen Straßen? Und bei Gebäuden bald ein check_date:building:levels oder check_date:addr:housenumber? So ein Tag hat meiner Meinung nach (außer in genannten Ausnahmefällen) nichts in der OpenStreetMap-Datenbank verloren.
Aus meiner Sicht sind diese Tags ziemlich überflüssig. Ich habe schon manchmal das angegebene Datum (in JOSM) erneuert, wenn ich die Info bestätigen konnte, aber ich empfinde das nur als Extraarbeit ohne Mehrwert.
Ich weiß ja nicht, wie das in euren Städten ist, aber hier wird auf den Straßen nach und nach Kopfsteinpflaster durch Asphalt ersetzt. Auf den Radwegen hingegen werden statt Asphalt inzwischen in der Regel Pflastersteine verwendet. Eine Abfrage alle 2 Jahre oder so halte ich für sinnvoll.
Wie @Discostu36 halte ich so einen tag schon sinnvoll, Dinge ändern sich und sollten regelmäßig überprüft/abgefragt werden.
Alternativ oder zusätzlich wäre die Verwendung von check_date:smoothness ebenfalls sinnvoll, wenn smoothness hinterlegt ist. In so einem Fall könnte check:date:surface entfallen, denn wenn ich mich Recht erinnere kann man vom SteetComplet aus bei der Abfrage nach smoothness die surface ändern.
Das sehe ich genau so. Es ist sicherlich schwierig den richtigen Prüfrhythmus zu finden. Aber irgendwann sollten alle in OSM erfassten Objekte überprüft werden.
Hier nicht. Und ich glaube es kommt häufiger vor, dass eine Bundesstraße mehrspurig ausgebaut wird, als dass sich surface=asphalt zu irgendetwas anderem ändert. Trotzdem gibt es kein check_date:lanes. Ich stimme dir allerdings zu, dass es generell schon sinnvoll ist, Tags regelmäßig zu überprüfen. Aber einen reinen Metadaten-Tag für einen anderen Tag, nur um eine Kontrolle anzustoßen, halte ich für den falschen Weg. Sonst gibt es irgendwann für jeden Tag noch einen zugehörigen Zeitstempel-Tag.
Hoffentlich gibt es irgendwann ein Feature wie das von @SimonPoole in #3 vorgeschlagene, bis dahin wird das Spammen von check_date-Tags wohl leider weitergehen. Aber ich vermute mal, das wird noch sehr lange Zeit Wunschdenken bleiben.
Eigentlich sollte man die changesets besser auswerten und auch qualitativ verbessern.
Ansonsten bräuchte man check-date an sehr vielen Objekten.
Generell finde ich, dass es in der Datenbank tendenziell zu viel Müll gibt, weil Objekte teilweise Jahre überleben obwohl sida längst nicht mehr gibt.
Egal ob Spielplätze, Parkbänken, Bushaltestellenhäuschen, Papierkörbe und und und - etwa alle 5 Jahre mal die Existens in Frage zu Stellen, macht schon Sinn.
Ich kann ja verstehen, dass man nach einer Möglichkeit sucht, die Aktualität der Daten irgendwie beurteilen zu können, aber es gibt ja diverse Probleme dabei, die eben keines dieser Tags löst. Hier mal ein paar Punkte, die mir spontan einfallen:
Daten zu realen Objekten können komplett fehlen, z.B. ist ein Haus im Wald auf Luftbildern selten zu erkennen und wird daher gerne gar nicht erfasst
Daten können ganz neu und trotzdem falsch oder zumindest umstritten sein.
Eine Straße mag super genau und mit allen Hausnummern erfasst sein, aber die nächste in 100 m Entfernung könnte trotzdem deutlich weniger detailiert erfasst sein,weil dort vielleicht nicht so oft jemand lang spaziert/radelt.
Ich behaupte: OSM wird dieses Problem nie los werden, das ist einfach eine Eigenschaft der OSM Daten, die im Prinzip der Datenerfassung vor Ort begründet ist.
Damit macht es für mich auch keinen Sinn, gegen dieses Problem zu “kämpfen”.
ich habe noch nie einen check-date-tag gesetzt und finde es schwierig, solche meta-Informationen mit den normalen Daten in der Datenbank zu vermischen. Grundsätzlich halte ich es für sinnvoll, die Informationen zu erfassen und bereitzustellen, das sollte aber spezifisch oder getrennt passieren und nicht in den “Sachdaten”, (die derzeitige “Lösung” in der Hauptdatenbank ist interimsmäßig evtl. bzw. anscheinend wohl akzeptabel aber man sollte sich dauerhaft nicht damit abfinden). Zu viele Nachteile (z.B. generiert man ständig neue Versionen selbst wenn sich überhaupt nichts ändert, theoretisch könnte man das in unendlich kleinen Zeitabständen machen)
Im Einzelnen ist es nur folgerichtig, nicht bei Öffnungs- und Leerungszeiten halt zu machen sondern das Prinzip auf alle Eigenschaften auszudehnen. Mein Vorschlag wäre, die entsprechenden tags zu filtern und in ein paralleles System einzuspeisen und dann aus den “OSM-Stammdaten” zu löschen. Evtl. wäre das auch ein Projekt, das die Foundation leiten könnte, zumindest ist es für das Gesamtprojekt m.E. höchst relevant.
Da gibt es regionale Unterschiede. Mancherorts werden die Pflastersteine gerne heraus gelöst und dann als Wurfgeschosse oder im eigenen Garten verwendet. Obwohl, halten tun sie dann immer noch.
Ich finde check_date an sich eine gute Sache. Gerade bei Informationstafeln in der Landschaft wie z.B. Wanderkarten, auch bei manchen Wanderwegen nutze ich dies, wenn ich die Attribute aktuell überprüft und aktualisiert habe. Dieses hilft auch mir, den Überblick zu bewahren, zu welchem Zeitpunkt die entsprechenden Objekte sich in dem Zustand befanden, wie in der Datenbank eingetragen. Dieses allgemeine check_date bezieht sich dann aber auch auf alle Attribute, d.h. ich signalisiere damit, dass ich alle erfassten Attribute überprüft habe. Das kann man aus einem Changeset so nicht herauslesen.
Jetzt mit check-dates von einzelnen Attributen zu arbeiten, finde ich ein wenig problematisch, da dies logisch fortgeführt zu mehreren check-dates pro Objekt führte. Allerdings ist mir klar, dass Street-complete nur immer ein einzelnes Attribut abfragt und daher auch nicht ein allgemeines check-date setzen kann.
wobei solche unspezifischen check-dates nicht unbedingt einfach in der Auswertung sind, weil man nicht nur den gegenwärtigen Zustand ansehen muss sondern auch in der History nachsehen muss, welche Attribute zum Zeitpunkt des Setzens bereits am Objekt waren. Und man kann nur dann das Attribut setzen, wenn man auch wirkllich alle tags versteht und geprüft hat.
Ich sehe check-date auch nicht als ein Attribut an, dass man in größerem Umfang auswertet sondern es ist aus meiner Sicht ein Hinweis, wenn man ein Objekt bearbeitet, wann es das letzte Mal komplett gecheckt wurde (und ob es ggf. sinnvoll ist, alle Attribute erneut zu überprüfen). Selbstverständlich sollte man ein allgemeines check-date auch nur eintragen, wenn man alle Attribute überprüft hat.
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.
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.
Übrigens auch viel haltbarer.