Wie kommt man an die OpenStreetMap-Rohdaten? Man braucht sie, wenn man eigene Karten rendern oder eigene Projekte durchführen will. Bekommen kann man sie nun wieder etwas einfacher: neben der nicht unbedingt als zuverlässig bekannten XAPI gibt es jetzt Overpass API, sowohl mit einem Kompatibilitätsmodus für XAPI als auch mit eigener Syntax, die die Möglichkeiten des Servers besser ausnutzt. Speziell für geographisch kompakte Anfragen ist Overpass API zudem oft um eine Größenordnung schneller – größere Ausfälle hat es hier auch in einem halben Jahr Testbetrieb nicht gegeben.
Zwei Beispiele, die sich auf http://www.overpass-api.de/query_form.html einfügen lassen:
<query type="node">
<has-kv k="amenity" v="bank"/>
<bbox-query s="51.15" n="51.35" w="7.00" e="7.35"/>
</query>
<print/>
liefert alle Banken in Wuppertal.
<union>
<query type="relation">
<has-kv k="network" v="VRR"/>
<has-kv k="ref" v="622"/>
</query>
<recurse type="relation-node"/>
</union>
<print/>
liefert die Buslinie 622 samt aller ihrer Bushaltestellen. Zahlreiche weitere Beispiele stehen auf der Wiki-Seite.
Die technische Realisierung nimmt die Idee des Projektes auf: Overpass API ist Hardware-sparsam ausgelegt, damit potentielle Nutzer leicht eine eigene Kopie installieren können. Es reichen bereits 1 GB RAM und 60 GB Festplatten-Speicherplatz für den kompletten Planeten, inklusive minütlicher Updates. Der Server hinter www.overpass-api.de hat 4 GB RAM und einen Zweikernprozessor, ermöglicht aber eine gute Leistung, weil die Server-Geschwindigkeit ohnehin vorwiegend von der Festplatten-Geschwindigkeit abhängt. Auch die Software-Voraussetzungen sind moderat: GNU automake sorgt dafür, dass jede Variante von Linux und Co. ausreicht. Insbesondere ist keine relationale Datenbank mehr erforderlich.
Den Geschwindigkeitsvorteil erzielt Overpass API vor allem dadurch, dass räumlich nahe beieinanderliegende Daten auch zusammen von der Festplatte gelesen werden. So verursacht das Abrufen aller Daten einer Kleinstadt nur noch Leseaufwand von ein paar 512-KB-Blöcken anstatt hunderter oder gar tausender kleiner Zugriffe, wie sie in einer relationalen Datenbank auftreten würden. Auf räumlich stark verteilten Abfragen ist also kein Geschwindigkeitsvorteil zu erwarten, aber solche Abfragen sind, den Logs nach zu urteilen, eher selten.
Für die Abfrage verwendet Overpass API eine eigens entwickelte XML-basierte Skriptsprache, es gibt aber auch einen XAPI-Kompatibilitätslayer. Die Skriptsprache auf Konsistenz ausgelegt und kann auf die XML-Regeln für Sonderzeichen-Behandlung zurückgreifen, und sie bildet den Rechenaufwand angemessen ab: Die Abfrage nach alle Elementen in einer Bbox sind z.B. mehr Code als die Abfrage nur nach Nodes, weil die übrigen Elemente auf den Nodes basierend berechnet werden müssen – langlaufende Abfragen fühlen sich also auch als Skript langlaufend an.
Für die nächste Version, 0.7, ist geplant, auch die Metadaten Version, Timestamp, User und Changeset zu OSM-Elementen auszuliefern. Dann ließen sich die Ergebnisse z.B. auch Editoren nutzen. Dazu kommen einige Erweiterungen der Skriptsprache, um speziell gemischte Orts- und Tag-Suchen bei Ways und Relations zu verbessern. Ich hoffe diese Version bis Ende August fertigzustellen.
Deine Edits auf einer Karte – wdye – [1]
