POI aktuell halten

Jein. Denn allein aus der Tatsache, dass es eine neue Version eines Elementes gibt, kann man noch nicht schließen, dass auch jemand etwas vor Ort kontrolliert hat. Es kann auch einfach eine technisch bedingte Änderung sein (z. B. Weg aufgetrennt) oder jemand hat einfach nur vom Schreibtisch aus die Punkte nach Luftbild neu verschoben, aber nicht kontrolliert, ob das, was er verschiebt, überhaupt noch da ist. Umgekehrt geht es auch um die Dokumentation der Fälle, in denen sich nichts geändert hat, um zu vermeiden, dass dort jemand zur Kontrolle hinläuft, obwohl erst letzte Woche jemand dort war.

Ich wüsste auch nicht, wie man das im Changeset in einer auswertbaren Form unterbringen sollte.

Kann ich jetzt nicht ganz nachvollziehen. Wenn ich deinen Link von oben in Firefox für Android öffne, habe ich ganz normal den Editor und kann dort beliebig die Abfrage bearbeiten und danach ausführen.

Jo, da ist meine DB der selben Meinung:


select count(check_date) check_date,
       count("survey:date") "survey:date",
       count(lastcheck) lastcheck
  from v_checking;

 check_date | survey:date | lastcheck 
------------+-------------+-----------
      10372 |      183733 |      5059

Gruss
walter

ps: Weltweit alle POI als Node.

Und täglich grüßt das Murmeltier…gibt im letzten Jahr mehrere Diskussionen dazu, auch hier
http://forum.openstreetmap.org/viewtopic.php?pid=555863#p555863

Die hohe Anzahl von survey:date ist wohl teilweise Importen geschuldet und konzentriert sich auf Gletscherrandlagen in der Antarktis.
http://taginfo.openstreetmap.org/keys/survey%3Adate#map

Ich werfe noch mal zwei Links in die Runde zu dem Tool aus Landshut
http://wiki.openstreetmap.org/wiki/Landshut_Projekte#2015-12-08_POIs_aktuell_halten

Und hier direkt zur Auswertung
http://osm.edvbl.dyndns.org/poi_lastcheck/

Gruß
geow

Nur zum geringen Teil. Ich habe jetzt mal über Deutschland in Overpass-Turbo die Abfrage über lastcheck, check_date und survey:date laufen lassen. Das Ergebnis ist wie folgt:

lastcheck: 4783 Nodes, 2992 Ways, 117 Relations
check_date: 8691 Nodes, 1303 Ways, 46 Relations
survey:date: 34090 Nodes, 11175 Ways, 2 Relations

Die Abfrage funktioniert im Prinzip wie folgt:


area[name="Deutschland"][admin_level=2]->.schland;
node(area.schland)["lastcheck"];
out ids;
way(area.schland)["lastcheck"];
out ids;
rel(area.schland)["lastcheck"];
out ids;

Zu beachten ist, dass auf der Karte nichts angezeigt wird (würde nur unnötig Rechenleistung schlucken), sondern dass man das Ergebnis auf der Datenseite erhält und anschließend beim Zurückschalten auf die Karte unten rechts die Statistiken sehen kann. lastcheck ist entsprechend durch die anderen Werte zu ersetzen.

Wenn man sich nun die Ergebnisse anschaut, dann ist neben der offensichtlichen Tatsache, dass survey:date auch in Deutschland mit Abstand am gebräuchlichsten ist, auch zu berücksichtigen, dass lastcheck und check_date praktisch nur nationale Eigenheiten sind. Bei lastcheck haben wir hier in Deutschland 4783 + 2992 + 117 = 7892 von weltweit 8225 Objekten, das entspricht satten 96 %, bei check_date sind es 8691 + 1303 + 46 = 10040 von weltweit 13838 Objekten, das entspricht 73 Prozent. Bei survey:date sind es dagegen 34090 + 11175 + 2 = 45267 von weltweit 244301 Objekten, das entspricht 19 Prozent.

Warum die Ids ermitteln, wenn nur die Anzahl interessiert? Dafür gibt’s ja auch out count;


area[name="Deutschland"][admin_level=2]->.schland;
(node(area.schland)["lastcheck"];
way(area.schland)["lastcheck"];
rel(area.schland)["lastcheck"];
);
out count;

Ergebnis (unter “Daten” zu finden):


  <count total="7892" nodes="4783" ways="2992" relations="117"/>

Das ist bei mir auch so, es hängt mir CodeMirror zusammen und lässt sich unter “Editor” → “Codemirror aktivieren” abstellen.

Hi

geow - danke für die Links, den ein oder anderen hatte ich noch nicht gesehen. Dass diese Diskussion ein Wiedergänger ist, zeigt doch, dass dieses Thema vielen am Herzen liegt, was mich freut, und andererseits, dass es offensichtlich noch keine befriedigende Lösung gibt.

Richtig, das rutscht bei meinem Ansatz wie oben geschrieben durch. Aber gibt es wirklich POI, die über mehrere Generationen fälschlicherweise eine neue Version bekommen?
Meine Auswertung zeigt zweifelfrei, dass sich seit x Tagen niemand mehr um dieses Objekt gekümmert hat. Das bedeutet entweder “nichts genaues weiss man nicht” oder “alles noch so OK wie es eingetragen ist”. Mit zunehmender Zeit wird ersteres naturgemäß immer wahrscheinlicher. Daher kontrolliere und korrigiere ich “nach bestem Wissen und Gewissen”. Letztere Fälle markiere ich mich check_date.
Dieses Vorgehen beschert mir aktuell über 600 POI, die älter als ein Jahr sind, genug Arbeit um ein paar zu “übersehen”.

Bei einem konsequenten Vorgehen mit check_date (oder was auch immer) wird es doch erst richtig spannend. Man wird immer im unklaren bleiben, ob jemand nur im Vorbeifahren gesehen hat, dass es die Kneipe noch gibt, oder wirklich kontrolliert hat, ob der wheelchair access auf dem Damenklo noch korrekt ist - es sei denn wir kleistern die Nodes mit einer Vielzahl von check_date:… zu.
Was ist wenn das check_date deutlich älter ist, das der Timestamp? Technische Änderung? Check_date nicht aktualisiert? Wir können dieses Thema nicht komplett lösen.
Was ich beitragen möchte ist, dass OSM nicht zu einer Datenmüllhalde wird, mit Elementen, die über Jahre als Karteileiche ihr Dasein fristen… und unbedarfte Benutzer dann sagen “Das hat doch schon ewig geschlossen und steht hier immer noch, OSM ist Mist”. Jeder kennt solche Fälle bei der kommerziellen Konkurenz, oder :slight_smile:

Schönen Abend!

Man könnte auch einfach mal anfangen, OSM Notes zu bearbeiten.

https://www.openstreetmap.org/#map=14/51.5139/7.4680&layers=N

Verstehe ich nicht. Wenn CodeMirror deaktiviert ist, fehlen natürlich solche Annehmlichkeiten wie Syntax Highlighting. Aber man kann doch trotzdem editieren (also ich zumindest).

Da ist bei mir ein schwarzes Loch. Die nächste ist erst 12 km weit entfernt. :wink:

Die Anmerkung “(auf mobilen Geräten deaktivieren; Änderung wirkt erst nach App-Neustart).” passt schon. Mit aktivem CodeMirror kann ich die Query nicht anpassen unter Chrome, sowohl auf Android als auch iPhone.

Mit Firefox für Android habe ich da sowohl mit als auch ohne CodeMirror kein Problem (mit ist natürlich schöner). Insoweit für mich wirklich in keinster Weise nachvollziehbar.

Ich finde es nicht sooo gut, jedes überprüft eObjekt mit lastcheck oder welchem tag auch immer zu versehen - wenn sich das durchsetzt, wird es die history unnötig aufblähen. Meiner Meinung wäre so etwas wie der OSM Tasking manager sinnvoller.

Baßtölpel

+1 Genau deshalb hab ich mir gedacht das Thema wieder auf den Tisch zu bringen :slight_smile:

IMHO sollte ein Aktualisierungstag nur gesetzt werden, wenn wirklich ausdrücklich alle tags gecheckt wurden.

Und genau diese Datenleichen werden immer mehr, wenn es weitergeht wie bisher. Die Frage ist also, was kann man tun…
Mein Vorschlag wäre ein Proposal mit einem festen Vorschlag für folgende Punkte:

  • Welches Tag wird benutzt.

  • Welche Typen sollen damit versehen werden (amenity=,shop= whatever)

  • Wann wird das tag gesetzt/aktualisiert

Dann ins Wiki damit mit Hinweis auf Tools die die Bearbeitung unterstützen. Und um mit gutem Beispiel voranzugehen dann vielleicht eine Wochen-/Monatsaufgabe, damit auch endlich was ins Rollen kommt :)

Sollte doch mit der ‘deutschen Gründlichkeit’ möglich sein…

Es geht wohl primär um bestimmte POI, bei denen sich main- oder sub-tags regelmäßig ändern, wie z.B. shops, tourism und amenity. Ob sich dabei - selbst bei verbreiteter Anwendung - die Größe der Datenbank wesentlich erhöht, darf bezweifelt werden. Es wäre aber m.E. ein nicht unwesentliches Merkmal im Sinne der Qualitätssicherung, die umso wichtiger ist, je älter ein Objekt ist.

Ich finde auch, daß wir dringend ein Verfahren brauchen um festzuhalten, daß die Objekte überprüft wurden. Wie gesagt, einen tag auf den Objekten selbst finde ich aber nicht ideal.

Baßtölpel

Nicht so radikal, es kann auch sinnvoll sein, nur die Prüfung einzelner sub-tags zu ermöglichen - z.B. survey:date:opening_hours

survey:date ist bereits im Wiki dokumentiert
http://wiki.openstreetmap.org/wiki/Key:survey:date

und hat laut http://taghistory.raifer.tech/ mit weitem Abstand die größte Verbreitung, also sollten wir es vielleicht einfach verwenden…ohne weitere proposals :wink:

Nunja, es ist ‘aufgelistet’ - dokumentiert wäre irgendwie ausführlicher. Deshalb sind all diese Fragen ja offen und keiner weiss bescheid wie es gemacht werden sollte. Guckt euch mal hier die ganzen Hausnummern an :wink:

Also wenn es so aufgedröselt wird, bekomme ich doch ein paar Bauchschmerzen. Mal davon abgesehen, dass man dann vor lauter Keys überhaupt nicht mehr fertig wird mit der Dokumentation einer Kontrolle, wird das auch extrem unübersichtlich. Wir haben parallel diese Tankstellendiskussion, wo einige schon allein jeden der rund 20 Fuel-Keys taggen wollen (ggf. als “no”). Wenn dafür dann auch noch 20 Survey-Keys hinzukämen, zusätzlich dann noch solche Dinge wie Öffnungszeiten, x Zahlmöglichkeiten, Brand, dann haben wir in Zukunft regelmäßig Einträge mit 50 bis 60 Keys. Das ist irgendwo nicht mehr sinnvoll zu handhaben. Zumal dann auch die Versionshäufigkeit steigt, weil vermutlich jeder nur ein paar Teilaspekte prüft und somit häufiger die Dokumentationszeitstempel aktualisiert werden müssen.

Also dort sollte man doch ein sinnvolles Maß finden und ggf. auch mal Mut zur Lücke haben. Es ist besser wenn jemand vielleicht auch nur 80 Prozent des Umfangs prüft und das trotzdem einheitlich dokumentiert, statt dass ein solches Chaos angerichtet wird, was niemand mehr beherrscht.

Die History wird nicht aufgebläht; sie wird ergänzt. Es wird gezeigt, daß das Obejtk noch aktuell und keine Karteileiche ist. Ein Objekt in dessen History alle 6 Monate ein check_date (oder was auch immer) aktualisiert wird, ist besser, als eines dessen Historie seit 7 Jahren unverändert ist.

Ich denke manchmal sogar, daß es vielleicht sogar gut wäre, wenn veraltete POIs nicht mehr in der Hauptkarte angezeigt oder mit einem Fragezeichen versehen werden.

Christian

Ich finde auch, dass erst ein mal eine Grundbasis funktionieren sollte, bevor am Ende völliges Chaos herrscht. Lediglich die wichtigsten keys zu checken und trotzdem ‘aktuell’ eintragen finde ich ok - aber die reine Existenz oder ein einzelnes tag als aktuell zu deklarieren bringt nicht wirklich eine Verbesserung der Datenqualität.

Zum Thema History sehe ich eigentlich keine Probleme - ist die nicht genau für soetwas da?? :slight_smile: Schließlich sollte ja nicht alle 6 Wochen aktualisiert werden; ausreichend dürften 6 Monate - 2 Jahre sein (je nach Typ des POI)

Ansonsten könnte auch überlegt werden wann man das Objekt als aktuell taggt. Wenn man survey:date zB nur dann hinzufügt wenn die letzte Änderung lange her ist und noch alles identisch ist wird die History nicht allzusehr ‘belastet’. Das survey:date könnte bei einer Änderung des POI wieder gelöscht werden, der Timestamp würde dann genügen (und es gäbe keine Konflikte Timestamp vs survey:date). Allerdings wäre dieser Workflow meines Erachtens wieder zu kompliziert was die Beteiligung hemmt.

Einfacher: survey:date wird bei JEDER Änderung auf das aktuelle Datum gesetzt (ein Auswertungstool sollte beachten, dass das auch mal vergessen wird); wenn der POI identisch ist wird es frühestens nach 6 Monaten neu gesetzt (btw: sollte reichen um immer genug zu tun zu haben :D)

@Kontinentalverschieber, du hast den Konjunktiv überlesen :wink: Es kann sinnvoll sein, nur die Prüfung einzelner sub-tags zu dokumentieren. Ich habe nicht angeregt, das flächendeckend zu machen. Datenkonsumenten sollten damit ohnehin kein Problem haben. Es war primär ein Kommentar zum kategorischen Vorschlag von Sir_Blight, eine Aktualisierung nur zu taggen, wenn “ausdrücklich alle tags gecheckt wurden”. Das wäre zwar prinzipiell wünschenswert, aber in der Praxis unrealistisch und nicht durchsetzbar.

Für den im OP genannten Zweck erscheint mir das Landshuter Tool bestens geeignet. Habt Ihr das schon bei euch ausprobiert? Die Spalten kann man übrigens sortieren…und so mit den “Fossilien” anfangen: http://osm.edvbl.dyndns.org/poi_lastcheck/

edit: link ergänzt