Credit: Jeff Schmaltz, NASA's MODIS Rapid Response Team

Nach dem Hurrikan Ike verwenden Einsatzteams auf Haiti Location Based Services auf der Basis von Open-Source-Projekten wie Openstreetmap und Openrouteservice.

Haiti, Sommer 2008. Hurrikane Ike hat gerade die Insel verwüstet und weite Teile überflutet. Geschätzer Schaden: Milliarden Dollar. Hunderte Tote, Zehntausende Obdachlose. Weiträumige Überschwemmungen, zerstörte Brücken und Straßen gestalten den durch die UN organisierten Hilfseinsatz für die über 650000 Betroffenen kompliziert. Mitten in der Katastrophe besteht der freie Routendienst Openrouteservice (ORS, [1]) seine Feuertaufe und zeigt die Flexibilität und Leistungsfähigkeit von Open-Source-Software und offenen Standards.

Freie Software im Katastropheneinsatz

Für die Helfer vor Ort braucht das Katastrophenmanagement der UN innerhalb kürzester Zeit genaue und aktuelle Straßenzustandskarten mit Informationen über Hindernisse, Gefahrengebiete und noch vorhandene oder zerstörte Infrastruktur. Das freie Kartenprojekt Openstreetmap (OSM, [2]), auf dem auch Openrouteservice basiert, soll helfen.

Aber die Qualität der Daten des haitianischen Verkehrsnetzes erweist sich als größeres Problem. Die Openstreetmap-Karten für das Gebiet des Entwicklungslandes in der Karibik stellen sich als unzureichend heraus, ganz im Gegensatz zu europäischen Metropolen und manch anderen Städten in der Dritten Welt (Abbildungen 1 und 2).

Abbildung 1: Im Community-Projekt Openstreetmap kartieren Freiwillige die Welt. Die Qualität der Daten ist in ländlichen Regionen und Entwicklungsländern wie Haiti noch eher mäßig.

Abbildung 2: In Industrieländern und vor allem deren Metropolen sind dagegen flächendeckend auch Fußwege und zahlreiche Details wie Einbahnstraßen erfasst, wie das Beispiel Bonn zeigt.

Glücklicherweise finden sich bei einer Umweltorganisation qualitativ ausreichende Daten über das Straßennetz, die das UN-Team dank offener Standards ohne Umwege über den freien Kartendienst manuell in die Datenbank von Openrouteservice (Abbildung 3) laden kann. Mehrere NGOs wie Cartong.org [3] beteiligen sich jetzt an der weiteren Datenerhebung und -analyse und stellen ihre Ergebnisse den Hilfsorganisationen zur Verfügung.

Abbildung 3: Der freie Routingdienst Openrouteservice verwendet Openstreetmap-Karten für detailreiche Funktionen. Helfer in Haiti planen damit ihre Fahrten mit ständig aktuellen Daten über die Schäden an der Infrastruktur.

Der Lehrstuhl Kartographie des Geographischen Instituts der Universität Bonn realisiert dann über Openrouteservice den dringend benötigten Routenplaner, der für die mobilen Einsatzteams vor Ort ständig aktualisierte Informationen über Erreichbarkeit und Befahrbarkeit einbeziehen muss.

In Haiti pflegen die Mitarbeiter der Hilfsorganisationen die Problemgebiete über die Weboberfläche als Geodatensätze selber in eine von der Uni Bonn bereitgestellte Geodatenbank ein. Die Routenplanung für die Helfer vor Ort berücksichtigt so etwa unpassierbare Gebiete automatisch. Rückmeldungen aus Haiti bestätigen, dass der Dienst schon als Prototyp eine wertvolle Hilfe für die Arbeit vor Ort leistet.

Mit Daten vom Anwender: Mobile Routenservices

Möglich ist dies, weil in den Industrieländern Navigationsgeräte und mobile Kartenanwendungen boomen und moderne Kartensysteme wie Openstreetmap ein Massenphänomenen geworden sind. Typisch fürs Web 2.0 stehen sie ganz im Zeichen des User-generated Content: Fleißige Anwender kartieren, korrigieren und kommentieren die Daten der Wege, Straßen und Gebäude, nicht nur vor ihrer eigenen Haustür.

In Großstädten erreicht Openstreetmap damit schon heute einen deutlich höheren Grad an Details und Genauigkeit als die kommerziellen Pfadfinder Google Maps oder Map24, die den Trend vor einigen Jahren lostraten. Der Vergleich der Abbildungen 2 und 4 zeigt in Openstreetmap Fußwege, Einbahnstraßen und Objekte wie U-Bahnstationen und Fährverbindungen, die bei Google fehlen.

Für den Anwender liegen die Vorteile freier Kartendienste auf der Hand: Qualitativ hochwertige, aktuelle Daten sind kostenlos verfügbar und fast beliebig nutzbar.

Abbildung 4: Für deutsche Städte typisch: Rund um den Hofgarten in Bonn zeigt Google Maps deutlich weniger Details als das freie Pendant Openstreetmap. Auf dem Land oder in der Dritten Welt liegt jedoch meistens Google vorn.

Eigene oder fremde Daten lassen sich, wie das Beispiel Haiti zeigt, meist über offene Standards unkompliziert einbinden. Dabei stellen Lizenzen wie die bei OSM gültige Creative Commons Share Alike [4] die in Europa vorherrschenden Geschäftsmodelle auf den Kopf und öffnen neue Spielräume für Innovationen.

Selbstlose Landvermesser

Das normalerweise umfangreiche und teure Erfassen der Daten übernimmt bei Openstreetmap eine Heerschar von Freiwilligen, die in der Regel weder extra ausgebildet sind noch auf spezielles Hightech-Equipment zurückzugreifen. Das steht zwar komplett konträr zu eingespielten Abläufen kommerzieller oder amtlicher Geodatenanbieter, entspricht aber dem typischen Prosumer-Ansatz des Web 2.0.

Die wahre Stärke von Openstreetmap und ähnlichen Projekten liegt in der großen und aktiven Community, die das gemeinsame Ziel einer weltweiten, freien Wiki-Karte antreibt. Damit hat Openstreetmap tatsächlich das Potenzial, künftig sowohl quantitativ als auch qualitativ neue Meilensteine der Verfügbarkeit digitaler Geodaten zu setzen. Schon heute geraten die Genauigkeit und Aktualität im Bereich der Fußgänger- oder Fahrradnavigation beeindruckend, zumindest solange Benutzer sich in Großstädten und deren Gürteln bewegen (Abbildung 5).

Abbildung 5: Openrouteservice bietet auch Routingfunktionen für Fahrradfahrer und Wanderer, in manchen Umgebungen sogar schon Indoor-Routen.

Marktwirtschaftlich unmöglich

Die dafür notwendigen umfangreichen Geodaten unter marktwirtschaftlichen Bedingungen zu erfassen und zu betreuen wäre für ein Unternehmen unverhältnismäßig aufwändig und sehr schwer erfolgreich zu vermarkten. Im idealen Prosumer-Modell steigt dagegen die Qualität der Informationen in einem ständigen Wiederholungszyklus von Überprüfen und Verbessern kontinuierlich.

Dass die Commons Based Peer-Production [5] funktioniert, hat bereits die Online-Enzyklopädie Wikipedia gezeigt, Collaborative-Effort-Projekte wie OSM profitieren jetzt auch von Erfahrungen, die die Online-Enzyklopädie in den letzten Jahren machte. Getreu dem Wiki-Begründer Ward Cunningham folgt auch Openstreetmap dem Prinzip: Do the simplest thing that could possibly work. Jeder darf mitmachen, jeder kann Daten, die er für wichtig hält, einpflegen, seine oder andere Daten verändern, verbessern oder auch löschen. Eine strikte Organisation oder Bürokratie existiert nicht, die Registrierung per E-Mail-Anmeldung reicht völlig.

Das Projekt Weltkarte

Unwägbarkeiten begegnet das Projekt mit schlichtem Pragmatismus. Diese klare, einfache Struktur hat den Datenbestand von OSM in nur vier Jahren von 0 auf sagenhafte 4,2 Bz-2-komprimierte GByte anwachsen lassen. Als Quellen für die OSM-Daten dienen:

• GPS-Daten von Navigationsgeräten (Waypoints und Tracks zum
  Beispiel aus ».kml«- und
  ».gpx«-Dateien)
• Frei nutzbare Satellitenbilder, zum Beispiel der NASA [6]
• Frei verfügbare Geodaten
• Karten mit abgelaufenem Copyright
• Vor-Ort-Kenntnisse der Benutzer

Bis Herbst 2008 haben gut 70000 Benutzer rund 550 Millionen GPS-Waypoints erfasst, hochgeladen und editiert.

Technologisch besteht Openstreetmap aus den vier Komponenten Karteneditor, Geodatenbank, Kartenrenderer und Kartenviewer. Den Anfang machen Editoren wie Potlatch [7], ein Flash-Online-Editor für den Webbrowser oder der verbreitete Java-Openstreetmap-Editor (JOSM, [8], Abbildung 6) mit seinen vielen Plugins. Die damit eingetragenen Daten landen auf einem zentralen MySQL-Server in einem Serverraum des University College of London. Verschiedene Renderer generieren die OSM-Karten, die die Viewer in Anwendungen oder im Browser darstellen. Interessierte finden einen guten Vergleich der Editoren auf [9].

Abbildung 6: Der in Java geschriebene Editor für Openstreetmap JOSM bearbeitet Benutzerkarten anhand von GPS-Daten oder lädt dafür Onlinekarten.

Auf Wunsch verteilt: Tiles@home

Osmarender [10] und Mapnik [11] dienen OSM als Kartenrenderer. Weil es große Mengen Rechenzeit kostet, eine Karte aus den gespeicherten Vektordaten zu generieren, berechnen alle Engines vorgerenderte Kacheln (Tiles) auf dem Server, die sie als Bilddateien an die Browser der Benutzer ausliefern.

Der Osmarender erzeugt dabei SVG-Vektorgrafiken aus OSM-Daten, wobei die entsprechenden Styles und Regeln in einer separaten Metadatei vorliegen. Das Tiles@home-Projekt [12] verwendet ihn im Seti-Stil für verteiltes Rendern der Kartenkacheln. Benutzer stellen dabei einem Perl-Skript Rechenzeit zur Verfügung, um Millionen von Tiles in Hunderten GBytes zu erstellen und sie auf Mirrors zu hosten. Änderungen oder Ergänzungen an den OSM-Daten sind folglich nicht sofort in den Karten sichtbar. Die Kacheln des Mapnik-Servers werden mindestens einmal pro Woche aktualisiert, bei Tiles@home lässt sich die Aktualisierung der Kacheln auch anstoßen.

Slippy, die Karte

Den in C++ programmierten Open-Source-Kartenrenderer Mapnik haben Programmierer unabhängig von OSM entwickelt, er dient heute primär zum Rendern der Online-Kartendarstellung, der so genannten Slippy Map (flinke Karte). Die schnellen, von Google Maps bekannten Ajax-basierten Kartenclients fürs Web haben sich dank der intuitiven Bedienbarkeit durchgesetzt [13]. Die flinke Karte als das übliche Interface von Openstreetmap basiert auf Openlayers [14] und kann zwar verschiedene Renderer verwenden, Mapnik ist jedoch der Default.

Die Rohdaten stehen frei zur Verfügung, deshalb lassen sich auch individuelle Applikationen, zum Beispiel gemäß dem Web Map Standard (OGC WMS), aufsetzen. Allerdings ist dafür eventuell erheblicher Aufwand für die Aufbereitung der Daten einzuplanen, da die komplette Semantik, zum Beispiel die thematische Gliederung, in den Tags über erweiterte oder optionale Attribute kodiert ist (siehe Abbildung 7).

Abbildung 7: Erweiterte Attribute des Objekts »Autobahn« im JOSM-Editor.

Schnittstellen

Dennoch bieten die freien Standards und Daten umfangreiche Möglichkeiten: Openrouteservice nutzt beispielsweise Openstreetmap-Daten und betreibt selbst einen eigenen Webmapping-Service, unter anderem mit OSM-Daten mehrerer Staaten, indem er Styled-Layer-Deskriptoren (OGC SLD) zur Konfiguration der verschiedenen Maßstäbe und Layer verwendet.

Der Zugriff auf die ungerenderten Rohdaten des OSM-Projekts erfolgt entweder über das OSM-API oder Datendumps. Clients geben einen geografischen Bereich an, den der Server laden soll. So lassen sich maximal 50000 Nodes oder (in Deutschland) eine Fläche von etwa 50 mal 50 Kilometer abfragen. Wem das nicht reicht, der greift über das zweite API namens Osmxapi [15] ohne jede Beschränkung zu oder zieht sich eines der allwöchentlichen Planet Files [16].

Das Datenmodell

Grundlage der Datenbank und des XML-Austauschformats der OSM-Daten ist sein Datenmodell, das drei grundlegende Objekttypen umfasst: Node, Way und Relation (Abbildung 8). GIS-Spezialisten mag überraschen, dass kein spezifischer Objekttyp für flächenhafte Objekte (Polygone) existiert, sondern OSM diese vollständig über Closed Ways realisiert. Jedes Objekt kennt optionale Attribute, Tags genannt, die aus einem Key und einem Wert bestehen. Diese Key-Value-Paare ordnen den Typen weitere Beschreibungen zu. Jeder Node und jeder Way erhalten in der OSM-Datenbank einen eigenen, eindeutigen und numerischen Identifikator (ID), über den sich die Objekte abrufen, bearbeiten und löschen lassen.

Abbildung 8: Nodes sind das Grundelement der Openstreetmap-Daten, Linien und Umrisse setzen sich aus einzelnen Ways zusammen. Jeder Node muss mindestens drei Attribute enthalten: ID (»id«), geografische Länge (»lat«) und geografische Breite (»lon«).

Die OSM-Nodes reichen aus, um einzelne geografische Punkte oder Orte wie Sehenswürdigkeiten, Ortschaften, Städte und andere Points of Interests (POI) zu beschreiben. Mit den Ways sind dann Start-, End- und alle Zwischenpunkte einer Linie sowie der Umriss einer Fläche möglich. Ein Way ist in OSM ein Linienzug, der aus mehreren durch Geraden verbundenen Nodes besteht. Ways beschreiben hauptsächlich Straßen und Wege, aber auch Elemente wie Flächen, Flüsse oder Eisenbahnlinien.

Relationen modellieren im OSM-Datenmodell Beziehungen zwischen den OSM-Objekten. Jedem Node oder Way lassen sich beliebig viele Map-Features zuordnen, die ein umfangreicher, offener Objektartenkatalog definiert [17]. Auf [18] diskutieren die OSMler neue Features, wer die Ankunft seines Feature nicht erwarten kann, verfolgt den aktuellen Stand auf Tagwatch [19].

Openrouteservice

Dass die Daten und das Datenmodell schon heute für andere Anwendungen verwendbar sind, zeigt Openrouteservice. Mittlerweile deckt ORS neben Deutschland auch die Schweiz, Österreich, Belgien, Italien, Lichtenstein, Dänemark und das ehemalige Heimatland von Openstreetmap, Großbritannien, mit Irland ab. Weitere Staaten sind in Arbeit.

Openrouteservice ist aber weit mehr als ein einfacher Routenplaner, er bündelt mehrere Dienste der Open Location Services (OGC OpenLS, [20]) als Funktionen wie einen Gelbe-Seiten-Dienst für die freie Umgebungssuche, Geocoding und Reverse Geocoding für Adressensuche in einem Webportal.

Neben den einfachen Routingfunktionen stehen dem Benutzer Zusatzfunktionen wie Ausschlussgebiete, Verkehrsinformationen über den Traffic Message Channel (RDS-TMC, [21]), ein Directory-Service mit Points of Interest und die vom aktuellen Standort aus innerhalb einer vorgegebenen Zeit erreichbaren Regionen zur Verfügung (Abbildungen 9 und 10).

Abbildung 9: Openrouteservice kennt Ausschlussgebiete, die die Routenberechnung vermeiden soll. Die Reisedauer lässt sich in Echtzeit berechnen, inklusive immer aktueller Verkehrsdaten aus dem RDS-TMC. Dazu kommt eine Umgebungssuche, die auch den nächsten Biergarten findet.

Abbildung 10: Die Erreichbarkeitsanalyse von Openrouteservice beantwortet Fragen wie: Welches Gebiet ist von der Bonner Innenstadt aus innerhalb von 25 Minuten erreichbar? Die Abbildung zeigt darüber hinaus Staus und Baustellen, die TMC gemeldet hat.

Freie 3D-Dienste

All diese Standard-Dienste greifen auf speziell aufbereitete Daten von Openstreetmap zu, Entwickler können sie nach Belieben in Anwendungen integrieren oder eigenständig nutzen. Die noch im Aufbau befindliche 3D-Geodaten-Infrastruktur GDI-3D [22] verwendet beispielsweise den Open Location Services (OpenLS) Directory Service, um die POIs dreidimensional auf einem digitalen Geländemodell darzustellen. Vor allem das Projekt Heidelberg 3D [23] demonstriert die Möglichkeiten, die dieses offene Konzept bietet.

Auch Openrouteservice nutzt eine ganze Kette von OGC-Diensten wie den OGC Sensor Observation Service (SOS, [24]) und den Web Processing Service (WPS, [25]), um die von Radio und Navigationsgeräten bekannten RDS-TMC-Daten in der Karte anzuzeigen (Abbildung 10). Der Anwender aktiviert im Webfrontend einfach ein Optionsfeld, und schon berechnet ORS die optimale Route und die zu erwartende Dauer in Abhängigkeit von Staus, Baustellen und zu erwartender Verkehrsdichte. TMC ist in der aktuellen Version aber nur für Nordrhein-Westfalen und Bayern integriert.

Openrouteservice als Java-6.0-Programm läuft als Servlet in einem Tomcat-Server ab Version 5.5. Die Kommunikation erfolgt OLS-typisch über HTTP-Posts und in Form von XML-kodierten Anfragen und Antworten. Alle benötigten Daten des Dienstes sind in einer PostgreSQL-PostGIS-Datenbank gespeichert, der Informationsaustausch zwischen den OpenLS-Services (Abbildung 11) und der Datenbank findet über JDBC statt.

Abbildung 11: Hinter dem Webfrontend von Openrouteservice steckt ein komplexes Modell verschiedener Services mit klar umrissenen Funktionen. Neben den vier Hauptkomponenten Viewer, Services, Renderer und Datenbanken fallen vor allem die umfangreichen Open Location Services (OpenLS) auf.

Performance-Messung

Tests mit unterschiedlichen Routing-Bibliotheken (Geotools oder Pgrouting) und -Algorithmen (Dijkstra, A*) und Routen-Längen zeigen bei kurzen Routenberechnungen keine großen Geschwindigkeitsunterschiede. Soll das System allerdings größere Routen im Bereich von mehreren Hundert Kilometern ermitteln, rechnet die ORS-eigene optimierte Java-Implementierung des A*-Algorithmus am schnellsten.

Openstreetmap existiert seit vier Jahren, Openrouteservice noch nicht einmal ein Jahr. Auch wenn ORS noch manchmal hakt oder etwas länger braucht, um Abfragen zu beantworten, schreitet die Entwicklung doch rasant voran: Im Herbst 2008 waren schon über 6 Millionen Straßensegmente enthalten, Karten- und POI-Daten für ganz Europa sind in Arbeit. Neben dem Web-GUI haben Entwickler erste mobile Clients für Smartphones und PDAs mit Webbrowser oder über Java-Midlet-Technologie entwickelt, zum Beispiel für Googles Android-Plattform.

Vorfahrt für freie Daten

Die freien GIS-Dienste wie OSM und ORS stehen für beispiellose Erfolgsgeschichten, die ohne Open-Source-Software und offene Standards unmöglich wären. 3D-Routingsysteme wie in Heidelberg, mobiles Routing übers Smartphone, erweiterte Grid-Computing-Ansätze zur Berechnung der Karten, Emergency-Routingsysteme wie im Projekt “Offenes Katastrophenmanagement mit freiem GIS” (OKGis, [26]) klingen vielversprechend und eröffnen umfangreiche Möglichkeiten.

Dabei hat Europa im Gegensatz zu den USA noch großen Nachholbedarf, was das Angebot an frei verfügbaren, öffentlichen Geodaten angeht. Im Zuge der INSPIRE-Initiative [27] entstehen jedoch mehr und mehr Geoportale und freie, OGC-konforme Datenquellen, die sich in GIS-Portale integrieren lassen.