Handbuch zur Overpass API

Räumliche Datenauswahl
Objekte Finden
Objekte Zählen
Daten Analysieren
Anhang

Datenformate

Es gibt verschiedene Datenformate, um OpenStreetMap-Daten zu transportieren. Wir stellen alle vor, die einen unmittelbaren Anwendungszweck haben.

Abgrenzung

Die Datentypen sind bereits im passenden Abschnitt der Einleitung eingeführt worden. Sie sollten hier also bereits mit Nodes, Ways und Relations vertraut sein.

Dieser Abschnitt erläutert zum einen Ausgabeformate. Zum anderen werden die verschiedenen möglichen Detailgrade vorgestellt. Welches Tool welches Ausgabeformat benötigt ist jeweils im Abschnitt zum Tool erläutert.

Dem häufigen Problem, die Geometrie von OpenStreetMap-Objekten zu Vervollständigen, ist der Abschnitt zu Geometrien im Kapitel Räumliche Datenauswahl gewidmet.

Traditionelle Detailgrade

Zunächst zu den Detailgraden: Während die Ausgabeformate über eine pro Abfrage globale Einstellung gesteuert werden, werden die Detailgrade bei jedem Ausgabe-Kommando über dessen Parameter gesteuert. Dadurch ist es möglich, verschiedene Dateigrade in einer Anfrage zu mischen; diese Fähigkeit wird für die jeweils optimale Datenmenge einiger Geometrievarianten benötigt. Bei den Anwendungen ist dies jeweils vermerkt.

Wir geben zu den Detailgraden jeweils auch ein Beispiel rund um den Londoner Vorort Greenwich. Das Beispiel ist dabei hauptsächlich so gewählt, dass es nur überschaubar wenige Nodes, Ways und Relations liefert, damit man sich die Daten gut im Tab Daten von OVerpass Turbo anschauen kann.

Für die originalen OpenStreetMap-Detailgrade gibt es eine Hierarchie sie zuzuschalten:

Das Kommando out ids liefert:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out ids;

Das Kommando out skel liefert zusätzlich die nötigen Informationen, um die Geometrie aufzubauen:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out skel;

Das Kommando out (ohne Zusätze) liefert die vollständen Geodaten, also zusätzlich:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out;

Das Kommando out meta liefert zusätzlich:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out meta;

Schlussendlich liefert das Kommando out attribution die folgenden Daten mit:

Dieser letzte Detailgrad betrifft allerdings Daten, die nach herrschender Meinung unter den Datenschutz fallen. Daher ist dafür ein erhöhter Aufwand nötig. Da diese Daten für keines der in diesem Kapitel diskutierten Anwendungen erforderlich sind, verzichten wir hier auf ein Beispiel.

Varianten

Es ist möglich, drei Detailgrade an zusätzlicher Geometrie zuzuschalten. Alle Kombinationen zwischen den gerade vorgestellten Detailgraden und den zusätzlichen Geometrie-Detailgraden sind möglich.

Das Flag center schaltet pro Objekt eine einzelne Koordinate zu. Diese hat keine besondere mathematische Bedeutung, sondern liegt einfach in der Mitte der das Objekt einschließenden Bounding-Box: Beispiel 1

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out ids center;

Beispiel 2

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out center;

Das Flag bb (für Bounding-Box) schaltet pro Objekt die einschließende Bounding-Box zu: Beispiel

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out ids bb;

Das Flag geom (für Geometrie) ergänzt die vollen Koordinaten. Dafür ist als Mindest-Detailgrad die Stufe skel notwendig, es funktioniert also bis einschließlich attribution: Beispiel

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out skel geom;

Wir haben jetzt allerdings jetzt nicht nur einige hundert Meter in einem Park von Greenwich sondern auch mehrere hundert Kilometer Fußweg im Osten Englands zurückerhalten. Dies ist ein generelles Problem von Relations. Als Abhilfe gibt es eine Bounding-Box auch für das Ausgabe-Kommando, siehe dort.

Zuletzt gibt es noch das Ausgabeformat tags. Dieses basiert auf ids und zeigt zusätzlich Tags, aber keine Geometrien oder Strukturen an. Es ist vor allem nützlich, wenn man die Koordinaten im Ergebnis nicht braucht:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out tags;

Es ist aber auch mit den beiden Geometriestufen center und bb kombinierbar:

( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out tags center;

JSON und GeoJSON

Nun zu den Datenformaten: Während die Detailgrade pro Ausgabe-Kommando gewählt werden können, wird das Ausgabeformat nur einmal global pro Abfrage festgelegt. Zudem ändert die Wahl des Ausgabeformats zwar die Form, aber nicht den Inhalt.

Innerhalb von JSON gilt es damit, einen Spagat zu überbrücken. Einerseits gibt es ein durchaus verbreitetes Format für Geodaten, sogenanntes GeoJSON. Andererseits sollen die OpenStreetMap-Daten ja ihre Struktur behalten, und diese passt nicht zu den Vorgaben von GeoJSON.

Als Lösung gibt es die Möglichkeit, GeoJSON-konforme Objekte aus den OpenStreetMap-Objekten zu erzeugen. Die originalen OpenStreetMap-Objekte werden jedoch originalgetreu in JSON abgebildet und sind kein GeoJSON.

OpenStreetMap-Objekte in JSON:

[out:json];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out geom;

Abgeleitete Objekte in GeoJSON:

[out:json];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
convert item ::=::,::geom=geom(),_osm_type=type();
out geom;

Die Erzeugung abgeleiteter Objekte ist ein großer Themenkomplex mit eigenem Kapitel.

CSV

Oft ist es nützlich, Daten in Tabellenform organisieren zu können. Für OpenStreetMap-Daten bedeutet dies vom Nutzer ausgewählte Spalten und eine Zeile je gefundenes Objekt.

Die Auswahl der Spalten schränkt dabei für die meisten Objekte die über das Objekt verfügbare Information wieder ein. Z.B. werden nicht als Spalte angeforderte Tags nicht ausgegeben. Komplexere Geometrien als eine einfache Koordinate können ebenfalls nicht in diesem Format abgebildet werden. Dies unterscheidet dieses Format von XML und JSON.

Der Standardfall einer Spalte ist der Key eines Tags. Es wird dann zu jedem Objekt der Wert dieses Tags am Objekt ausgegeben. Hat das Objekt das Tag nicht, so wird ein leerer Wert ausgegeben. Für die weiteren Eigenschaften des Objekts gibt es spezielle Werte, die mit :: beginnen. Beispiel

[out:csv(::type,::id,name)];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out center;

CSV selbst stand ursprünglich für comma seaprated value. Allerdings haben die zahlreichen nutzenden Programme unterschiedliche Erwartungen an Trennzeichen entwickelt. Daher lässt sich sowohl das Trennzeichen konfigurieren als auch die Überschrift ein- und ausschalten:

[out:csv(::type,::id,name;false;"|")];
( way(51.477,-0.001,51.478,0.001)[name="Blackheath Avenue"];
  node(w);
  relation(51.477,-0.001,51.478,0.001); );
out center;

Bei den jeweiligen Anwendungen ist vermerkt, welche Variante sich eignet.


weiter: Overpass Turbo