In Südostasien werden viele Straßen und Flüsse bei OpenStreetMap von Bing Luftbildern abgemalt. Nun ist es leider so, dass noch nicht flächendeckend die Luftbilder, bzw. eigentlich hochaufgelösten Satellitenbilder zur Verfügung stehen.
Viele Wege enden daher „im Nichts“. Wenn jetzt neue Bilder verfügbar werden, die die Abdeckung verbessern, besteht die Kunst darin diese Wege zu finden.
Ein Fluss hört einfach auf. Mit neuen Luftbildern könnte es weitergehen…
In diesem Beispiel wurde ein Fluss mittels verfügbarer Bilder von links kommend eingezeichnet. Die alte Grenze der Luftbilder ist als Hilfslinie noch sichtbar. Mit einem Update der Bilder bei Bing könnte der Verlauf des Flusses nun weiter fortgesetzt werden.
Wie findet man solche lose Enden?
Zuerst habe ich mir überlegt wie man eigentlich solche lose Enden per Software finden kann. Ich würde die Auswertung gerne regelmäßig machen, daher soll das Ganze auf meinem Server lauffähig sein. Da dort bereits eine PostgreSQL Datenbank mit einem Extrakt für das Karten-Rendering läuft lag es nahe diese Daten auch für die Auswertung zu verwenden.
In einem ersten Schritt soll mein Algorithmus solche Wege finden bei denen entweder der erste Knoten oder der letzte Knoten mit keinem anderen Weg verbunden ist. Um nicht zu viele Treffer zu bekommen fange ich mit den wichtigsten Dingen zuerst an. Meiner Meinung nach sind das die Hauptstraßen. Das lässt sich später noch einfach erweitern, zum Beispiel auf Flüsse oder Eisenbahnen. Diese Daten werden gerendert, sind also auch in meinem Datenbankschema enthalten.
Die Tabelle „planet_line“ ist allerdings bereits für das Rendering vorverarbeitet. Die Geometrie gibt keinen Rückschluss auf die Knoten. Und ich möchte mit den Knoten und nicht mit der Geometrie arbeiten.
Glücklicherweise existiert (eigentlich für die Updates) noch die Tabelle „planet_ways“ bei der die Knoten in einem Array gespeichert sind. Der Default in PostgreSQL verwendet eine für Informatiker ungewöhnliche Nummerierung, das erste Array-Element fängt mit 1 und nicht mit 0 an. Die Anfangs- und Endknoten der interessanten Wege liefert nun folgende Query:
|
1 |
SELECT nodes[1] AS "first", nodes[array_upper(nodes, 1)] AS "last" FROM planet_ways WHERE ARRAY['primary','secondary','tertiary'] && tags |
Das Ergebnis lasse ich in eine temporäre Tabelle speichern. Bei diesen Einträgen muss ich nun prüfen ob sie mit anderen Ways verbunden sind, also in deren „nodes“ Array enthalten sind. Wege bei denen der Anfang an das Ende geknüpft ist werfe ich auch raus. Übrig bleibt eine Tabelle mit „problematischen“ Wegen bei denen der Anfang oder das Ende nicht verbunden sind.
|
1 2 |
DELETE FROM loose WHERE head=tail; DELETE FROM loose AS l USING planet_ways AS w WHERE l.id <> w.id AND ARRAY[l.head, l.tail] && w.nodes; |
Was kann davon verbessert werden?
Für meine Südostasien Auswertung ergibt das eine Liste mit etwas über 8.000 Wegen bei denen mindestens ein Ende lose „in der Luft“ hängt. Ein paar Stichproben zeigen dass das zu zu stimmen scheint. Das sind theoretisch alles Probleme die auch die bereits existierenden Qualitätssicherungstools finden können.
Ich will aber mehr. Ich will diejenigen Stellen finden bei denen es hoch aufgelöste Bing Bilder gibt um das zu verbessern. Dazu brauche ich einen weiteren Schritt. Ich muss prüfen ob die Knoten innerhalb eines Bereiches liegen der von den Bildern abgedeckt ist.
Hier kommen die Grenzen der Luftbilder zum Einsatz. Sind zwar keine „on the ground“ Daten, jedoch sehr nützlich für die Community und werden daher auch in der OSM Datenbank gepflegt (vor allem da es keine funktionierende Alternative gibt und das die pragmatischste Lösung ist um gemeinsam daran zu arbeiten).
Abgleich mit den Luftbildern
Die Grenzen der Luftbilder müssen ebenfalls in die Datenbank importiert werden. Dann kann mittels räumlicher Abfragen aus dem PostGIS Paket geprüft werden ob eine Geometrie innerhalb einer anderen liegt. Hier also ob der lose Endpunkt des Weges in einem Bereich liegt in dem es Luftbilder gibt.
Etwas vereinfacht dargestellt sieht die Abfrage dann so aus:
|
1 |
SELECT * FROM loose AS l, planet_nodes AS n WHERE n.id=l.node AND ST_Within(ST_SetSRID(ST_Point(n.lon/100, n.lat/100), 900913), (SELECT ST_Union(way) FROM planet_polygon WHERE osm_id=-1903739)) |
Zu beachten ist hier besonders das Format der Punktkoordinaten in der Datenbank. Sie werden in der Standardeinstellung in der „spherical mercaator“ Projektion abgespeichert wobei zwei relevante Nachkommastellen in der Datenbank mit abgelegt werden indem das Komma um zwei Stellen verschoben wird. Am Äquator entspricht das einer Auflösung von einem Zentimeter.
Eine Straße kann auch knapp innerhalb eines Luftbildes enden wenn es danach nicht weitergeht
Um eine gewisse Unschärfe an den Rändern der Luftbilder zuzulassen – eventuell hört ein Weg ja auch noch knapp innerhalb eines Luftbildes auf weil es am Rand nicht weitergeht – kann man den Bereich der Luftbildabdeckung auch etwas kleiner machen. In PostGIS geht das mit ST_Buffer, aber eben einem negativen Buffer.
Die Daten ausgeben
Die so gewonnenen Daten sollen jetzt auch angezeigt werden. Als Datenformat für die Ausgabe verwende ich GeoJSON. Dieses Format ist gerade im OSM-Umfeld recht beliebt und von meiner Kartenbibliothek OpenLayers schon unterstützt.
Auf der Webseite sieht man nun die einzelnen Punkte an denen es noch etwas zu tun gibt in einer Karte. Um es übersichtlicher zu halten werden dicht beieinander liegende Punkte zusammengefasst. Eine Verknüpfung zur RemoteControl Schnittstelle von JOSM erlaubt das einfache Laden in den Editor. Wenn kein aktiver JOSM erkannt wird werden Links zu iD/Potlatch angezeigt.
Regelmäßige Aktualisierungen
Der letzte Schritt war dann noch ein Cronjob der die Auswertung regelmäßig startet und die Daten für die Kartenansicht exportiert.
Das Ergebnis kann auf http://compare.osm-tools.org/loose.html betrachtet werden.
Die Karte zeigt lose Enden und die Abdeckung der Luftbilder
Vor dem Abmalen vom Luftbild sollte man die Lagegenauigkeit der Bilder mit einem in OSM vorhandenen GPS Track abgleichen. Wenn schon Straßen existieren und dort die Position gut aussieht ist die Chance groß dass auch in den neuen Bereichen die Ausrichtung stimmt.
Sehr nützlich!!!
Irgendwann wird die Frage eh gestellt. 🙂 Hast du vor die Karte demnächst zu erweitern?
Ich mappe oft in Westafrika. Hierbei entdeckt man häufig im Nichts endende Primary Straßen.
Mein Server hat aktuell nicht die Kapazität um eine weitere Region mit einer Mapnik-Datenbank aktuell zu halten und darauf Auswertungen zu machen. Der Trick an meinem Ansatz war aber gerade, dass ich die Datenbank weiterverwenden wollte.
Mittelfristig gibt es zwei Möglichkeiten. Zum einen würde ich den virtuellen Server gerne durch einen richtigen dedicated Server ersetzten. Dann wäre auch mehr Rechenleistung verfügbar. Momentan schrecke ich da noch vor den Kosten zurück. Wären mindestens 60 Euro pro Monat die ich dann für OSM ausgeben würde. Zusätzlich zur ganzen Freizeit die in das Projekt fließt.
Die andere Möglichkeit wäre die Auswertung auf einem reduzierten Datensatz zu machen. Ich habe noch nicht genauer geschaut wie andere QS Tools das machen, dieser Weg scheint mir aber für eine Auswertung auf Welt-Maßstab sinnvoller.
Hallo Stephan,
Super Tool hast du da gebaut!
Wie mein Vorredner interessiert mich Afrika:)
Ich arbeite mit einem Hilfsprojekt (www.fanga.de.vu) in Burkina Faso West-Afrika und mappe dort wenn ich unten bin, aber auch von zu Hause aus.
Vielleicht finden sich Leute in der Community, die das nötige Wissen +Server haben und man die Karte in mehrere Bereiche auf verschiedene Server aufteilt.
Vermutlich würde der Server schon ausreichen wenn die Auswertung auf eigenen Daten arbeitet.
Ein echter Showstopper ist aber, dass es in Westafrika keine gepflegten Daten zur Verfügbarkeit der Luftbilder gibt. Dann kann auch keine Auswertung gemacht werden.
Ihr könnt immer noch den OSM Inspector verwenden um Fehler in den Daten zu finden.
Pingback: Wo fehlen bei OpenStreetMap noch Daten? - Technology BlogTechnology Blog