Wichtiges Element der neuen Version ist, dass erstmals ein Feature nicht von mir selbst entwickelt worden ist, sondern von Mmd beigetragen worden ist. An dieser Steller erst einmal ein herzliches Dankeschön dafür.

Es handelt sich dabei um einen neuen Ausgabemodus, „out:csv“. Wie der Name vermuten lässt, gibt eine Abfrage wie

[out:csv(::id,::type,"name")];
area[name="Bonn"]->.a;
( node(area.a)[railway=station];
way(area.a)[railway=station];
rel(area.a)[railway=station]; );
out;


alle Bahnhöfe in Bonn mit ihren jeweiligen Namen als Tabelle aus. So könnten die Daten direkt in LibreOffice übernommen werden. Dabei kann über die angegebenen Parameter in der Klammer gesteuert werden, welche Tags oder Sonderelemente wie Id und Co ausgegeben werden. Es gibt folgende spezielle Bezeichner:

• id
• type
• version
• timestamp
• changeset
• uid
• user
• lat
• lon

Dabei ergeben „lat“ und „lon“ nur dann sinnvolle Angaben, wenn Nodes abgefragt oder der Modus „center“ zur Ausgabe verwendet wird. Weitere einstellbare Parameter sind das Trennzeichen zwischen zwei Datenzellen und ob es Überschriften geben soll.

Der Modus ist aber noch nicht abschließend fertig: CSV ist kein so klar umrissenes Dateiformat wie XML oder JSON. Die Tücke liegt dabei in Detailfragen, z. B. welche Zeichen auf welche Weise escaped werden sollen, ob man Anführungszeichen um Einträge mit Leerzeichen oder gleich für alle Einträge braucht. Oder auch nur, wie Fehlermeldungen eingebaut werden sollen. Daher bitte ich um Rückmeldung, am besten als Issues auf Github, oder als Mail an talk@ oder talk-de@.

Eine weitere große Neuerung ist, dass jetzt auch nach Keys mit regulären Ausdrücken gesucht werden kann:

rel[~"^name"~"^Schweiz$"];
out;

untersucht gleich alle Tags, deren Key mit „name“ beginnt, darauf, ob sie den Wert „Schweiz“ haben – der Wert steht in der Tat hier nur im „name:de“-Tag.

Weitere Verbesserungen sind, dass die Suche nach seltenen Tags auf großen Flächen jetzt schneller geht. Dieser Wunsch kam speziell von den Machern der Wochenaufgabe, und ich erfülle ihn gerne.

Zurück zu den holprigen Umständen der Einführung: wie bei jedem längeren Ausfall der Overpass API möchte ich gerne ein paar Worte zur Erklärung liefern. Dieses Mal hat es nicht einen schicksalhaften Hardware-Ausfall oder äußere Umstände gegeben, sondern schlicht ein gewisses Maß an Ungeschicklichkeit bei mir. Ich muss ein wenig ausholen.

Die Datenbank besteht neben einer großen Menge Dateien vor allem aus zwei Prozessen, „dispatcher“ genannt, die die Schreib- und Lesezugriffe miteinander koordinieren. Damit ist sichergestellt, dass jede Leseabfrage immer den gleichen konsistenten Zustand der Datenbank wie zum Startzeitpunkt sieht, auch wenn in der Zwischenzeit ein Schreibprozess Änderungen geschrieben hat. Es gibt zwei Arten von Schreibprozessen, solche, die die Daten von der Hauptinstanz übernehmen, und den Schreibprozess, der aus den Ways und Relations Areas berechnet. Beide sind voneinander unabhängig und daher gibt es zwei getrennte Dispatcher, die jeweils eine Art von Schreibprozess koordinieren sollen.

Leider habe ich zwar den „dispatcher“ für die Hauptdatenbank richtig konfiguriert, aber dem „dispatcher“ für die Areas irrtümlich mitgegeben, er solle sich auch um Metadaten kümmern. Das hat dann dazu geführt, dass er sämtliche Metadaten gelöscht hat, wann immer er mit den Areas fertig geworden ist. Daher habe ich den letzten erhaltenen vollständigen Stand der Datenbank vom 22. Oktober aus dem Clone zurückkopiert. Leider dauert es dann ungefähr einen Tag, bis die Änderungen aus den letzten 11 Tagen wieder eingepflegt sind. Nun sollte die Overpass API wieder voll einsatzfähig sein, sogar mit erweiterter Funktionalität.

Am 28. Mai wird die Overpass API ein kleines Jubiläum erreichen: seit dann fünf Jahren versorgt sie die Nutzer von OpenStreetMap mit genau dem Teil der Daten, den sie wollen.

Das tut sie mit durchaus Erfolg: allein im letzten Jahr ist die durchschnittliche tägliche Nutzerzahl von 700 auf 4500 gestiegen (Vergleich März 2012 bis März 2013 gegenüber März 2013 bis März 2014).

Auch die Anzahl der Anfragen ist auf mittlerweile durchschnittlich 180.000 pro Tag gewachsen, die abgefragte Datenmenge auf 45 GB pro Tag.

Kehrseite des Wachstums ist, dass nun doch so langsam die Kapazitätsgrenze der Festplattengeschwindigkeit auf dem Server erreicht ist. Statt den Mangel zu verwalten, würde ich gerne die Kapazität erhöhen: mit einer SSD statt einer traditionellen Festplatte ist etwa eine Verzehnfachung der Kapazität möglich.

Dies schafft dann auch die Kapazitätsreserve, um demnächst auch alte Daten archiviert anbieten zu können und dann endlich unerwünscht gelöschte Daten in der OpenStreetMap-Datenbank leicht wiederfinden zu können.

Das kostet allerdings Geld, auf eine Sicht von 2 Jahren etwa 1300 EUR. Nach Rücksprache mit dem FOSSGIS würde ich gerne im Wege von Spenden an den FOSSGIS

FOSSGIS e.V.
BLZ: 551 900 00
Mainzer Volksbank
Kto.: 415938026
IBAN: DE93 5519 0000 0415 9380 26
BIC: MVBM DE 55

mit Betreff „Overpass API“ dieses Geld sammeln. Für alle, die gerade eine Steuererklärung gemacht haben: Spenden an den FOSSGIS sind nach derzeitigem Stand von der Einkommenssteuer befreit, wenn man sie in der Steuererklärung angibt und eine Kopie des Kontoauszugs beilegt. Ich selbst werde 50 EUR spenden, aber auch eine Spende von 5 EUR finanziert die Erweiterung bereits für 3 Tage.

Sollte mehr Geld zusammenkommen, werden wir den Betrieb der Overpass API einschließlich der SSD-Erweiterung für mehr als zwei Jahre im Voraus finanzieren können. Sollte weniger Geld zusammenkommen, entsprechend kürzer.

Beobachtungen

Wie man im Munin für die Overpass API unter Lese-/Schreibauslastung sehen kann, sind die Festplatten an etwa 16 Stunden des Tages über 95 Prozent aktiv, d.h. an ihrer definitiven Leistungsgrenze.

Ein Testlauf (danke dafür an Malcom Herring) mit einer leider nicht Server-tauglichen SSD hat für das weltweite Auslesen von Seezeichen die Laufzeit von 30 Minuten auf 2 Minuten reduziert. Daher die Hoffnung, dass eine SSD eine Kapazitätserweiterung um den Faktor 10 tatsächlich erbringen kann.

Die Statsitiken zu Nutzerzahl, Datenmenge und Abfragenzahl sind leider etwas schwierig zu lesen, da ich sie nicht groß aufbereite: Der komplette Datensatz wird als JSON übertragen und kann dann client-seitig im Browser untersucht werden.

Mit dem ersten Dropdown-Feld kann gewählt werden, ob alle Abfragen oder nur die auf /api/interpreter bzw. nur die auf /api/xapi usw. berücksichtigt werden. Mit dem nachfolgenden Testfeld kann auf ein einzelnes Land mit ISO-Ländercodes eingeschränkt werden.

Zu „Ltr“ oder „Rtl“ ist etwas mehr Erklärung notwendig: Jedes Diagramm stapelt die Zahlen segmentiert nach total abgefragter Datenmenge pro IP-Adresse pro Tag. So lässt sich unterscheiden, ob sehr viele Nutzer jeweils wenig Daten herunterladen (z.B. eine neue Smartphone-App), sehr wenige Nutzer sehr viele Daten (Massennutzer) oder viele Benutzer mittlere Datenmenge (Wachstum der normalen Nachfrage). Die Stufen sind: unter 1 KB, 1 KB – 10 KB, dann weiter mit Zehnerpotenzen bis 100 MB bis 1 GB, danach über 1 GB. Die graue Kurve zählt z.B. Nutzer, die insgesamt weniger als 1 KB Daten heruntergeladen haben. Die grüne Kurve liegt bei 1 MB bis 10 MB, die rote Kurve kennzeichnet die höchste Stufe über 1 GB. „Ltr“ stapelt klein auf groß, „Rtl“ stapelt groß auf klein.

Mit dem nächsten Zahlenfeld kann man das anzuzeigende Maximum automatisch bestimmen lassen (Wert „0“) oder manuell setzen (anderer Wert). Danach folgen zwei Felder für minimales und maximales Datum. Das letzte Feld erlaubt, über mehr als einen Tag zu mitteln; es wird dann der Mittelwert der letzten entsprechend vielen Tage angegeben. Z.B. habe ich obige Werte mit dem Jahreswert 360 berechnen lassen.

Und eben damit die Kurve auch in Zukunft Wachstum zeigen kann: Vielleicht schaffen wir es ja gemeinsam, zum fünfjährigen Jubiläum die Kapazität per SSD bereits vervielfacht zu haben.

Kurz vor Weihnachten hat die Overpass API einige Anfragen deutlich langsamer als gewohnt beantwortet. Das ist zwar recht bald wieder besser geworden. Aber seitdem verhält sich die Overpass API an einer anderen Stelle weniger schnell als gewohnt: Ist normalerweise der Datenstand nur 1-2 Minuten hinter der Hauptdatenbank, so ist er im Moment in den Abendstunden oft bis zu 30 Minuten hinter dem Datenstand der Hauptdatenbank.

Dies kann man am Wert „Lag to OSM Main Database“ hier ablesen.

Das erste Phänomen hängt allein mit Areas zusammen: Entgegen meinen Vermutungen auf Talk-De lag es nicht direkt an einer Fläche über den Südpol, sehr wohl aber an der neu erfassten Fläche für die Antarktis. Diese Fläche soll alles südlich des 60 Grades südlicher Breite umfassen. Das ist mal locker ein Sechstel der Koordinatenfläche in Längen-Breitengrad-Systematik und damit z. B. ein Vielfaches der bereits riesigen Fläche von Russland. Das war zu groß für die Software. Das Problem ist bis auf Weiteres dadurch gelöst, dass die Erzeugung sehr großer Flächen jetzt übersprungen werden. Es betrifft die Gesamtrelationen für Russland, Australien und eben mehrere Antarktis-Relationen. Damit kann dann auch ein wohlmeinender Mensch mit einer Eurasien- oder Pazifik-Relation nicht mehr die Datenbank sprengen.

Aber woher kommt der Rückstand zur Hauptdatenbank und wann wird das wieder besser? Zeit für Detektivarbeit!

Fangen wir mit dem Naheliegenden an: Gibt es mehr Andrang auf der Overpass API? Danach sieht es nicht aus. Die Anzahl unterschiedlicher IP-Adressen pro Tag ist seit September bei 4000 etwa gleich geblieben. Die Anzahl der Queries ist sogar gefallen, aber da Queries unterschiedlich groß sein können, muss das nichts heißen. Es kommt durchaus vor, dass Nutzer über 10.000 Objekte einzeln per Id abfragen – das macht kaum Last, erhöht aber stark den Query-Zähler.

Die übertragene Datenmenge ist andererseits gestiegen, aber erstens bei weitem nicht so stark, dass dies die Last erklären könnte, und vor allem passt die Verteilung kaum zu den Lastspitzen des Update-Prozesses.

Unser Detektiv würde sich also wohl eher anderen Verdächtigen zuwenden, aber die Leser mögen das Phänomen im Hinterkopf behalten.

Der nächste Verdächtige ist die Datenbank für die nächste Version der Overpass API. Diese wird zwei maßgebliche Verbesserungen bringen. Zum einen wird die auf der SoTM 2013 (korrigiertes Video) angesprochene Kombination aus großer Bounding-Box und Tag-Kriterium schneller, denn die Datei, die Tags auf Ids abbildet, merkt sich jetzt auch geographische Indizes. Zum anderen wird die Datenbank die volle Historie seit dem Lizenzwechsel bekommen, so dass man beispielsweise auch abfragen könnte, welche Briefkästen in Bonn im Dezember 2012 gemappt gewesen sind.

Das erfordert allerdings, mit einem Planet vom Lizenzwechsel zu starten und alle Diffs seitdem auf die Datenbank anzuwenden. Das durchzurechnen dauert etwa einen Monat und passiert seit dem 21. Dezember.

Eigentlich kann es die aktuelle Version nicht beeinträchtigen, da die neue Version mit ionice läuft. Ionice ist ein Werkzeug des Linux-Kernels, um die Festplatten-Priorität für einzelne Prozesse zu verändern. Die neue Datenbank wird mit so niedriger Priorität gerechnet, dass nur dann Zugriffe stattfinden sollten, wenn für die aktuelle Version nichts zu tun ist. Auf die gleiche Weise ist übrigens generell auch die Area-Erzeugung herunterpriorisiert.

Beides funktioniert sehr wirksam: Sowohl die Area-Erzeugung als auch die neue Datenbank werden weniger als halb so schnell bearbeitet, wenn die aktuelle Version mehr als eine Minute Verspätung sammelt. Anders ausgedrückt: die beiden Verdächtigen haben ein sehr gutes Alibi.

Zeit für einen ungewöhnlicheren Verdächtigen: die aktuelle Version bietet die sogenannten Augmented Diffs – Diffs, die alle Geometrie-Information explizit enthalten, damit man diese auch einzeln ohne Datenbank auswerten und darstellen kann. Die Diffs werden z. B. für Norbert Renners Achavi genutzt (laufende Instanz).

Die Erzeugung ist zwangsläufig mit den normalen Updates verzahnt, denn dabei stehen die benötigten Daten zur Geometrie ja genau zur Verfügung. Allerdings kann das trotzdem viel Zeit brauchen: Wenn nämlich ein Knoten einer großen Relation, z. B. der deutschen Grenze angefasst wird, ändert sich deren Geometrie. Und für den vollständigen Augmented Diff müssen dann die geometrischen Daten der ganzen deutschen Grenze gesammelt werden. Das kostet Zeit.

Tatsächlich spielt das eine Rolle, denn die Datenmengen pro Stunde Datenbank-Zeit (und nicht die Größe eines einzelnen Diffs, diese ist für einen mehrminütigen Diff sowieso größer als für einen einminütigen) sind in den Abendstunden tatsächlich spürbar größer. Allerdings gilt auch hier: Größen-Rekorde hat es im Dezember nicht gegeben, sondern in den Monaten vorher, in denen die Overpass API auch abends näher am Puls der Zeit war. Wir haben also einen Teil des Rätsels geklärt, nämlich warum speziell von 17 bis 24 Uhr sich die Verzögerungen häufen.

Übrigens wird dieses Problem mit der neuen Version besser: dann können Augmented Diffs bei Nachfrage erzeugt werden, was nicht nur beliebige Zeiträume (1 Sekunde ebenso wie mehrere Monate) erlauben wird, sondern eben das Problem, die Geometrie vollständig nachschlagen zu müssen, vom Update-Prozess entkoppelt.

Unauffällig dazugekommen ist auch eine andere Funktion: Die auf dem Export-Tab von osm.org seit neuestem erwähnte Map-Export-Funktion (mit der eigenwilligen Übersetzung „API überführen“ – hört sich an, als wenn da eine Maschine übersetzt hat. Kann man eigentlich Übersetzungen weniger aufwendig als mit einem Pull-Request beitragen?). Diese könnte eine hohe Last erklären, weil sie es leicht macht, große Datenmengen abzufragen. Andererseits verhindert ein eher aggressiver unumgänglicher 5-Minuten-Timeout, dass die Abfragen zu aufwendig werden.

Um die Last des Map-Aufrufs gesondert herauszufinden, habe ich das Logging erweitert: Laufzeiten abzufragen wäre kontraproduktiv, weil gleich aufwendige Abfragen ja langsamer laufen, wenn generell die Server-Last höher ist. Man findet dann nur neu heraus, was man schon vorher wusste. Die schlichte Anzahl der Abfragen hilft hier nicht, weil ja gerade der Verdacht besteht, dass spezielle Abfragen viel aufwendiger als die Durchschnittsabfrage sind.

Also zähle ich jetzt Plattenzugriffe. Da fast alle Plattenzugriffe der Overpass API einheitlich je 512K en bloc lesen, reicht zählen hier aus. Das hat eine große Überraschung gebracht.

Zu erwarten wären grundsätzlich etwa 8 Zugriffe pro Sekunde bzw. knapp 30.000 Plattenzugriffe pro Stunde, da die Festplatte ihren Lesekopf jeweils zum Anfang des Blocks bewegen muss. Die Messungen ergeben aber mehr als 1.2 Mio. Zugriffe pro Stunde (20.000 pro Minute), also das 40-fache! Dann spielt der Cache eine viel größere Rolle, als ich bisher immer vermutet habe. Der Cache ersetzt Festplattenzugriffe durch Abrufe vorhandener Kopien der gleichen Daten im RAM, was etwa um den Faktor 1000 schneller geht als ein Festplattenzugriff. Demnach kommen also wohl knapp 98% aller Blöcke statt von der Festplatte vom Cache. Das spricht sehr für die Qualität der Cache-Algorithmen im Linux-Kernel.

Entgegen der Erwartungen passt aber das Lastmuster bei den Plattenzugriffen nur äußerst schlecht zu den Lastspitzen der Update-Funktion. Das allein erklärt es also nicht.

Es hat mich aber auf eine andere Hypothese gebracht, und wie es sich für einen guten Krimi gehört, ist sie durchaus etwas verworren: Die Leistungsfähigkeit der Update-Funktion hängt maßgeblich davon ab, wie groß der Anteil der Datenbank ist, der im Cache statt nur auf der Festplatte liegt. Wenn nun die zweite Datenbank bearbeitet wird, belegt diese ebenfalls einen erheblichen Teil des Caches. Dazu kommt, dass die Map-Abfragen gerne viel RAM belegen. Das spielt alles eine untergeordnete Rolle, solange nicht für die Augmented Diffs große Datenmengen gewälzt werden müssen. Aber so machen sich die Augmented Diffs jetzt bemerkbar, während vorher der Cache die zusätzliche Last kaschiert hat.

Wenn die Erklärung richtig ist, wird sich die Lage entspannen, wenn die neue Version aktiv wird. Diese braucht ja weniger Last für die Augmented Diffs. So sehe ich also gespannt dem Moment voraussichtlich Ende Januar entgegen, wenn die Datenbank für neue Version auf die aktuelle Zeit aufgeholt hat.

Für die kommende FOSSGIS im Juni 2013 habe ich noch zu viele Ideen für Vorträge. Ich würde Euch daher unter den nachfolgenden Vorschlägen um ein Votum bitten, was ich anmelde.

Es gibt dabei auf der FOSSGIS die beiden Vortragsformen „Vortrag“ und „Workshop“; für einen „Lightning Talk“ sind die Ideen alle zu umfangreich. „Vortrag“ ist ein normaler 30- bis 45-minütiger Vortrag. Ein „Workshop“ umfasst mehr Zeit, ist aber für die Teilnehmer gebührenpflichtig; die Gebühren dienen dem FOSSGIS zur Finanzierung der Konferenz. Ich werde die Materialien aus dem Workshop daher dann nachher auch in anderer Form zugänglich machen, so dass auch Teilnehmer mit schmalen Bugdet davon profitieren. Die Vortragsfolien wird es ohnehin online geben.

Syntax und Semantik der Overpass API

Die Overpass API ist eine über das Web erreichbare Datenbank, die den OSM- Datenbestand spiegelt. Sie bietet dabei schnellen Lesezugriff mit umfangreichen Abfragemöglichkeiten und ergänzt so die zentrale OSM-Datenbank, die auf Schreiboperationen ausgelegt ist.

Die Overpass API wird heute bereits für eine Vielzahl von Anwendungen, z.B. zur Qualitätssicherung, für in Echtzeit erzeugte Kartenoverlays, thematische Downloads oder auch zur Beschleunigung der Main API verwendet. Ihren Geschwindigkeitsvorteil erzielt die Overpass API durch eine optimierte Datenhaltung anstatt einer relationalen Datenbank.

In diesem Vortrag wird in die Abfragesprache systematisch eingeführt. Als Beispiele werden ein Kartenoverlay auf Basis von OpenLayers erstellt, es wird die spezielle Area-Syntax zur Generierung der Straßenliste einer Stadt verwendet, und es wird als Beispiel für eine mehrstufige Abfrage das Tool zur Erstellung von Bus- und Bahn-Linienbändern und -plänen vorgestellt.

Mobile Karten erstellen mit OSM, OpenLayers und Overpass API

Mit OpenStreetMap stehen nicht nur freie Daten zur Verfügung, sondern wegen der hervorragenden Community decken diese auch ein sehr breites thematisches Spektrum ab, und sie erreichen dabei eine Aktualität, die sich eher in Tagen und Stunden als Monaten und Jahren bemisst.

Mit der Kombination der freien Werkzeuge OpenLayers und der Overpass API lassen sich diese leicht in einer Karte für thematische Overlays visualisieren, die sowohl gleichermaßen auf dem Desktop wie auf mobilen Endgeräten funktioniert, aber trotzdem nicht mehr Infrastruktur als eine einfache HTML-Seite braucht. Dank Overpass API ist sie stets minutenaktuell und auch spontan im HTML-Code oder sogar zur Laufzeit konfigurierbar.

Anhand einer Beispielkarte werden die Möglichkeiten erläutert: Es wird gezeigt, wie durch ein durchdacht einfaches Bedienkonzept und Nutzung der Geolokalisierung eine Smartphone-freundliche Karte entsteht. Wir werden eigene Kategorien von Points of Interest spontan als Kartenoverlay hinzufügen. Und es wird gezeigt, wie durch Kombination von Tag-Verarbeitung auf dem Client und Rückgriff auf die Nominatim-API zu jedem POI automatisch eine Adresse ermittelt werden kann.

Änderungsverfolgung in OSM

Nachdem der OpenStreetMap-Community die Aufgabe, Daten zu erfassen, mit Bravour erfüllt hat, tritt zunehmend auch die Aufgabe der Datenpflege in den Vordergrund. Fehlerhafte oder veraltete Daten sind dabei mindestens so heikel wie fehlende Daten, denn sie untergraben das Vertrauen in die Qualität der Datenbank.

Dabei kann es für fehlerhafte Daten viele Ursachen geben: Weit häufiger als Vandalismus sind dies Bedienfehler von Neu-Mappern. Noch schwieriger zu finden sind Seiteneffekte anderer Edits wie beschädigte Relationen, nicht eindeutige oder irrtümlich gewählte Tags oder sogar unerwartete Nebenwirkungen der wenigen Methoden, bereits hochgeladene Änderungen rückgängig zu machen.

Wir geben einen Überblick, mit welchen Tools sich Änderungen visualisieren und verfolgen lassen, stellen Methoden zur Wiederherstellung alter Datenzustände vor und erläutern, wie sich auf Basis der Neuentwicklung „Augmented Diffs“ eigene, spezialisierte Tools entwickeln lassen.

Augmented Diffs in der Praxis

Der Wunsch in Frederik Ramms Vortrag zu „Augmented Diffs“ vom letzten Jahr ist seit dem Hack-Weekend in Karlsruhe im Oktober 2012 Wirklichkeit geworden: Die Augmented Diffs bieten zusätzlich zu den Diffs der Main API alle nötigen Informationen, um Änderungen geographisch verorten zu können oder auch einen Diff in der Zeit rückwärts anwenden zu können. Sie stellen damit ein sehr hilfreiches Werkzeug zur Änderungsverfolgung dar.

Leider sind die „Augmented Diffs“ aber auch in den Mühen der Ebene angekommen: Die potentiellen Anwendungen für Augmented Diffs sind so unterschiedlich, dass verschiedene Formate notwendig werden. Schon beim Löschen eines Elementes müssen zwei statt einem Satz Metadaten hinzugefügt werden. Die Geometrie eines Weges oder einer Relation kann sich ändern, ohne dass für diesen eine neue Versionsnummer vergeben wird. Beschränkt man den Augmented Diff geographisch, so können sogar Objekte ohne Versionsänderung im Augmented Diff als gelöscht markiert werden müssen. Insgesamt ergibt sich eine unerwartet komplexe Semantik von Änderungstypen.

Dazu kommen Probleme jenseits der Semantik: Einerseits sollen Relationen komplett aufgeführt werden, wenn sich ihre Geometrie ändert. Andererseits sorgt dies bei den doch häufigen Änderungen an Landesgrenzen für Dateigrößen, die nicht nur für andere Clients schwer beherrschbar sind, sondern auch erhebliche Kapazitäten des Server belegen. Sie sorgen zudem dafür, dass sich nur schwer Zeiträume von mehr als einigen Stunden überbrücken lassen.

Es wird als Ausweg ein Ausblick auf den zukünftigen Full-History-Modus der Overpass API gegeben: Damit können dann Augmented Diffs mit den auf den jeweiligen Anwendungszweck zugeschnittenen Inhalten generiert werden, so dass insbesondere längere Zeiträume für kleine Bounding Boxen schnell erstellt werden können, was wiederum die Änderungsverfolgung drastisch verbessert.

Ich werde realistischerweise höchstens einen Workshop plus einen Vortrag vorbereiten können. Bitte bennent ein Wuschthema für einen Workshop und ein Wunschthema für einen Vortrag. Wie üblich werde ich nicht strikt auszählen, sondern den besten Argumenten folgen wie z.B. inhaltliche Überschneidungen zu ähnlichen Vorträgen zu vermeiden.

[poll id=“3″]

In der ersten Juni-Hälfte hat die Overpass API nicht so zuverlässig wie gewohnt gearbeitet. Mittlerweile konnte die Overpass API wieder zum Normalbetrieb zurückkehren. Wenn ich selbst anderswo solche Ausfälle erlebe, möchte ich eine Erklärung haben. Daher im Folgenden ein paar Details zu der Ausfallzeit:

Was ist passiert?

Am letzten Dienstag, 6. Juni, ist die Anzahl der Anfragen von ca. 50.000 – 80.000 pro Tag auf fast 1.000.000 pro Tag angestiegen. Erfreulicherweise hat sich auch die Anzahl unterscheidbarer IP-Adressen von 300 pro Tag auf etwa 6000 erhöht. Allerdings ist der Server mit dieser drastisch angestiegenen Last überfordert – ein Slashdot-Effekt. Fast alle Abfragen wurden mit einer HTML-Seite, dass der Server überlastet ist, beantwortet.

Die neu auflaufenden Abfragen sind alle von der Form xapi?*[amenity=*][bbox=...]. Erfreulicherweise wird eine Kennung des User Agents mitgeschickt, so dass ich die Abfragen der iOS-App „Geomon“ zuordnen kann. Es sieht so aus, als wenn die Timeout-Meldungen keinerlei Effekt auf das Verhalten der App haben.

Unabhängig davon fällt am Freitag aus ungeklärten Gründen die Rambler-Instanz aus: die erste Unregelmäßigkeit ist, dass ein Durchlauf des Compilerwerkzeugs make mit einer nicht reproduzierbaren Fehlermeldung abstürzt. Danach gibt es Konsistenzehler bei der Area-Erzeugung, ebenfalls nicht reproduzierbar. Einige Stunden später gelingt es mir nicht mehr, mich per ssh einzuloggen, und der Webserver zeigt nicht einmal mehr die statische Website. Im Gesamtbild spricht fast alles für einen Hardware-Schaden. Im Nachhinein stellt es sich als ein Problem mit dem Rambler-internen NFS heraus; mein Home-Verzeichnis liegt nicht physisch auf dem gleichen Server wie der Overpass-Server, so dass dieser mein Home-Verzeichnis nicht mehr lesen konnte. Ich frage einen Reboot an, aber der Server bleibt unerreichbar.

Um die Performance für die meisten Anwendungen zu erhalten, auch wenn die Benutzerzahl von Geomon die aller anderen Anwendungen dominiert, habe ich daher zu diesem Zeitpunkt spezifisch die XAPI-Anfragen auf maximal 3 parallele Anfragen gedrosselt, so dass Overpass-QL-basierte Anwendungen weiterhin etwa die gewohnte Leistung erreichen.

Parallel dazu beginne ich für overpass-api.de einen Umzug vom vier Jahre alten Hetzner DS5600 (4 GB RAM, AMD K5600+) auf einen aktuellen Hetzner EX6S (32 GB RAM, Xeon E3-1245). Auf dem neuen Server habe ich diese Grenze auf 10 parallele Anfragen anheben können, so dass jetzt auch 90%-95% der Anfragen im XAPI-Format wieder ausgeführt werden.

Am 14. Juni ist dann das NFS-Problem auf dem Rambler-Server wieder behoben – der zuständige Administrator war nicht im Büro, und die Nachrichten-Weiterleitung hat nicht wie erwartet funktioniert. Jetzt funktioniert auf overpass.osm.rambler.ru wieder alles normal.

Ist overpass-api.de generell überlastet?

Generell muss sich niemand, der weniger als 10.000 Anfragen pro Tag erzeugt, darüber Gedanken machen. Die Leistungsgrenze des alten Servers liegt bei etwa 100.000 Anfragen pro Tag, die des neuen etwa bei 1.000.000 Anfragen pro Tag. Bei Lasttests haben sich auf dem neuen Server bis zu 10.000 Abfragen pro Minute als handhabbar herausgestellt, je nach Größe der Anfragen.

Knapp sind auf dem Server vor allem Festplattenzugriffe, im Englischen, der Server ist „I/O bound“. Die eigentlich gute Performance von Overpass API beruht darauf, Geodaten in Blöcken von 512KB statt einzeln zu lesen. Eine typische Anfrage wird das Lesen von 3-4 Blöcken auslösen, und der Server kann etwa 10 pro Sekunde lesen. Die beobachtete Geschwindigkeit liegt aber deutlich darüber, was dafür spricht, dass sehr viele Blöcke erfreulicherweise statt von der Festplatte aus dem RAM-Cache gelesen werden. Sehen kann man dies am Munin-Diagramm: es werden sogar mehr Daten geschrieben als gelesen.

Nicht knapp ist dagegen die CPU-Zeit. Das Munin-Diagramm zeigt uns, dass die Prozessoren ganz erheblich Zeit für die Area-Aktualisierung verwenden können und zu noch mehr Anteilen unbeschäftigt sind, was der gezeigte, orange bzw. gelbe Nice-Anteil ist.

Die eigentliche Schwierigkeit liegt jedoch darin, dass Anfragen schubweise kommen, zum Teil bis zu 5000 pro Minute. Für statische Webseiten wäre dies nicht viel, für Datenbankabfragen ist es allerdings sehr viel. Während solcher Schübe ist es unter Umständen nicht möglich, alle Abfragen zu bearbeiten, während dies im Normalbetrieb gewährleistet ist.

In der Vergangenheit hat es auch andere problematische Nutzungsmuster gegeben: allen voran ein offenbar auf Seiten des Client abgebrochener Download größerer Teile des Planeten, der vom Server weiterverfolgt, aber vom Client mehrfach erneut versucht worden ist.

Welche Maßnahmen bestehen?

Generell ist Overpass QL von vorneherein für die Ressourcen-Steuerung ausgelegt. Dazu wird für jede Abfrage zunächst der RAM-Bedarf und die Laufzeit geschätzt. Dies kann entweder explizit der Nutzer mit den entsprechenden Direktiven tun, oder der Server nimmt Default-Werte von 180 Sekunden und 512MB RAM an.

Überschreitet eine Anfrage den RAM-Bedarf oder ihre geschätzte Laufzeit, wird sie abgebrochen. Dies stellt sicher, dass große Abfragen von den Nutzern auch als große Anfragen gekennzeichnet werden. Umgekehrt entscheidet der Interpreter vor der Ausführung der Anfrage, ob noch genug Ressourcen für die Ausführung zur Verfügung stehen. Dies stellt sicher, dass zumindest nicht einzelne große Anfragen den Server blockieren können.

Overpass QL ist zudem defensiv entworfen: eine aufwendige Abfrage hat auch einen langen und umständlichen Quelltext, so dass nur sehr selten versehentlich große Anfragen gestellt werden.

Warum ist speziell XAPI problematisch?

Im Gegensatz zu Overpass QL ist XAPI dafür konzipiert, Resourcen-Grenzen vor dem Benutzer zu verbergen. Das führt dann dazu, dass ausgerechnet die einfachsten Abfragen wie „xapi?*[highway]“ viel zu große Ergebnisse sowohl für den Server als auch für den Client liefern.

Tatsächlich ist dieser Konflikt zwischen Konzept und Realität die Haupt-Antriebsfeder gewesen, anstelle von XAPI eine imperative Skriptsprache zu konzipieren.

Welche Maßnahmen bestehen nicht und warum?

Keine Filterung besteht nach IP, User Agent oder ähnlichem.

Scraping von einer einzelnen IP-Adresse in solchem Umfang, dass es den Server blockiert, habe ich noch nicht beobachtet. Auf der anderen Seite gibt es Implementierungen, die für die Overpass-API-Daten als Proxy agieren. Dann sehe ich von vielen Nutzer-IP-Adressen nur eine Proxy-IP-Adresse, was dann fälschlicherweise nach einem Scraper aussieht.

Ein ähnliches Problem stellt sich bei den User Agents: Fast alle Browser, einschließlich einiger Internet-Explorer-Versionen, beginnen den User-Agent mit „Mozilla“. Browser-Mash-Ups sind aber erwünschte Nutzer. Es ist sogar noch schlimmer: würden einzelne Browser als User-Agents blockiert, sieht ein Website-Entwickler nicht reproduzierbare Unterschiede zwischen verschiedenen Browsern oder Versionen, für die man üblicherweise in den Browsern und nicht bei einem Datenlieferanten nach den Ursachen suchen würde.

Wie geht es weiter?

Auch in Zukunft wird der Server auf hohe Last einer populär werdenden Anwendung nur mit Überlast-Meldungen reagieren können. Es gibt nach dem Umzug durchaus erhebliche Reserven für den Normalbetrieb, aber mehr als eine Zehnerpotenz Lastreserve lässt sich nicht sinnvoll vorhalten.

Anders ausgedrückt: bei einem öffentlichen, kostenlosen Server sollte niemand erwarten, dass der Server jederzeit problemlos funktioniert, eben weil andere Nutzer den Service überlasten könnten. Wer Zuverlässigkeit garantieren möchte, sollte eine eigene Instanz betreiben – dafür ist die Software Open Source und leicht zu installieren.

Für mich selbst habe ich den Anspruch, Störungen in weniger als 24 Stunden zu beheben, so dass auch weiterhin Projekte ohne Geld für einen Server trotzdem Zugriff auf ein leistungsfähiges Backend für OSM-Daten bekommen können.

In diesem Sinne möchte ich mit der guten Meldung schließen, dass dank dem Lastproblem die Software durch neue Optimierungen jetzt zum Teil erheblich schneller antworten kann. Das „Geomon“-Team ist mittlerweile auf einen eigenen Server umgezogen, so dass nun größere Server-Power mit effizienterer Software für die gleichen Nutzerzahlen auf Overpass API zur Verfügung steht.

Ein einzelnes Objekt (Knoten, Weg oder Relation) in OSM lässt sich zwar über seine ID identifizieren, aber diese ID kann kurzlebiger als das Objekt sein. Ein Beispiel dafür sind im Wiki Links der Form http://www.openstreetmap.org/browse/relation/23092.

Aktuell erhalten viele Objekte im Rahmen des Lizenzwechsels eine andere ID. Aber auch das Aufspalten eines Weges in zwei Teilwege führt dazu, dass die eine Hälfte nicht mehr über die alte ID auffindbar ist.

Mit Hilfe der Overpass API können in OpenStreetMap jetzt auch semantische, permanente Links gesetzt werden. Aus einem Link wie oben wird dann ein Link auf die Relation, die das Tag „ref“ mit dem Wert „A 555“ und das Tag „network“ mit dem Wert „BAB“ hat:
http://overpass-api.de/api/interpreter?data=[out:custom];rel[ref=“A 555″][network=BAB];out;
Ein solcher Link ist nun tatsächlich gültig, so lange das beschriebene Objekt existiert, egal mit welcher ID. Gibt es genau eine Relation mit diesen Eigenschaften, wird auf die entsprechende Seite http://www.openstreetmap.org/browse/relation/23092 weitergeleitet. Gibt es mehr als eine Relation oder keine Relation, wird eine Auswahlseite angezeigt.

Ein Beispiel für das Verlinken befindet sich auf der Seite WSW_mobil#CityExpress. Die Links dort sind mit dem Template Template:PTRoute erzeugt. Die Identifikation der gesuchten Relationen erfolgt hier über die beiden Tags _network_ und _ref_. Dabei erfüllen die Templates nun auch eine wichtige semantische Aufgabe: Sie drücken aus, welche Tags für eine bestimmte Kategorie von Objekten (z.B. Autobahnen oder Buslinien) sinntragend sind.

Dabei lässt sich auch das Linkziel und das Aussehen der Suchergebnisseite frei einstellen. Ebenso lassen sich auch geographische Begrenzungen zur Identifikation des Objekts verwenden. Details hierzu sind auf der Wikiseite Overpass_API/Permanent_ID (in Englisch) erläutert.

Damit können tote Links im Wiki mit einmaligem Ändern durch dauerhaft aktuelle ersetzt werden.

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.