QS für OSM-Daten

Mein Kartenprojekt (Freizeitkarte Deutschland für Garmin) habe ich gestartet, indem ich mir zunächst einen Überblick über die OSM-Ausgangsdaten verschafft habe. In diesem Zusammenhang ist ein Programm entstanden (list_osm_tags.pl), welches alle OSM-Elemente statistisch erfaßt und chronologisch ausweist.

Bei der Arbeit mit den Statistikdaten sind diverse Defekte in den OSM-Ausgangsdaten aufgefallen. So werden beispielsweise die Tags “natural” und “landuse” (inkorrekterweise) häufig “überkreuz” genutzt. Andere Tags beinhalten Schreibfehler (z.B. “forrest” statt “forest”) oder existieren offiziell gar nicht (z.B. “landuse=education”). In vielen Fällen dürfte der Renderer diese Daten ignorieren, d.h. die Elemente fehlen dann in den gerenderten Karten.

Die Idee wäre es nun, gemeinschaftlich im Rahmen einer Qualitätssicherungsmaßnahme (QS), Defekte in den Ausgangsdaten zu ermitteln und zu korrieren. Hierzu könnte man beispielsweise Deutschland in 100 kleine Gebiete aufteilen und für jedes dieser Teilgebiete eine entsprechende QS-Maßnahme durchführen.

Das oben erwähnte Programm arbeitet auf den originalen OSM-XML-Daten. Weitere Details zum Programm finden sich hier:
http://www.easyclasspage.de/maptools/index.html

Frage: Was haltet ihr von der Idee und dem Vorgehensmodell?

Hallo

DOWNLOAD:===> Not Found

MfG
Achim

Es gibt schon diverse tools zur QS: http://wiki.openstreetmap.org/wiki/Quality_Assurance. Leider werden sie nur von wenigen benutzt.

Einen check für überscheidende Flächen gibt es dabei m.W. noch nicht.

Baßtölpel

Bis auf die Schreibfehler sind das nicht unbedingt Defekte. Denn da es bei OSM keine klare Definition fuer irgendetwas gibt, ist auch nur selten etwas wirklich falsch:

  • Ueberlagerungen von landuse und natural koennen durchaus Sinn machen. Z.B. kann eine Wasserflaeche Bestandteil eines Wohngebietes sein, dann hat man ein natural=water ueberlagernd mit landuse=residential.
  • Nicht “offiziell” existierende Werte gibt es aus Prinzip nicht, OSM ist ja gerade so aufgebaut, dass fehlende Werte von Mappern erfunden werden sollen. Nur weil DEINE Karte z.B. kein landuse=education kennt, heisst das ja noch lange nicht, dass ANDERE Karten solche Objekte nicht ordentlich darstellen.

Wenn du damit andere Mapper zur Mithilfe bewegen kannst, nur zu. Etwas mehr Qualitaet kann den OSM-Daten bestimmt nicht schaden.

Aufgrund der unpraezisen Definitionen bei OSM muss man bei Aufraeumarbeiten aber immer etwas zurueckhalten agieren, sonst handelt man sich schnell Aerger mit andere Mappern ein, die eine anderes Mappingmodell bevorzugen.

Gruss
Torsten

Moin,

Überlagerungen im Sinne von Teil eines Wohngebietes, d.h. die Wohngebietsfläche liegt drumherum, ja.
Aber das die Wasserfläche alleine eine Wohngebietsfläche ist, macht doch nur Sinn, wenn der B-Plan Hausboote vorsieht - und nur dann hat man beide Tags am gleichen Objekt.

Gruß
Georg

Ein Beispiel für Überschneidungen:
Im Wald gibt es eine sumpfige Fläche, in der aber auch dichte Bäume stehen. Luftbild und Hans-guck-in-die-Luft melden ganz klar “Wald”, Füße melden “nass hier”. Und nu ?? :roll_eyes:

Ich fürchte mit “Überkreuznutzung” bin ich falsch verstanden worden. Gemeint hatte ich folgendes: Werte (z.B. “meadow”) "die für “landuse” vorgesehen sind, werden anstatt dessen mit “natural” verwendet und umgekehrt.

Wohngebiet /= Wohnzimmer

Zu einem Wohngebiet gehoeren z.B. auch Gaerten und kleinere Gruenanlagen mit dazu, und da koennen durchaus Wasserflaechen vorkommen.

Gruss
Torsten

Da hängt das Problem schon an landuse vs. natural.
Das erste impliziert eine aktive Nutzung durch Menschen, das zweite etwas ohne den Menschen Entstandenes.
Das lässt sich nicht immer so einfach einteilen.
Da ist eine Wiese “meadow” schon einfacher zu erkennen.

Ah, ok. Das ist fuer mich dann allerdings auch ein Fehler, genau wie die Tippfehler.

Gruss
Torsten

Ich hatte mal mit Jochen der die Statistik auf taginfo.osm.org entwickelt hat gesprochen und er erzählte mir auch von etlichen Fehlern.
Beide vertraten wir allerdings die Ansicht, dass eine maschinelle Lösung nicht gut wäre, da sie die lokalen Mapper ungerechterweise “bevormundet”. Wie ihr schon sagtet, kann ein vermeintlich falsche Klassifikation durchaus beabsichtigt worden sein und wir sind da ja eh “offen”.

Deshalb sollten wir das Problem vielleicht kleiner angehen und uns zunächst mal auf offensichtliche Rechtschreibfehler in der Klassifikation beschränken?
Da könnte man ja ein Projekt des Monats, oder eine “Woche der Verbesserung” (lasst uns probieren diese Woche keine neuen Daten aufzunehmen, sondern nur bestehende Daten zu verbessern) draus machen?

Ich denke bei den Rechtschreibfehlern im Schlüssel ist das relativ klar und bei den Werten sollte man natürlich die Schlüssel name, description,… rauslassen.

Traut sich jemand zu da Todo Listen oder eine Karte zu generieren? Wer hätte vielleicht Lust so eine Wikiseite anzulegen (ich helf gerne auch)?

Fuer offensichtliche Rechtschreibfehler gibt es xybot ( http://wiki.openstreetmap.org/wiki/Xybot ), der automatisch diese offensichtlichen Fehler korrigiert.

Falls manche Rechtschreibfehler wie z.B. “forrest” statt “forest” noch nicht erkannt werden, sollte man diese zu xybot’s Regeln hinzufuegen.

xybot findet anscheinend nicht alles:

place=isolated_dwelling (5921)
place=isolated_dewlling (147)
place=isolate_dwelling (39)
place=isolted_dwelling (17)
place=isoled_dwelling (4)
place=single_dwelling (4)

:wink:

http://taginfo.openstreetmap.org:8000/keys/place#values

Edit: Korrigiert

Xybot sieht m.E. vielversprechend aus - hätte insbesondere auch den Vorteil, daß auch zukünftige Tip- und Rechtschreibefehler des gleichen Schemas korrigiert werden. D.h. man müßte eine gesammelte Liste mit Fehler erarbeiten / erstellen und in die Xybot-Konfiguration einbringen.

Ach der macht das also, interessant. Habe dessen Entwickler mal auf den Thread aufmerksam gemacht.

Xybot ist schon sehr hilfreich, allerdings müsste man die Regeln sicher um einige hunderte Fälle erweitern. Und nicht für jeden einzelnen Schreibfehler lohnt das, wenn er nur einmal auftritt, ist er von Hand schneller korrigiert. Daher sind seiten wie taginfo schon wichtig. Wenn nur die XAPI angemessen und schnell reagieren würde, dann könnte man damit sogar wieder arbeiten. Seufz.

Da soll das hier ziemlich gut sein: http://wiki.openstreetmap.org/wiki/Overpass_API

Aber das bitte in nem speraten Thread ausbreiten :wink:

Gute Idee, fang schon mal an.
Zum Thema QS noch: ISO 9001 und vor allem ISO 19113. Bevor hier einfach drauflos korrigiert wird sollten Ziele und Prozesse definiert werden.

Ziel: Optimierung der xybot Regeln, so dass mehr offensichtliche Rechtschreibfehlern bei gängigen Key7Value kombinationen erfasst werden

Prozess:

  1. Identifizierung von offensichtlichen Fehlern mittels toc-rox Analysen, taginfo, …
  2. Auflistung dieser auf der xybot Wikiseite oder seperater Seite
    3, Kontaktierung Autor des xybots und einarbeitung des neuen Regelwerks

Das ist zumindest ein Anfang, auch wenn ich meine das ISOs nicht gut auf Community weil von oben herab, funktionieren. Ich denke wie immer bestimmt der, der anfängt. Na wer übernimmt das? :slight_smile:

Es gibt bereits ein PHP-Programm, das entweder *.osc oder *.osm (auch direkt komprimierte) Dateien lesen kann und auch auf Fehler in der Zahlenschreibweise hinweist (englisches statt deutsches Zahlenformat). Zu finden ist es unter http://familieverweyen.de/txt_0053.php.