OSM Daten überprüfen

Gereviewed 2017-04-24

• OSM Daten überprüfen
  • Tägliche Überprüfungen
    • Datenvalidierung
    • Die JOSM Suche verwenden
  • Nochmals prüfen
    • Fehler korrigieren
    • Genauigkeit auswerten
  • SQL Abfragen
    • Daten vorbereiten
    • SQL Abfragen
  • Zusammenfassung

Dieser Abschnitt beschäftigt sich mit Prozessen zum Überprüfen der Datenqualität, speziell im Kontext von Mapping Projekten direkt in OSM, wie jene des Humanitarian OpenStreetMap Team in zahlreichen Ländern und Open Cities Projekten in Bangladesh, Sri Lanka, and Nepal. Die gezeigten Methoden können auch im anderen Kontext nützlich sein, wenn Datenqualität Review eine Rolle spielt.

Wenn man in einem bestimmten Bereich einer Karte versucht alle Kartenelemente und Attribute zu mappen, sollte man auf Fehler prüfen und die Genauigkeit der Arbeit überprüfen. In diesem Tutorial werden wir einige Methoden der Datenprüfung durcharbeiten, die einzelnen Schritte und die Gründe dahinter erklären. Ein gut organisiertes Mapping Projekt sollte alle diese Prozesse beinhalten zur Evaluierung, Korrektur und zum Berichten.

• Tägliche Überprüfungen
• Erneut Sichten
• SQL Abfragen

Da das Datenmodell und die Anzahl der Kartenelemente wächst, werden Reviewmethoden immer wichtiger. Es würde z.B. nicht lange dauern und wenig Aufwand bedeuten ein Datenmodell mit nur interessanten Punkten (POIs) zu bewerten:

In diesem Fall wäre die folgende Frage zu stellen:

• Wurden alle POIs in allen Standorten gemappt?
• Haben alle POIs ein Name Attribut?
• Haben alle POIs ein Typ Attribut?
• Haben alle POIs ein Telefonnummer Attribut? Ist der Wert im Namenfeld richtig geschrieben (Groß-/Kleinschreibung)?
• Macht die Telefonnummer Sinn?

Normalerweise ist das Datenmodell viel komplexer, z.B. bei Gebäuden. Betrachte folgendes Datenmodell:

Stell dir vor du editierst tausende Gebäude mit vielen Attributen und die Analyse wird kritischer. In diesem Tutorial verwenden wir Gebäude als Beispiel, die selben Methoden können aber auch auf anderen Kartenelemente angewandt werden.

Tägliche Überprüfungen

Der beste Weg Daten zu prüfen und zu validieren ist auf einer regulären Basis. Dies kann täglich oder wöchentlich geschehen. Für einen Prüfer eines Mapperteams ist es eine wichtige Aufgabe, da das frühe Finden von Fehlern und schlechtem Editieren eine frühe Korrektur bedeutet und Mapper lernen sauber zu arbeiten.

Wir werden einige Methoden zur Datenprüfung mit JOSM anschauen, Einige Fragen die wir uns über unsere Daten stellen sind:

• Gibt es topologische Fehler (wie überlappende Gebäude oder inkorrekte Relationen)?
• Gibt es Fehler in den Tags (falsch geschrieben Tags, falsch verwendete Schlüssel-Werte Paare)?
• Sind die Daten komplett entsprechend des Datenmodells?

Lasst uns untersuchen wie wir in JOSM antworten auf diese Fragen finden. Wir nehmen an, dass wir die arbeit anderen untersuchen, aber der gleiche Prozess gilt auch für unsere eigene Arbeit (und sollte uns leichter fallen).

Wir verwenden eine Beispieldatendatei des Open Cities Mapping Projekts in Dhaka. Zum nachvollziehen, kann man es herunterladen: dhaka_validation_example.osm

Bitte keine Änderungen zu OpenStreetMap hochladen. Diese Übungen sind nur zur Demonstrationszwecken gedacht.

Datenvalidierung

Der erste Schritt um Daten zu prüfen ist das Validierungswerkzeug in JOSM aufzurufen, welches automatisch die geöffneten Daten auf mögliche Fehler prüft. Dieses Werkzeug ist besonders nützlich um topologische Fehler zu finden, aber nicht ganz so nützlich um inkorrekte Tags zu finden.

• Man aktiviert das Validierungswerkzeug indem man auf den Button auf der linken Seite von JOSM klickt. (Es ist unnötig, wenn das Fenster bereits geöffnet ist)

Man stellt sicher, dass nichts markiert ist, indem man auf einen freien Punkt in der Karte klickt. Falls man Kartenelemente selektiert hat, werden nur die markierten geprüft, wenn das Validierungswerkzeug läuft. (Manchmal möchte man nur bestimmte Kartenelemente prüfen, aber gerade möchten wir die ganze Datei prüfen)

• Klicke den “Validierung” Button auf der Leiste.

• Eine Liste mit Warnungen erscheint:

• Ein neuer Layer erscheint, er zeigt wo sich die Fehler befinden. Man kann den Layer praktischerweise vorerst verstecken.

Lasst uns einige Warnungen anschauen. Man sieht die “Überschneidende Gebäude” Warnungen. Diese Warnungen bedeuten, dass sich Gebäude irgendwo überschneiden. Wähle das erste Objekt in der Liste, mache einen Rechtsklick und klicke “Auf Problem zoomen”.

Klicke außerdem den “Auswählen” Button am unteren Ende des Validierungsfensters, um die fraglichen Wege auszuwählen. Das zeigt, dass diese beiden Wege ein Problem haben:

• Diesen Fehler hätten wir nie ohne das Validierungswerkzeug gefunden. Wenn man weit hinein zoomt, sieht man eine winzige Überlappung der Gebäude, was einen topologischen Fehler darstellt, da sich Gebäude normalerweise nicht überlappen. Um dies zu korrigieren, muss die mittlere Node bewegt werden. Falls sich die Gebäude tatsächlich berühren, was sie wahrscheinlich tun, kann die mittlere Node mit dem Weg verbunden werden.
• Wenn wir das korrigiert haben, können wir das Validierungswerkzeug erneut ausführen und die Warnung wird von der Liste verschwinden.

Diese automatische Datenprüfung ist eine effektive Art topologische Fehler zu korrigieren, insbesondere solche, die durch einen Menschen schwer zu finden sind. In der Liste der Validierungswarnungen sieht man, dass andere Warnungen wie “Gebäude in einem Gebäude” das Ergebnis ähnlicher Fehler sind.

Andere Warnungen wie “Kreuzende Wasserwege/Straßen” sind nicht notwendigerweise Fehler. Das zeigt, dass das Validierungswerkzeug mögliche Fehler findet, aber es wird jemand benötigt, der die Fehler auf wichtig oder unwichtig prüft.

Schauen wird die Warnungen unter “Ähnlich benannte Wege” an um nicht topologische Fehler zu sehen. Klicke “Auswählen” um die fraglichen Wege zu selektieren.

Siehst du den Fehler? Wir haben hier zwei unterschiedliche Straßensegmente der gleichen Straße mit leicht unterschiedlichen namen - “road” besitzt unterschiedliche Groß-/Kleinschreibung. Sie sollten den gleichen Namen haben und in diesem Fall sollte “road” groß geschrieben werden.

Die JOSM Suche verwenden

In JOSM zu suchen ist eine mächtige Funktion um Daten zu reviewen. Man kann Suchbegriffe und Abfragen verwenden, um nur gewünschte Daten zu selektieren.

• Für die Suche geht man zu Bearbeiten -> Suchen oder drückt STRG + F auf der Tastatur.

Man kann auf sehr viele unterschiedliche Arten hier suchen und Details und Beispiele in der Suchbox ansehen oder auf den “Hilfe” Button klicken.

• Lasst uns nun alle Gebäude auswählen. Fast jedes Gebäude hat das Tag building=yes und einige building=construction. Dies bedeutet wir können folgende Abfrage bauen:

  building = yes OR building=construction

Dies selektiert alle Gebäude, aber für den Fall, dass jemand einen anderen Wert verwendet, können wir Wildcards verwenden, so dass alle Kartenelemente mit dem Key Gebäude selektiert werden.

• Alle Gebäude werden selektiert.

Das ist wunderbar, aber wie hilft es uns beim Datenreview? Nun, dadurch dass wir alle gleichen Typen eines Kartenelements ausgewählt haben, können wir nach falschen Tags suchen.

• Wenn man ins Eigenschaftenfenster sieht, sehen wir alle Tags eines jeden ausgewählten Objekts. Sie verwenden alle die gleichen Keys, aber da jedes Kartenelement andere Werte hat, werden diese als <unterschiedlich> gekennzeichnet.

• Klicke auf das building:use Tag und dann “Bearbeiten”.

• VORSICHT! Ändert man hier den Wert und klickt OK, ändert man diesen Tag für alle markierten Kartenelemente. Das wäre sehr schlecht.
• Man klickt stattdessen auf die Auswahlbox neben dem Wert.

• Man beachte, alle fett geschriebenen Elemente haben eine Nummer in eckigen Klammern daneben. Dies ist die Anzahl der ausgewählten Kartenelemente, welche diesen Tagwert besitzen.

Man kann dies mit dem OpenStreetMaps Tags des Datenmodells vergleichen und nach Fehler suchen. Dieser Tag repräsentiert z.B. die Nutzung des Gebäudes. Im frühen Stadium des Open Cities Dhaka Projekts (woher diese Daten stammen) war man sich unsicher, wie eine gemischte Nutzung getaggt werden soll building:use=multipurpose oder building:use=mixed. Da der erste Tag in anderen Ländern bereits verwendet wurde, wurde dieser verwendet. Wie wir hier sehen wurde ein Gebäude als mixed getaggt. Wir korrigieren das. (Ein anderer offensichtlicher Fehler ist die unterschiedliche Nutzung der drei garage Begriffe, aber wir werden das hier nicht korrigieren.)

Wir können gerade das Kartenelement mit dem Tag building:use=mixed nicht ändern, weil wir hunderte von Kartenelemente ausgewählt haben. Um es zu korrigieren, müssen wir es erst finden. Wie? Erraten - mit dem Suchwerkzeug.

• Klicke “Abbrechen” um den Dialog zu beenden. Man erinnert sich, OK zu klicken kann gefährlich sein.
• Man öffnet die Suche erneut und gibt folgendes ein: “building:use”=mixed
• Man beachte, dass die Anführungszeichen notwendig sind, weil ein Doppelzeichen (:) auch eine andere Bedeutung hat. Das sollte das eine Gebäude mit diesem Tag auswählen. Es kann nun korrigiert werden zu multipurpose.

Beachte, wenn man dem Tutorial folgt, NIEMALS die Änderungen auf OpenStreetMap speichern. Die Übungen sind nur für Vorführungszwecke.

Nochmals prüfen

Wenn man ein Projekt wie eine detaillierte Gebäudeerfassung verwaltet, sollte eine zusätzliche Methode zur Qualitätssicherung, zur Verbesserung und Erfassung der Genauigkeit am Ende des Projekts, vorhanden sein.

Wenn mehrere Mapping Teams an einem Gebiet arbeiten kann es vorkommen, dass ein oder mehrere Teams eine nicht zufriedenstellende Arbeit abliefern. Aber selbst effiziente und genau arbeitende Teams machen Fehler. Man stellt sich vor, dass jedes Team 100 Gebäude am Tag erfasst - da ist es nicht unwahrscheinlich, dass ein kleiner Prozentsatz der gesammelten Attribute falsch ist.

Deshalb beinhaltet ein gutes Projekt Prozesse zur Überprüfung der getanen Arbeit, Fehlerbehebung, Bestimmung der zufriedenstellenden Mapping Teams und zur Ermittlung der wahrscheinlichen Fehlerrate für einen finalen Bericht.

Natürlich macht es keinen Sinn alle Gebäude in einem Zielgebiet zu überprüfen, aber 5-10% der Gebäude sollten geprüft werden. Die zu überprüfenden Gebiete sollten an unterschiedlichen Orten ausgewählt werden, um verschiedene Teams zu vergleichen. Teams können sich gegenseitig überprüfen oder erfahrene Manager können diese Überprüfungen durchführen. Es ist völlig normal, dass Manager einen Tag in der Woche benötigen, um das Zielgebiet zu überprüfen.

Fehler korrigieren

Was sollte passieren, wenn Fehler gefunden werden?

Wenn wenige Fehler (weniger als 5%) vorhanden sind, sollte dies dem originalen Mapping Team mitgeteilt werden, damit es sich diesen bewusst wird und dieselben Fehler nicht erneut macht. Die Daten sollten in OpenStreetMap korrigiert werden und das Ergebnis der Überprüfung dokumentiert werden.

Wenn viele Fehler auftauchen, sind größere Aktionen notwendig. Das Team muss in angemessener Weise darauf hingewiesen werden und die Bereiche, die von diesem Team erfasst wurden, sollten komplett überprüft werden, abhängig davon, wie ungenau die Daten zu sein scheinen. Mehr als 10% Ungenauigkeit ist aller Wahrscheinlichkeit nach eine nicht akzeptable Rate.

Genauigkeit auswerten

Das zweite Ziel der Überprüfung ist ein Aussagefähigkeit über die Genauigkeit der Daten am Ende des Projekts. Benutzer der Daten möchten die genutzten Metriken und Methoden zu Erfassung der Datenqualität erfahren.

Durch einbauen eines solchen Prozesses als Teil der Überprüfungsmethodik kann man erklären, wie man die Datenqualität geprüft hat und harte Zahlen vorlegen, die den möglichen Anteil an Fehlern in den erfassten Daten aufzeigen.

Nehmen wir an, dass wir z.B. ein Projekt zur Erfassung von 1000 Gebäuden verwalten. Wir können 10% oder 100 Gebäude davon zufällig im Zielgebiet mappen. Wir finden heraus, dass sechs der 100 überprüften Gebäude in hohem Maße ungenau erfasst wurden. Wir definieren nun als ungenau, wenn mehr als ein Attribut nicht korrekt ist. Sechs Prozent der Überprüfung sind also ungenau - wir können diese Fehler beheben, aber wir müssen immer noch annehmen, dass sechs Prozent aller 1000 Gebäude ungenau sind. Das sollte am Ende des Projekts als mögliche Fehlerrate berichtet werden.

Eine Überprüfung sollte während der ganzen Projektlaufzeit erfolgen. Man stellt sich vor, man wartet bis zum Ende unseres Beispiels und 40 von 100 Gebäuden wurden falsch erfasst. Es kann das ganze Projekt zum Scheitern bringen. Großflächige Fehler sollten deshalb früh gefunden und behoben werden.

SQL Abfragen

Das möglicherweise beste Analysewerkzeug sind SQL Abfragen in einem GIS System wie Quantum GIS. Es ist ähnlich der Suche nach Daten in JOSM, aber bietet mächtigere Analysen auch wenn es etwas mehr Zeit in Anspruch nehmen kann. JOSM zu verwenden ist ein schneller, gebräuchlicher Weg um nach Standardfehler zu suchen, während Abfragen in QGIS sich besser eignen um fehlende Daten oder nicht korrekte Attribute zu finden.

Wir nehmen hier an, dass man mit GIS umgehen kann und konzentrieren uns darauf Abfragen zu erstellen, welche beim Überprüfen von OpenStreetMap Daten helfen. Für die folgenden Übungen verwenden wir wieder Daten des Open Cities Dhaka Projekts, welche heruntergeladen werden können von dhaka_sql.zip. Die OpenStreetMap Daten wurden mit dem HOT Export Tool (export.hotosm.org) exportiert und die Zielgebietsgrenzen zu Beginn des Projektes definiert.

Daten vorbereiten

Man entpackt die Dateien und lädt beide Shapefiles in QGIS. Wir beginnen damit innerhalb des Projektbereichs nur die Gebäude auszuschneiden, damit unsere Abfragen später einfacher werden.

• Als erstes selektieren wir nur die Polygone innerhalb des Zielbereichs. Wir verwenden dafür das Spatial Query Plugin. Falls man es noch nicht installiert hat, geht man zu Plugins -> Verwalten und Installieren von Plugins um es dort zu suchen und zu installieren.
• Man geht zu Vector -> Spatial Query -> Spatial Query.
• Man gibt Eigenschaften an, um Kartenelemente zu selektieren von planet_osm_polygon, welche innerhalb des Zielbereichs sind.

• Klicke Anwenden. Nur Polygone innerhalb des Zielbereichs sind selektiert.

• Man macht einen Rechtsklick auf den Layer und speichert die Auswahl als neues Shapefile. Man fügt es zum Projekt hinzu.

• Als nächstes filtert man nur die Polygone, welche Gebäude darstellen und als Teil dieses Projektes gesammelt wurden.
• Man macht einen Rechtsklick auf planet_osm_polygon und klickt auf “Filter …”
• Man gibt folgende Abfrage ein:

“building” != NULL AND “source” = ‘Open Cities Dhaka Survey’

• man klickt OK. Filtert man mit dieser Abfrage, so bekommt man nur Polygone mit einer Angabe in der Gebäude Spalte. Es entfernt auch Gebäude, welche nicht das source-Tag dieses Projektes haben.
• Man speichert diese Daten als neues Shapefile. Wir verwenden diese Datei für unsere SQL Abfragen.

SQL Abfragen

Wir können nun Abfragen auf dem Gebäude Layer ausführen, um mögliche Fehler zu finden. Denken wir über mögliche Dinge nach, die wir abfragen möchten. Das Datenmodell dieses Projektes kennzeichnet Attribute, die für jedes Gebäude gesammelt werden sollen - dies sind:

• name
• building
• building:levels
• building:use
• building:vertical_irregularity
• building:soft_storey
• building:material
• building:structure
• start_date
• building:condition

Man beachte, dass diese Attribute im Shapefile geleert sind, da Spaltennamen auf 10 Zeichen begrenzt sind.

Was für Fragen wollen wir also stellen? Was sind mögliche Fehler? Ein häufig vorkommender Fehler ist es ein Gebäude zu mappen, aber nicht alle Attribute zu erfassen. Wir wollen also eine Abfrage stellen, die uns alle Gebäude ausgibt, die nicht ein komplettes Set an Attributen haben. Natürlich ist es für einige Attribute wie name und start_date (Baujahr) auch in Ordnung wenn sie leer sind, da nicht jedes Gebäude einen Namen hat und manchmal das Baujahr unbekannt ist. Aber die anderen Attribute sollten immer angegeben werden.

Versuchen wir dafür eine Abfrage zu entwickeln:

• Man macht einen Rechtsklick auf den Gebäude Layer (den wir im vorherigen Abschnitt erstellt haben) und klickt auf “Filter…”. Das öffnet den Query Builder. Damit kann man komplexe Abfragen erstellen, welche nur die Daten zurückgibt, die wir wollen.
• Man kann seine eigene Abfrage durch doppelklicken auf Felder, Operatoren und Werte erstellen oder die hier gebaute Abfrage kopieren:

“building_c” = NULL OR “building_s” = NULL OR “building_l” = NULL OR “building_m” = NULL OR “vertical_i” = NULL OR “soft_store” = NULL OR “building_u” = NULL

• Wenn man “Test” klickt werden 125 Kartenelemente zurück geliefert. Das bedeutet, dass von den etwa 3500 gemappten Gebäuden, 125 ein oder mehrere Attribute fehlen.

• Klickt man OK, bekommt man die Gebäude die den Kriterien der Abfrage entsprechen angezeigt.

• Diese Gebäude könnten genauer betrachtet werden, um festzustellen welche Attribute fehlen und ob sie neu gesammelt werden müssen. Es ist dann mit QGIS möglich eine Karte für ein Vor-Ort-Team zu erstellen, um die fehlenden Gebäudeattribute zu korrigieren.

Gibt es andere nützliche Abfragen? Vielleicht prüft man auch auf Attribute, welche nicht in unserem Datenschema enthalten sind. Wir haben das im JOSM Suche Abschnitt gemacht. Man kann eine Abfrage verwenden, um alle Gebäude zu finden, deren Attribute nicht unserem Datenmodell entsprechen.

Man kann damit auch nach Anomalien suchen, welche möglicherweise aber nicht zwangsweise Fehler sind. Wenn man z.B. den Query Builder öffnet building_I auswählt und “Alle” klickt um alle Attributwerte zu laden, sieht man, dass die meisten Gebäude eine Nummer zwischen 1 und 20 haben (Dieses Attribut ist buildings:levels, die Anzahl der Stockwerke des Gebäudes). Es gibt aber auch die 51. Es ist unwahrscheinlich, dass es ein so hohes Gebäude mit 51 Stockwerken, größer als alles andere in diesem Gebiet gibt. Wir können es aufspüren und eine Notiz erstellen, damit die Mapper dies prüfen können.

Abfragen können ein effektives Mittel sein, um mögliche Fehler in Daten zu finden. Zusammen mit anderen Fähigkeiten von QGIS können Karten erzeugt werden, die zur Überprüfung von Daten in einem Gebiet verwendet werden können.

Zusammenfassung

Wir haben in diesem Tutorial einige effektive Daten-Qualitätssicherungsmethoden vorgestellt, die während eines Projekts angewandt werden können und einige praktische Übungen zur Überprüfung von OSM Daten durchgeführt. Zur Durchführung eines Mapping Projekts oder zur persönlichen Überprüfung von Daten in einem Gebiet, können diese Methoden nützlich sein.