POI aktuell halten

Hallo an Alle!

bezugnehmend auf diese Diskusion, wollte ich euch mal fragen wie ihr es handhabt, POI aktuell zu halten.

Die Notwendigkeit ist ja allemal vorhanden - meineserachtens mindestens genauso wie Neue einzutragen. Ich weiss, dass es bisher noch keinen wirklichen Konsens über das WIE gibt. Ich finde ein bisschen schade, dass scheinbar jeder sein (komplett) eigenes Süppchen kocht. Damit ist der Datenqualität nicht unbedingt geholfen.

Als Anregung wie man vorgehen könnte ist das Landshut-Projekt sehr interessant - allerdings scheint daraus (noch?) kein Dienst für die Allgemeinheit entstanden zu sein. Kennt jemand einen Service mit dem sich der Stand von POI einfach und systematisch abfragen lässt? So in etwa könnte ich mir das vorstellen: POI_aktuell_halten_Beispiel.jpg

Zusammenfassend: Findet ihr das Thema wichtig? Was macht ihr um POI aktuell zu halten und wie? Gibt es Tools zur Arbeitserleichterung oder besteht ein allgemeines Interesse daran?

Ich bin mal auf euren Workflow und Anregungen dazu gespannt.

LG - Kevin

Meine Handhabung: Einfach immer die Augen offenhalten und bei Veränderungen ein Photo machen.
Die Wenigsten überprüfen POIs wohl systematisch. Selbst in Landshut werden noch nicht einmal gemeldete Fehler zeitnah korrigiert: http://www.openstreetmap.org/#map=14/48.5431/12.1497&layers=N

Das Vermeiden von zu vielen Einträgen (unwichtiger und/oder häufig wechselnder Dinge) ist auch hilfreich - auch wenn das hier nicht jeder hören mag. Meine persönliche Erfahrung: Die meisten wollen hauptsächlich erfassen. Pflegen wollen wesentlich weniger.

Systematisch kann sich nichts abfragen lassen, weil es keine Systematik gibt. Mal davon abgesehen, dass nur die wenigsten POI überhaupt irgendeine Art von derartigem Datum tragen, ist man sich auch bezüglich des zu verwendenden Keys nicht einig. Wobei ich mal behaupten würde, dass die Übersicht unter Key:check_date inzwischen eine Präferenz in Richtung Key:survey:date erkennen lässt.

Wenn man sich dort einmal geeinigt hätte, könnte es irgendwann vielleicht auch eine App-Unterstützung geben, die mir POI in der Nähe meines Standortes oder entlang einer vorgeplanten Route sowie zu überprüfende Werte anzeigt (Ist dieser Laden noch die Bäckerei xyz? Hat er noch die Öffnungszeiten von … bis …? Häkchen dran, fertig, nächster.). Wobei man dort auch noch definieren müsste, in welchem Abstand eine solche Überprüfung überhaupt gewünscht ist. Denn es hat wenig Wert, wenn an vielbegangenen Strecken alle drei Tage nur sinnlos die Versionsnummer in der Datenbank hochgezählt wird, weil eine weitere Person dokumentieren möchte, dass sie dort war. Das würde nur für eine sehr unübersichtliche Versionsgeschichte sorgen, wenn man recherchieren muss, wie Fehler in die Datenbank gekommen sind oder man die Version ermitteln muss, die man zum Zurücksetzen braucht.

@Lübeck:

Ich glaube den gibt’s nicht mehr in Timmendorf (Habe in dem Chinesen gegenüber gespeist und mir ist dort kein anderer aufgefallen):

https://www.openstreetmap.org/node/1228949451

:wink:

EDIT: OSM Note erstellt.

@chris66:

Ein Schuhgeschäft, welches keine Schuhe verkauft. Soso… :wink:

Das sehe ich genauso. In einigen Gebieten ist es schon fast Glücksspiel ob die nächste Einkaufsmöglichkeit auch noch da ist… Wie das wohl in 5 oder 10 Jahren ist? Sicher hilft es die Augen offenzuhalten, doch Gefahr und Realität ist halt, dass ggf alle 3 Tage von verschiedenen Mappern festgestellt wird, dass das Restaurant an der Hauptstraße immer noch da ist, aber das die Kneipe in der kleinen Gasse nebendran schon seit 6 Monaten weg ist merkt womöglich keiner… Vielleicht ist es ja möglich etwas anzustossen. :slight_smile:

Vielleicht braucht es ja ein gut genutztes Tool um eine Einigung zu bekommen :slight_smile:
Der zeitliche Abstand einer Überprüfung ist natürlich eine enorm wichtige Sache - ein pub hat eine kürzere Zeitspanne als eine parking-area oder gar eine bench. Wo wir auch gleich bei der Auswahl wären, jede einzelne Bank finde ich nicht soooo wichtig.

Ich habe den Ehrgeiz ‘meine’ Gegend ein wenig zu überprüfen, hier hat sich in letzter Zeit viel geändert. Dazu möchte ich mir ein kleines Tool basteln. Wenn viele sagen, sie würden soetwas auch nutzen überlege ich mir das Ganze größer und professioneller anzulegen.

Der verkauft sogenannte Barfuß-Schuhe.

http://www.leguano.eu/

Und da steht wirklich „leguano (Barfußladen)“ dran? Ansonsten ist der Klammerzusatz ein Fall für description:de=*. Ich kann mir ohne weitere Erklärung nichts unter einem Barfußladen vorstellen.

Verkauft der nur diese Schuhe, oder auch normale?

–ks

Sorry, hab das Foto bereits gelöscht. Zitat von der Webseite:

Es werden nur Schuhe dieser Marke dort verkauft. Ob man die als “normal” bezeichnen kann weiß ich auch nicht. :wink:

Hi alle,

seit meinem Umzug (ausserhalb von D) widme ich mich auch dem aktualisieren von POI.
Ich habe mir eine Overpass Abfrage [1] gebastelt, die mir die Objekte ausgibt, die meiner Meinung nach eine kurze Halbwertszeit haben. Ich filtere dann nach dem Timestamp aus was mir noch zu frisch erscheint. Ich arbeite mich derzeit von hinten heran, daher schmeisst die Anfrage momentan alles weg, was neuer ist als 11/2012, so bleiben mir die ca. 100 ältesten POI übrig.
Mein Ziel ist, mich bis an ein Jahr alte POI heran zu arbeiten. Bei diesen ganz alten Objekten bleibt eigentlich immer irgendwas zu verbessern/ändern/erweitern/löschen. Nur wenn ich bestätigen kann, dass wirklich alles noch so ist, setze ich check_date (laut taginfo das verbreitetste “check”-tag).
Für den menschlichen Leser soll es ein Hinweis sein, für meine Auswertung dient es vor allem dazu dem Objekt ein neues Timestamp zu generieren. Dinge, die ich ändere, erhalten ja sowieso ein neues Datum. Dass bei dieser Methode Objekte durchrutschen, die jemand z.B. verschiebt, obwohl sie veraltet sind - geschenkt.

Grüße, Marc

[1] overpass-turbo.eu/s/i43
ich, weiss in Zeile 16 ist ein Typo :slight_smile:

Also ich würde einmal behaupten, dass survey:date deutlich mehr Verbreitung als check_date hat.

guter Punkt, erscheint aber nicht, wenn ich in Taginfo nach “check” suche :wink: Andererseits habe ich ja nicht gesurveyt, sondern gecheckt. Wie schon festgestellt wurde, gibt es keine Einigkeit, was solche Tags angeht, daher wollte ich in erster Linie sicherstellen, dass ich nicht das exostischste Verwende. Evtl. werde ich zu survey:date umschwenken.

Gruß, Marc

Hi zorque!

Die Anregung die Timestamps mit einzubeziehen finde ich echt gut - auf die Idee ist mein Schmalhirn noch garnicht gekommen…
Wie gehst du nach der Abfrage weiter vor? Druckst du dir eine Handvoll einfach als Datenliste aus und ziehst los oder machst du dir eine gpx fürs Navi (etliche POI haben ja keine Adresse) oder etwas anderes?

@Kontinentalverschieber:
Bitte nicht falsch verstehen, aber ob survey:date, check_date, lastcheck oder was auch immer verwendet wird finde ich derzeit bestenfalls zweitrangig. WENN genügend Mapper systematisch an der Aktualität arbeiten gibts irgendwann auch eine klare Tendenz.

LG

Ganz im Gegenteil: Solche Unbestimmtheit lähmt alles. Weil es nämlich keine klare Vorgabe gibt, weiß auch niemand, was er machen soll. Also lässt er es weg. Wenn man will, dass etwas benutzt wird, muss man klar sagen, was erwartet wird. Da sind solche Wiki-Seiten, deren Inhalt es ist, dass die einen es so und die anderen es so machen, aber es auch noch ganz viele andere Möglichkeiten gibt und eigentlich auch noch gar nichts wirklich festgelegt ist, völlig kontraproduktiv. Vielfalt ist nicht der Sinn einer Geodatenbank.

Um das also nicht unnötig weiter zu zerfasern, kann man ruhig klar sagen, dass vor Ort überprüfte Elemente mit survey:date=YYYY-MM-DD zu versehen sind. Mit solch einer klaren Ansage wird man Leute auch viel schneller dazu bekommen, in der Richtung aktiv zu werden, statt dass man dort immer nur im Ungefähren operiert.

Hello Sir,

da meine Programmierkünste sehr beschränkt sind, und ich persönlich meine Zeit lieber auf der Straße verbringe, als daheim zu grübeln, was ich wie machen könnte, gehe ich den pragmatischen Weg. Ich schicke mir die Abfrage aufs Handy* und gehe los. Overpass zeigt zwar alle Attribute an, allerdings mache ich eine Vollerfassung, sprich mache dann Fotos von allem was mir zu einem POI wichtig ist. In seltenen Fällen muss ich noch ein zweites Mal hin um genauer nachzuschauen oder Unklarheiten zu beseitigen, aber ist ja alles im Umfeld.
Die Touren selber mache ich spontan. Mal nach Notes, die ich zusätzlich erledigen möchte, mal nach Häufung von alten POI, mal um abgelegne und hügelige Gebiete erstmal auf die lange Bank zu schieben.

Jede Form von survey oder check date finde ich redundant solange es sowieso eine neue Version der Elemente gibt. In den allermeisten Fällen dürfte die Differenz zum Timestamp sehr gering sein (und wenn sie groß ist, ist die Frage ob es nicht schonwieder veraltet sein könnte). Zweitens: keep it simple. Drittens: das kann man auch im Changeset unterbringen. Meine Meinung :slight_smile:

*ist das eigentlich richtig, dass man Overpass-Abfragen auf Android (mehrere Geräte, Firefox und Chrome) nicht ändern kann?

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.