Overpass API Version 51 mit holprigem Start

Von der Overpass API gibt es endlich wieder eine neue Version. Mit drei Monaten Abstand bin ich diesmal nicht ganz so weit hinterher wie bei der letzten Version. Dafür gibt es auch keine so epochalen Änderungen. Wenn nichts dazwischenkommt, wird es die nächste Version zum Jahresende geben. Zu den etwas unglücklichen Umständen der Inbetriebnahme werde ich mich am Ende äußern.

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.

Roland

Roland mappt unter Roland.olbricht und hat seinen Schwerpunkt auf die Entwicklung der OSM-Infrastruktur gelegt. Beruflich ist er am Fraunhofer-Institut SCAI in St. Augustin bei Bonn als Software-Entwickler (ohne Bezug zu OSM) tätig.

Kategorie: Aus dem Maschinenraum, Gastblog

  1. Peter

    Sag mal plant Ihr auch ne alternative Anfragesprache, die einfacher ist? Also sowas wie eine einfache Version der JSON-Anfrage von ElasticSearch?

    • Roland

      Danke für die Idee. Allerdings kann Nominatim bereits eine ausgereifte Volltextsuche. Daher ist keine dritte “einfachere” Abfragespache für diesen Anwendungsfall geplant.

      Ich werde aber an einer besseren Dokumentation, auch auf Deutsch, arbeiten. Diese vereinfacht hoffentlich den Zugang zur Abfragesprache.

  2. Tobias

    Danke für die Arbeit, Roland. Danke Mmd für das neue Feature. Gibt es eigentlich noch mehr EntwicklerInnen, die sich beteiligen? Was passiert, wenn Roland irgendwann nicht mehr will oder kann?

    • Roland

      Weitere Entwickler gibt es leider nicht. Unterstüzung können wir gerne gebrauchen. Folgt mmds gutem Beispiel! Um die Zugänglichkeit zu verbessern, werde ich den Quellcode so umbauen, dass er besser verständlich wird.

      Wenn ich morgen “unters Auto komme” oder OSM den Rücken kehre, steht der Quellcode nach wie vor unter AGPL zur weiteren Verwendung zur Verfügung. Auch der Server wird genau deswegen von der FOSSGIS betrieben.