DE:Overpass API/Language Guide

Overpass API · Referenz der Sprache · Leitfaden der Sprache · Technical terms · Bereiche · Beispielabfragen · Sparse Editing · Permanent ID · FAQ · mehr (Deutsch) · Web site
Servers status · Versions · Development · Technical design · Installation · XAPI compatibility layer · Public transport sketch lines · Anwendungen · Source code and issues

Overpass turbo · Wizard · Overpass turbo shortcuts · MapCSS stylesheets · Export to GeoJSON · mehr (Deutsch) · Development · Source code and issues · Web site

Overpass Ultra · Examples · Overpass Ultra extensions · MapLibre stylesheets · URL Params · mehr (Deutsch) · Source code and issues · Web site

Dieser Artikel ist eine deutsche Übersetzung des Originals (in der Regel auf Englisch), aber der Inhalt scheint unvollständig oder nicht aktuell zu sein! Bitte aktualisiere diese Übersetzung, wenn möglich.

Hintergrund und Grundidee

Die Overpass API erlaubt es, gezielt OSM-Daten nach eigenen Kriterien zu finden. Dafür steht eine eigens entworfene Abfragesprache bereit.

Der grundlegenden Aufbau der Overpass API ist, dass Auflistungen von OSM-Daten (nodes, ways...) durch nacheinander ausgeführte Befehle generiert und modifiziert werden. Als Beispiel listet die folgende einfache Abfrage alle nodes in einer bestimmten bounding box (Begrenzungsrahmen) auf und gibt das Ergebnis dann aus:

node(50.745,7.17,50.75,7.18);out;

Du kannst in einem nächsten Schritt diese Auflistung filtern, indem du zum Beispiel nur nach Bushaltestellen (highway=bus_stop) suchst:

node(50.745,7.17,50.75,7.18)[highway=bus_stop];out;

Alternativ kannst du die Suche erweitern, indem du die ways einschließt, die die Nodes benutzen. Vielleicht willst du, wie im folgenden Beispiel, zusätzlich auch alle Nodes dieser ways ausgegeben bekommen:

node(50.745,7.17,50.75,7.18);
way(bn);
(._;>;);
out;

Diese Ausdrücke und ihre Syntax sind im folgenden detailliert beschrieben.

Die Overpass-API-Sprache

Auf alle Funktionen der Overpass API kann über eine einfache HTTP-GET-Anfrage zugegriffen werden. Um das zu erreichen, wurde die neue Abfragesprache Overpass QL parallel zur etablierten XML-Abfragesprache eingeführt. Du kannst immer zwischen beiden Formen übersetzen: Dazu einfach eines der folgenden Beispiele in http://overpass-api.de/convert_form.html kopieren. Dort kannst du das Ausgabeformat auswählen als

• XML query format: Das ist identisch mit allen XML-Ausdrücken im folgenden.
• pretty Overpass QL: Das ist identisch mit den Overpass QL-Ausdrücken im folgenden
• to concise Overpass QL: Das ergibt eine einzeilige HTTP-GET-Anfrage für den selben Ausdruck.

Um eine Abfrage auszuführen, verwende stattdessen bitte http://overpass-api.de/query_form.html.

Grundwissen Overpass QL

Du hast schon einige Beispiele für die QL-Syntax gesehen. Die QL-Syntax basiert auf der Syntax von C. Ein Befehl endet immer mit einem Semikolon ;.

Es gibt drei Arten von Befehlen:

• Ein Befehl ist entweder ein Abfragebefehl, dann fängt er mit "node" (Punkt), "way" (Weg), "rel" (Rel.) oder "relation" (Relation) ("rel" ist nur eine Kurzschreibweise für "relation") an.
• oder es ist einer der speziellen Befehle ">", ">>", "<", oder "<<".
• oder der Befehl ist ein Ausgabebefehl, dann fängt er mit "out" (Ausgabe) an.

Abfrageanweisungen bestehen aus dem Typ des abzufragenden Objekts

• node
• way
• rel

und mindestens einer Bedingung. Es gibt verschiedene Arten, wie eine Bedingung aussehen kann.

Bedingungen in Overpass QL

Es gibt verschiedene Arten von Bedingungen, die Sie verwenden können:

• zum Filtern von Objekten (Knoten, Wege, Beziehungen oder Overpass-Bereiche), die in der Eingabeergebnismenge vorhanden sind, oder
• um Rekursionsabfragen auf ihnen durchzuführen, um sie alle durch die Vereinigung aller mit ihnen rekursiv verbundenen Objekte zu ersetzen.

Alle Overpass-QL-Sprachelemente für Filter (oder Rekursionsabfragen) können nur nach Angabe eines Hauptabfragetyps (oder .resultset) verwendet werden, sie sind keine Abfragen an sich.

Tag-Anfrage (oder "tag-Filter")

Alle Arten von tag-Anfragen. z. B.:

  ["key"]            /* filtert Objekte, die mit diesem Schlüssel und einem beliebigen Wert gekennzeichnet sind */
  [!"key"]           /* filtert Objekte, die nicht mit diesem Schlüssel und einem beliebigen Wert gekennzeichnet sind */
  ["key"="value"]    /* filtert Objekte, die mit diesem Schlüssel und diesem Wert gekennzeichnet sind */
  ["key"!="value"]   /* filtert Objekte, die mit diesem Schlüssel, aber nicht mit diesem Wert gekennzeichnet sind, oder die nicht mit diesem Schlüssel gekennzeichnet sind */
  ["key"~"value"]    /* filtert Objekte mit diesem Schlüssel und einem Wert, der einem regulären Ausdruck entspricht */
  ["key"!~"value"]   /* filtert Objekte mit diesem Schlüssel, aber einem Wert, der nicht mit einem regulären Ausdruck übereinstimmt */
  [~"key"~"value"]   /* filtert Objekte, die mit einem Schlüssel und einem Wert versehen sind, die regulären Ausdrücken entsprechen */
  [~"key"~"value",i] /* filtert Objekte, die mit einem Schlüssel und einem Wert ohne Berücksichtigung der Groß-/Kleinschreibung versehen sind, die regulären Ausdrücken entsprechen */

Bounding-box- (Grenzkasten-) Anfragen

Bounding-Box-Anfragen können (wie alle anderen Anfragen für Filter oder Rekursionsabfragen) nur als Filter nach der Angabe eines Hauptabfragetyps (oder .resultset) verwendet werden; sie sind keine Abfragen an sich. In der Syntax von Overpass QL haben sie eine Form wie in diesem Beispiel:

/*Deine Abfrage */  (51.0,7.0,52.0,8.0)

Beschränkungen des Gebietes beginnen immer mit dem niedrigsten Breitengrad (ganz im Süden), gefolgt vom niedrigsten Längengrad (ganz im Westen), dann dem höchsten Breitengrad (ganz im Norden) und dem höchsten Längengrad (ganz im Osten). Bitte beachte, dass die XAPI-Syntax anders ist. Der XML-Syntax ist die Reihenfolge egal, da sie die Zahlen benennt.

Die Overpass-XML-Syntax wird durch die Verwendung von (expliziteren) benannten Parametern geschützt (beachten Sie jedoch, dass ihr Name immer noch irreführend sein kann, da sie weiterhin negative Werte für alle absoluten Koordinaten in der südlichen oder westlichen Hemisphäre und positive Werte für alle absoluten Koordinaten in der nördlichen oder östlichen Hemisphäre annehmen).

  <query><!-- durch einen effektiven Abfragetyp ersetzen; wenn dieses Element fehlt, wird ein Standard <query type="node"> angenommen -->
    <bbox-query s="51.0" w="7.0" n="52.0" e="8.0"/>
  </query><!-- durch einen effektiven Abfragetyp ersetzen -->

Eine "bounding box" (Grenzkasten), die sich durch den Antimeridian erstreckt (der sonst die beiden Längengrade vertauschen würde), entspricht einer Vereinigung von zwei Unterabfragen für jede Seite des Antimeridians. Das lange Band, das den vorherigen Grenzkasten über dieselbe Spanne von Breitengraden ergänzt, entspricht zum Beispiel dieser Vereinigung von Abfragen auf zwei Grenzkästen. Da dies ein sehr großer Bereich ist, der zu viele Daten abdeckt, wird diese Abfrage wahrscheinlich fehlschlagen, es sei denn, die Hauptabfragen enthalten selektivere Filter wie Tag-Filter:

  (
    /*Deine Abfrage*/(51.0,  7.0, 52.0, 180); /* Westseite des Antimeridian (bis zum positiven Längengrad 180°E) */
    /*Deine Abfrage*/(51.0, -180, 52.0, 8.0); /* Ostseite des Antimeridian (vom negativen Längengrad 180°W) */
  );

Beachten Sie, dass Sie hier in jeder Unterabfrage dieselbe Hauptabfrage angeben müssen. Mindestens jedoch "node", "way", "rel", "area" oder ein ".namedresultset", optional gefolgt von anderen Filtern oder Rekursionen. Derzeit bietet die Overpass-API keine Möglichkeit, diese Umwandlung automatisch vorzunehmen, wenn Sie die Längengrade vertauschen. Stattdessen gibt die Overpass-API einen Fehler zurück, falls der erste angegebene Längengrad größer ist als der zweite Längengrad.

Und es ist immer noch nicht möglich, einen einzelnen zusammengesetzten Filter zu erstellen, der eine Vereinigung von Grenzkästen enthält (oder andere polygonale Formen, die auf einer geordneten Liste von Koordinatenpaaren basieren, oder andere Scheibenformen, die auf den Koordinaten eines zentralen Knotens und einem maximalen Radius basieren, oder Ausschlüsse, die auf einer Subtraktion von zwei einfachen oder zusammengesetzten Formen basieren). Außerdem bietet die Overpass-API keine Möglichkeit, solche einfachen oder zusammengesetzten Formen mit Hilfe von positiven oder negativen Puffern geometrisch zu transformieren, um komplexere Begrenzungsfilter zu verwenden. Die Abfragen müssen mit verschiedenen vorverformten einfachen Formen wiederholt werden. Weitere Einzelheiten finden Sie in den folgenden Abschnitten zu den unterstützten Abfrageverknüpfungen und zu (around: ...) oder (poly: "...") speziellen Filtern für andere Arten von einfachen Begrenzungsformen.

Gebietsabfragen ("area filters")

Die "Area"-Objekte sind nicht direkt OSM-Objekte, sondern werden von einem Batch generiert und auf dem Overpass-API-Server zwischengespeichert, der in regelmäßigen Abständen auf diesem Server läuft, um alle neuen oder geänderten Datenänderungen in der Datenbank zu verarbeiten und nach Nicht-Knoten-Objekten zu suchen, die eine umschlossene Fläche beschreiben; zu diesen Objekten gehören geschlossene Wege oder Relationen (insbesondere "Boundary"- und "Multipolygon"-Relationen), deren Mitglieder einen oder mehrere Wege umfassen, die miteinander verbunden sind, um geschlossene "innere" oder "äußere" Ringe zu bilden, die eine Fläche abgrenzen. Overpass verarbeitet diese Objekte, um ihre Geometrie zu extrahieren (und sie im Falle von Relationen entsprechend neu zu verbinden und zu ordnen), und zwar als eine Reihe von polygonalen Begrenzungen. Der Overpass-API-Server speichert dann die berechnete Geometrie und ordnet sie über die ID dem OSM-Weg oder dem Relation-Objekt zu, indem er ihre Tags auflistet; der Stapel erkennt auch einige Benennungs-Tags, die nützlich sind, um sie leichter zu identifizieren.

Overpass-"areas" sind nützlich, um explizite Rekursionsabfragen zu vermeiden, und auch als vorberechnete Filter, die keine Relationen und Wege zurückgeben, die in Wirklichkeit keinen Bereich umschließen. Da sie jedoch in regelmäßigen Abständen generiert werden, spiegeln sie möglicherweise nicht den aktuellsten Stand der OSM-Datenbank wider oder sogar nicht alle aktuellen Diffs, die bereits empfangen und auf dem Overpass-API-Server gespeichert wurden. Sie können jedoch die Abfragen erheblich vereinfachen und beschleunigen, insbesondere bei großen Flächen mit komplexen Geometrien, die in der Regel "Boundary"- oder "Multipolygon"-Relationen verwenden. Darunter fallen z. B. die Grenzen von Ländern oder deren regionalen Unterteilungen oder die komplexen Grenzen großer "Landnutzungs-" oder "Natur"-Gebiete.

Diese Gebiete können dann als selektivere Begrenzungsfilter anstelle von einfachen Begrenzungsrahmen oder auch selbst als Abfragen verwendet werden. In diesem Fall werden alle Knoten in der von der Gebietsgeometrie eingeschlossenen Fläche zurückgegeben.

Wenn Flächen durch ihre interne ID in Overpass referenziert werden (und diese Fläche eingeschlossen wurde), werden alle in der Eingabemenge vorhandenen Flächen ignoriert und nur die OSM-Objekte in der Eingabemenge, die sich mit der angegebenen Fläche schneiden, werden unverändert beibehalten:

 (area:2400000001) /* Objekte in Bereichen filtern, deren Fläche durch den Weg begrenzt ist mit  id=1 in OSM */
  (area:3600000001) /* Objekte in Bereich filtern, dessen Fläche durch Wegeglieder der Beziehung mit id=1 in OSM */

Derzeit werden die IDs für vorberechnete Überführungsbereiche einfach durch Hinzufügen großer statischer Konstanten zur OSM-ID zugewiesen, dies unter der Annahme, dass die zugehörigen OSM-Objekte tatsächlich einen Bereich umschließen.

Bereiche (areas) nach Namen auswählen

In der Regel werden Gebiete jedoch ausgewählt, indem eine gesonderte Abfrage, welche vom Overpass Turbo-Client unterstützt wird, nach den bekannten Benennungs-Tags für das OSM-Objekt, das sie darstellen, durchgeführt wird. (Nominatim wird verwendet, um verschiedene Benennungs-Tags zu verarbeiten, zu erkennen und zu indizieren, einschließlich Tags für übersetzte Namen die gefundenen Gebiete in einer benannten Ergebnismenge speichern: Jedes übereinstimmende Gebiet mit relevanten Tags wird in dieser benannten Ergebnismenge gespeichert:

{{geocodeArea:"United Kingdom"}}->.a; /* finde ein area mit dem tag "name"="United Kingdom" */
  {{geocodeArea:"GB"}}->.a;             /* finde ein area mit dem tag "ISO3166-1"="GB" */

Beachten Sie, dass die obigen "geocodeArea"-Abfragen, in der Ergebnismenge "a", nur Overpass-Gebiete zurückgeben, die dem angegebenen Namen entsprechen, aber keine OSM-Objekte wie z. B. Knoten, Wege oder Beziehungen. Es werden nicht alle möglichen Gebiete durch solche Abfragen zurückgegeben, sondern nur das erste passende: dies geschieht durch die Verwendung einer Overpass Turbo-Syntax-Erweiterung, die es ermöglicht, eine Suche nach Namen, unter Verwendung von Nominatim, durchzuführen und dann das zurückgegebene Objekt in eine passende Overpass-Gebiets-ID zu konvertieren. Diese Abfragen funktionieren nicht direkt auf einfachen Overpass-API-Servern, und Sie müssen die konstante Gebietskennung selbst angeben. Ohne die Overpass-Turbo-Erweiterung zu verwenden (die eingeschränkter ist und möglicherweise nicht das erwartete Gebiet zurückgibt), können Sie immer noch das Overpass-API-Konstrukt verwenden, um dasselbe zu erhalten (aber ohne auf nur ein Gebiet in der Ergebnismenge beschränkt zu sein, und mit mehr Möglichkeiten, das ausgewählte Vereinigungsgebiet nach expliziten Tags zu filtern):

  ( area[name="United Kingdom"]; )->.a;  /* oder mehr selektiv: */
  ( area["ISO3166-1"="GB"][admin_level=2]; )->.a;

Dann kann diese benannte Ergebnismenge verwendet werden, um Objekte nach Schnittpunkten mit diesem Bereich zu filtern. Mit der folgenden Filterklausel werden nur Objekte aus der aktuellen Ergebnismenge beibehalten, die sich mit einem beliebigen Bereich in der benannten Ergebnismenge "a" schneiden:

  /*Deine Abfrage*/(area.a)

Beachten Sie, dass dieser Filter alle Objekte (Knoten, Wege, Beziehungen oder Gebiete) in der Hauptabfrage behält, die vollständig in einem Gebiet in "a" enthalten sind oder teilweise von einem von ihnen bedeckt werden, oder alle Objekte in der Abfrage, deren Oberfläche ein Gebiet in "a" vollständig umschließt. Wenn es sich bei dem ausgewählten Gebiet beispielsweise um das Gebiet einer Stadt handelt, gibt der Filter alle lokalen Unterteilungen (Bezirke, Stadtteile) in dieser Stadt, alle natürlichen Merkmale (z. B. Seen) in dieser Stadt und alle Unterteilungen zurück, die diese Stadt einschließen (Knoten, Wege, Beziehungen und Gebiete in der Eingabemenge), es sei denn, Sie verwenden zusätzliche Tag-Filter in der Hauptabfrage, um selektiver vorzugehen. Z. B. ["admin_level"="8"], um nur OSM-Objekte auszuwählen, die diese Stadt repräsentieren; die geschlossenen Objekte für die umliegenden Städte, die ebenfalls mit ["admin_level"="8"] getaggt sind und die nur eine gemeinsame Grenze mit der ausgewählten Stadt haben, werden normalerweise nicht zurückgegeben, da die Fläche ihrer gegenseitigen Überschneidung leer und auf diese gemeinsamen Grenzen beschränkt sein sollte; jedoch werden alle Knoten und Wege zurückgegeben, die in der Eingabemenge enthalten sind und ebenfalls genau auf die Grenze des ausgewählten Gebiets fallen, unabhängig von anderen Beziehungen oder geschlossenen Wegen, in denen sie Mitglieder sein könnten.

Umkehranfragen ("Rekursionsfilter")

Oder man sucht über mehrere Schritte (rekursiv) vorwärts oder rückwärts über vorhandene Verknüpfungen.

  (r)
  (w)
  (n)
  (br)
  (bw)
  (>)
  (>>)
  (<)
  (<<)

Spezialanfragen ("Spezialfilter")

Oder man verwendet spezielle Bedingungen von der Form "(type:value)".

Mehr Informationen dazu findet man in den entsprechenden Abschnitten der Beispiele.

Über die Links

Für die meisten Beispiele liegen Links vor, die das Ergebnis in einer Karte visualisieren. Das ist aber noch in einem experimentellen Stadium. Die Gebietsbeschränkung liegt immer auf der deutschen Stadt Bonn. Außerdem brauchen einige Abfragen recht lange, so sind Zeiten von über einer Minute möglich, wenn keine der benötigten Daten im Cache des Servers liegen. Die Befehle sehen teilweise nicht schön aus, mit einem passenden User-Interface brauchen diese von einem normalen Benutzer aber nicht gesehen zu werden.

Benutzungsbeispiele

Beginnen wir mit einigen Beispielen für Abfragen, indem wir uns die Abfrage nach Gebietsgrenzen (bounding box) ansehen.

Die Gebietsgrenzen

Mit der bbox-Abfrage können Sie alle Knoten, Wege oder Beziehungen aus den angegebenen Gebietsgrenzen herunterladen. Spezifizieren Sie diese mit:

•    s die südliche Grenze in Dezimalgraden (niedrigste geografische Breite, gemessen entlang eines Meridians vom nächstgelegenen Punkt des Äquators aus, negativ in der südlichen Hemisphäre)
•    w die westliche Grenze in Dezimalgraden (niedrigster Längengrad, gemessen entlang eines Breitengrades vom nächstgelegenen Punkt auf dem Meridian von Greenwich, negativ in der westlichen Hemisphäre)
•    n die nördliche Grenze in Dezimalgraden (höchster Breitengrad, gemessen entlang eines Meridians vom nächstgelegenen Punkt auf dem Äquator, positiv in der nördlichen Hemisphäre)
•    e die östliche Grenze in Dezimalgraden (höchster Längengrad, gemessen entlang eines Breitengrades vom nächstgelegenen Punkt auf dem Meridian von Greenwich, positiv in der östlichen Hemisphäre)

Diese Koordinaten werden in der OSM-Datenbank und in der OverPass-API durch vertikale Projektion der realen Punkte auf Knoten auf dem WGS84-Ellipsoid angegeben.

Bitte beachten Sie auch, dass das Overpass-QL-Formular die implizite Reihenfolge (s, w, n, e) hat. Dies ist prägnanter als die explizite XML-Syntax, erfordert aber natürlich eine gewisse Sorgfalt, um die richtige Reihenfolge zu finden. Die westliche Grenze ist nur dann höher als die östliche, wenn Ihre Abfrage den Längengrad ±180,0 Grad mit einem Begrenzungsrahmen überschreitet, der durch den Antemeridian verläuft (in diesem Fall entspricht die Abfrage der Vereinigung zweier Begrenzungsrahmen auf beiden Seiten des Antemeridians.

Für Gebiete, die keine Boxen sind, siehe den Befehl Poly.

Wie man etwas findet

Etwas in den OpenStreetMap-Daten zu finden bedeutet immer, dass man entweder nach einem Ort oder bestimmten Werten in einem Tag suchen muss. Du kannst für die folgenden Beispiele jede beliebigen Zeichenkombination als Wert verwenden. Im ersten Schritt suchen wir Objekte anhand ihres Namens. Deshalb suchen wir Werte für den Schlüssel "name"

Durch exakten Namen

In unserem ersten Beispiel suchen wir nach Punkten(node) mit dem Schlüssel(key) "name" und dem Wert(value) "Gielgen".

Overpass QL:

node["name"="Gielgen"];
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" v="Gielgen"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen: OpenLayers map JSON, XML.

Abrufen aller Knoten innerhalb der Gebietsgrenzen

Wenn die letzte Abfrage nicht genau ist können wir noch einen Bereich(bounding box) angeben, um die Ergebnisse nur von dort zu erhalten. Die Koordinatenreihenfolge ist: "kleinerer Breitengrad","kleinerer Längengrad","größerer Breitengrad","größerer Längengrad". Die Angabe der Zahlen erfolgt mit einem Punkt als Dezimaltrennzeichen. Wenn du spontan keinen Bereich hast kannst du es mal mit dem aus dem nächsten Beispiel versuchen:

Overpass QL:

node
  ["name"="Gielgen"]
  (50.7,7.1,50.8,7.2);
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" v="Gielgen"/>
    <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen:OpenLayers map JSON, XML.

etwas in der Nähe von etwas anderem

Eine etwas weniger technische Methode das gewünschte Ergebnis bei einer großen Auswahlmenge zu bekommen ist es in der Umgebung um ein bekanntes Objekt zu suchen. Du kannst zum Beispiel einen Ort "Gielgen" in einem Radius von 1000 Meter um einen Ort suchen der "Bonn" genannt wird.

Overpass QL:

node["name"="Bonn"];
node
  (around:1000)
  ["name"="Gielgen"];
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" v="Bonn"/>
  </query>
  <query type="node">
    <around radius="1000"/>
    <has-kv k="name" v="Gielgen"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen: OpenLayers map JSON, XML.

Nicht exakte Namen

Sogar, wenn du den exakten Namen nicht kennst kannst du ein Objekt finden. Hierzu erlaubt es die Overpass-API reguläre Ausdrücke zu verwenden. Wir geben einige Beispiele der Verwendung.

Im ersten Beispiel suchen wir für einen Punkt, der "holtorf" im Namen hat:

Overpass QL:

node
  ["name"~"holtorf"]
  (50.7,7.1,50.8,7.25);
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" regv="holtorf"/>
    <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen: OpenLayers map JSON, XML.

Das zweite Beispiel sucht nach Punkten, dessen Namen mit "Holtorf" anfangen:

Overpass QL:

node
  ["name"~"^Holtorf"]
  (50.7,7.1,50.8,7.25);
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" regv="^Holtorf"/>
    <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen: OpenLayers map JSON, XML.

Das dritte Beispiel sucht für Punkte, deren Namen mit "holtorf" enden: Overpass QL:

node
  ["name"~"holtorf$"]
  (50.7,7.1,50.8,7.25);
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" regv="Holtorf$"/>
    <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen: OpenLayers map JSON, XML.

Natürlich könntest du auch nach "^Holtorf$" suchen, das gibt aber die gleiche Ausgabe wie eine einfache Suche nach dem gleichen Wert.

Zusätzlich kann man mit den regulären Ausdrücken auch ohne Beachtung der Groß- und Kleinschreibung suchen. Hierzu muss man beide Varianten in eckige Klammern schreiben: Overpass QL:

node
  ["name"~"[hH]oltorf"]
  (50.7,7.1,50.8,7.25);
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" regv="[hH]oltorf"/>
    <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen: OpenLayers map JSON, XML.

Einen Namen aus einer Auswahl

Wenn du verschiedene Werte erlauben willst kannst du sie Mithilfe des vertikalen Striches "|" trennen. Dieses Zeichen befindet sich auf der Deutschen Tastatur links von der Y-Taste (am Mac: alt+7 unter Verwendung der oberen Zahlenreihe).

Overpass QL:

node
  ["name"~"holtorf|Gielgen"]
  (50.7,7.1,50.8,7.25);
out body;

XML:

<osm-script>
  <query type="node">
    <has-kv k="name" regv="holtorf|Gielgen"/>
    <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
  </query>
  <print/>
</osm-script>

Ergebnis anzeigen: OpenLayers map JSON, XML.

Du kannst mehr Informationen über (POSIX extended) reguläre Ausdrücke in Linux über die Konsole oder die Suche im Internet nach "man 7 regex" erhalten. (Auf Deutsch leider nicht ganz so gut wie auf Englisch)

Verneinungen

Ein regulärer Ausdruck selbst kann nicht verneint werden. Deshalb gibt es in der Overpass QL einen Verneinungs-Operator.

Overpass XML: modv="not"

Overpass QL: ! (bei regulären Ausdrücken), != (bei Wertvergleichen)

Beispielsweise sucht folgende Abfrage nach allen "ways", die keinen Tag "highway" haben:

Overpass XML	Overpass QL
<osm-script> <query type="way"> <has-kv k="highway" modv="not" regv="."/> <bbox-query e="7.18" n="50.75" s="50.74" w="7.17"/> </query> <print limit="" mode="body" order="id"/> </osm-script>	way ["highway"!~"."] (50.74,7.17,50.75,7.18); out body;

Ergebnis anzeigen: OpenLayers map, JSON, XML.

Ein weiteres Beispiel zeigt, wie man die Suche nach Bushaltestellen auf solche einschränken kann, die ein Wartehäuschen haben. Formal wird nach einer Bushaltestelle ("highway"="bus_stop") gesucht, die mit dem Tag "shelter" (Wartehäuschen) markiert ist und der Wert des Tags nicht "no" ist.

Overpass XML	Overpass QL
<osm-script> <query type="node"> <has-kv k="highway" v="bus_stop"/> <has-kv k="shelter"/> <has-kv k="shelter" modv="not" v="no"/> <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/> </query> <print/> </osm-script>	node ["highway"="bus_stop"] ["shelter"] ["shelter"!="no"] (50.7,7.1,50.8,7.25); out body;

Ergebnis anzeigen: OpenLayers map, JSON, XML.

Die gleiche Abfrage mit regulärem Ausdruck:

Overpass XML	Overpass QL
<osm-script> <query type="node"> <has-kv k="highway" v="bus_stop"/> <has-kv k="shelter"/> <has-kv k="shelter" modv="not" regv="no"/> <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/> </query> <print/> </osm-script>	node ["highway"="bus_stop"] ["shelter"] ["shelter"!~"no"] (50.7,7.1,50.8,7.25); out body;

Ergebnis anzeigen: OpenLayers map, JSON, XML.

mehrere Tags

Natürlich kannst du auch Nodes mit mehreren Tags suchen, um wie im Beispiel Bushaltestellen mit Wartehäuschen zu finden. Also solche, die einen Tag "highway" = "bus_stop" und einen Tag "shelter" = "yes" haben:

Overpass XML	Overpass QL
<osm-script> <query type="node"> <has-kv k="highway" v="bus_stop"/> <has-kv k="shelter" v="yes"/> <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/> </query> <print/> </osm-script>	node ["highway"="bus_stop"] ["shelter"="yes"] (50.7,7.1,50.8,7.25); out body;

Ergebnis anzeigen: OpenLayers map, JSON, XML.

Straßen und andere Wege

Jede der oben genannten Abfragen funktioniert auch mit Linien (way) oder Relationen (relation). Wir suchen für die Straße "Gielgenstraße" im bekanntn Kartenrahmen:

Overpass XML	Overpass QL
<osm-script> <query type="way"> <has-kv k="name" v="Gielgenstraße"/> <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/> </query> <print/> </osm-script>	way ["name"="Gielgenstraße"] (50.7,7.1,50.8,7.25); out;

Ergebnis anzeigen: OpenLayers map, JSON, XML.

Damit ein Weg so wie er angelegt wurde, dargestellt werden kann oder du benötigst die Koordinaten aus einem anderen Grund, müssen die Punkte des Weges auch abgefragt werden. Dies wird mit einer speziellen rekursiven Abfrage (extra-recurse down statement) getan. Damit auch die Linie angezeigt wird, setzen wir sie in eine zusammenfassende Abfrage (union statement). Genauer wird dies in den folgenden Abschnitten erklärt.

Overpass XML	Overpass QL
<osm-script> <query type="way"> <has-kv k="name" v="Gielgenstraße"/> <bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/> </query> <union> <item /> <recurse type="way-node"/> </union> <print/> </osm-script>	( way ["name"="Gielgenstraße"] (50.7,7.1,50.8,7.25); >; ); out;

Relationen

Eine Relation befindet sich in einer Bounding Box, wenn eines ihrer Elemente vom Typ Knoten oder Weg innerhalb der Bounding Box ist. Folgende Abfragen geben alle Relationen aus, die ein Element in der Bounding Box (50.746,7.154,50.748,7.157) haben.

Overpass XML	Overpass QL
<osm-script> <query type="relation"> <bbox-query e="7.157" n="50.748" s="50.746" w="7.154"/> </query> <print/> </osm-script>	relation(50.746,7.154,50.748,7.157); out body;

Ergebnisse anzeigen: OpenLayers map, JSON, XML.

Region durch Polygon festlegen

Versuch einer Übersetzung durch Google.
Ergebnis für mich unbrauchbar:

Die "Gebiets" -Objekte sind nicht direkt OSM-Objekte, sie werden von einem Stapel, der regelmäßig auf diesem Server ausgeführt wird, generiert (und auf dem Overpass-API-Server zwischengespeichert), um alle neuen oder geänderten Datenänderungen in der Datenbank zu verarbeiten und nach Nicht-Knotenobjekten zu suchen beschreibt eine geschlossene Oberfläche; diese Objekte schließen geschlossene Wege oder Relationen (insbesondere "Grenz-" und "Multipolygon" -Relationen) ein, deren Glieder eine oder mehrere Arten umfassen, die miteinander verbunden sind, um geschlossene "innere" oder "äußere" Ringe zu bilden, die eine Oberfläche begrenzen. Überführung verarbeitet diese Objekte, um ihre Geometrie zu extrahieren (und sie im Fall von Relationen neu zu verbinden und anzuordnen) als eine Menge polygonaler Grenzen. Der Overpass-API-Server speichert dann die berechnete Geometrie und ordnet sie (nach ID) dem OSM-Weg oder Beziehungsobjekt zu, das ihre Tags auflistet; Der Stapel erkennt auch einige Benennungs-Tags, die hilfreich sind, um sie leichter zu identifizieren.

Übersteuerungsbereiche sind nützlich, um die Verwendung von expliziten Rekursionsabfragen zu vermeiden und auch als vorberechnete Filter, die keine Beziehungen und Wege zurückgeben, die tatsächlich keinen Bereich umschließen. Da sie jedoch von peridischen Batches generiert werden, geben sie möglicherweise nicht den neuesten Stand der OSM-Datenbank wieder (oder sogar alle neuesten Diffs, die bereits auf dem Overpass-API-Server empfangen und gespeichert wurden). Aber sie können die Abfragen erheblich vereinfachen und beschleunigen, insbesondere bei großen Flächen mit komplexen Geometrien, die gewöhnlich "Grenz-" oder "Multipolygon" -Relationen verwenden (wie etwa die Grenzen von Ländern oder ihren regionalen Unterteilungen oder die komplexen Grenzen von großen "Landnutzungen" oder " natürliche "Gebiete".

Diese Bereiche können dann als selektivere Begrenzungsfilter verwendet werden (anstatt einfache Begrenzungsrahmen zu verwenden) oder können auch selbst als Abfragen verwendet werden (in diesem Fall geben sie alle Knoten in der von der Bereichsgeometrie eingeschlossenen Fläche zurück).

Wenn Bereiche durch ihre interne ID in Overpassage referenziert werden (und dieser Bereich wurde eingeschlossen, werden alle in der Eingabemenge vorhandenen Bereiche ignoriert und nur OSM-Objekte in der Eingabesatzgruppe, die sich mit dem angegebenen Bereich schneiden, werden beibehalten.)

  (area: 2400000001) / * Objekte in einem Bereich filtern, dessen Oberfläche durch den Weg mit id = 1 in OSM * /
  (area: 3600000001) / * filtert Objekte in einem Bereich, dessen Oberfläche durch Wegglieder der Beziehung mit id = 1 in OSM * /

Die IDs für vorberechnete Überführungsbereiche werden derzeit zugewiesen, indem der OSM-ID einfach große statische Konstanten hinzugefügt werden (vorausgesetzt, die zugehörigen OSM-Objekte schließen effektiv eine Fläche ein).

Editieren der gefundenen Daten

Diese Anleitung ist inzwischen unter der eigenen Seite für Sparse Editing zu finden.

Sprachhinweise

dafür wurde eine eigene Seite angelegt language reference.

FAQ

auch hier wurde eine eigene Seite angelegt Overpass_API/FAQ#Languages_and_syntax