Talk:Overpass API/OverpassQL

Use Cases

• map: alle Daten innerhalb einer BBox.

Möglich. Es ist nicht so ganz klar, ob bei Relationen auch die referenzierten Elemente dazugehören sollen, aber beide Varianten lassen sich umsetzen.

• Liste aller Atomkraftwerke

Ist beim ersten Versuch daran gescheitert, dass ich kein klares Tagging gefunden habe. power=generator scheint ein Ansatz zu sein, liefert aber alle Kraftwerksarten.

node["generator:source"="nuclear"]{xml;}

liefert immerhin zur Zeit 146 Fundstellen, aber das sind vermutlich nicht alle.

Der Teil mit dem {xml;} erscheint mir unlogisch. Ist das Rückgabeformat nicht immer xml?

Nein, das Rückgabeformat kann verschieden sein. JSON und die Variante JSONP sind gerade im Betatest. Allerdings sollte einmal zentral pro Ausgabe entschieden werden. Daher habe ich "{xml;}" jetzt durch "{out;}" ersetzt.

Das geht gar nicht. Hier wäre es doch viel besser GET Parameter zu verwenden. Also z.b.

http://www.overpass-api.de/api/xml/

http://www.overpass-api.de/api/json/

Solche URLs gehen nicht so ohne weiteres. Grund dafür ist, dass der Webserver noch erkennen muss, dass es sich um Skriptaufrufe handelt. D.h. der Webserver muss speziell konfiguriert werden. Daher kann es nicht Bestandteil des Overpass-Servers werden. Ich werde aber entsprechende Hilfen für die Webserver-Konfiguration in der Dokumentation vermerken: Die beiden Regeln

RewriteRule ^/xml/(.+)$ /api/interpreter?data=[out:xml]$1 [PT]

RewriteRule ^/json/(.+)$ /api/interpreter?data=[out:json]$1 [PT]

in der httpd.conf setzen obige URLs auf ein geeignetes Format für den Overpass-Server um.

Das ganze ist schon schwer genug zu verstehen. jsonp verlangt sowieso get parameter mit callback.

Das dann eben URLs der Form

http://overpass-api.de/api/interpreter?jsonp=foo&data=node[name="Gielgen"]{out;}

Das ist zwar in der Tat lang, aber sollte von jedem Client verdaubar sein.

Zudem wäre es praktisch den {} Syntax für CSS Styling zu verwenden.

Ok. Man könnte die Syntax von {out;} auf out() ändern, wobei in den Klammern ein CSS-String mitgegeben werden darf. Also out("{ fillColor: blue }"). Hilft das?

So würde es doch auch gehen

http://www.overpass-api.de/api?*[name=Wien]&format=xml

• Liste aller Windkraftanlagen in einem Bundesland

Für ungefähr NRW geht z.B.

node["generator:source"="wind"](50.5,6.0,52.5,9.0){xml ids;}

mit etwas über 1000 Fundstellen.

{ids;) verstehe ich nicht

Ist auch ein Betriebsunfall. Da sollte nur "{xml;}" stehen. Mit dem Zusatz "ids" erhält man statt der vollen Daten nur die Ids der gefundenen Elemente, was z.B. zum Zählen praktisch sein kann.

• Liste der U-Bahnen in einer BBox

Das hat mal wieder ein Definitionsproblem im Detail. Alle U-Bahnen, die diese Bbox berühren, geht. Das Zuschneiden auf die Bbox geht bisher nicht.

union(rel[route=subway](50.5,6.8,51.0,7.5),node(r)->.foo,way(r),node(w)){xml;}

liefert die Fundstellen für Bonn.

Speziell bei U-Bahnen kommen wir dann auch mal wieder in Tagging-Interpretationsspielraum, außer route=subway könnte auch route=light_rail passen.

das keyword "union" finde ich hier überflüssig. Kann man nicht einfach normale Klammern verwenden?

auch die "->" funktion habe ich noch nicht kapiert. Was wäre das "normale" verhalten wenn nur ein Leerzeichen verwendet?

Ohne "->" wäre es ein Syntaxfehler. Das Leerzeichen hat keine syntaktische Bedeutung. Grundsätzlich gibt es Anweisungen, die Daten

• sammeln
• umwandeln
• ausgeben

Jede dieser Funktionen kann seine Eingabe entweder aus der Standardeingabe beziehen oder einer speziellen, benannten Variable. Eine solche Eingabe-Variable wird mit ".foo" gekennzeichnet.

Analog kann eine Funktion in die Standardausgabe oder eine Variable schreiben. Eine Ausgabevariable wird mit "->." gekennzeichnet. Würde man die Ausgabe von der Eingabe nur per Position kennzeichnen, so wäre ein "node.foo" ohne weitere Zusätze nicht eindeutig (ist aber sowieso unsinnig).

Wie wäre es mit

(rel[route=subway](50.5,6.8,51.0,7.5),node(r) .foo,way(r),node(w))

rel[route=subway](50.5,6.8,51.0,7.5),node(r) .foo,way(r),node(w)

"node(r)->.foo,way(r)" Variablen machen das Interface schwer zu verstehen. Kann man das nicht mit einem reinen Klammersyntax machen?

recursion - ist das gleich wie //* ?

Ich denke, "//*" kommt aus XPath? Dann wohl nicht. Eine der wesentlichen Eigenschaften von OverpassQL ist, dass es nicht deklarativ sondern imperativ ist. Das hat eine Reihe von Vorteilen, im Wesentlichen, dass es leichter ist, die Laufzeit einer Anfrage vorherzusagen und dass es schwieriger ist, unbrauchbare Abfragen zu schreiben. Insofern ergeben auch die Konstrukte aus einer deklarativen Sprache wie XPath meistens keinen Sinn.

Insofern ist auch die Klammersyntax eher problematisch. Ich wüsste nicht, wie man alle jetzt möglichen Kombinationen so sinnvoll präsentiert. Der zur Zeit beste Vorschlag zur Vereinfachung wäre, "<" und ">" für die Rekursion zu verwenden, um die Rechts-Nach-Links-Auswertung zu ersetzen. Obiges Beispiel schriebe sich dann als

union(rel[route=subway](50.5,6.8,51.0,7.5),>node->.foo,>way,>node){xml;}

oder

union(rel[route=subway](50.5,6.8,51.0,7.5),union(>way,>node),>node){xml;}

, wenn ">all" alle Relationen-Member sammelt oder noch kürzer

union(rel[route=subway](50.5,6.8,51.0,7.5),>>){xml;}

. Das Union-Keyword ließe sich sogar auch noch ohne syntaktische Mehrdeutigkeiten entsorgen.

problem Ich schau mir den Syntax an und weiss einfach nicht was es genau macht. Was macht z.B. was "w" in node(w) ?

Die komplette Anweisung wäre zu lesen als "Finde alle nodes, die zu einem oder mehreren derzeit gefundene Weg gehören.". Dabei steht das "(w)" dafür, dass Wege als Ausgangsmenge verwendet werden.

Das Skript union(rel[route=subway](50.5,6.8,51.0,7.5),node(r)->.foo,way(r),node(w)){xml;} zerlegt:

• (..,..,..) "Bilde die Vereinigungsmenge der Ergebnisse aller Abfragen zwischen den Klammern, und zwar ..."
• rel[route=subway](50.5,6.8,51.0,7.5) "Finde alle Relationen, die das Tag mit Key route und Value subway besitzen und in der Bbox von Breitengrad 50,5° Nord bis 51,5° Nord und Längengrad 6.8° Ost bis Längengrad 7.5° Ost liegen (d.h. mindestens ein Member vom Typ Way oder Node berührt die Bbox)."
• node(r)->.foo "Finde alle Nodes, die Member einer oder mehrerer dieser Relationen sind und leite die Ausgabe nach foo um (eine nicht mehr benutzte Variable, wir sammeln die Ausgabe nur im umfassenden Union)."
• way(r) "Finde alle Ways, die Member einer oder mehrerer der Relation aus der Ausgabemenge sind (und zwar die Menge von rel[route=subway](50.5,6.8,51.0,7.5), da node(r)->.foo umgeleitet worden ist)."
• node(w) "Finde alle Nodes, die Member einer oder mehrerer der Wege aus der Ausgabemenge sind (also dem Ergebnis von way(r))."

Bei diesem Syntax:

union(rel[route=subway](50.5,6.8,51.0,7.5),>node->.foo,>way,>node){xml;}

Was bedeutet hier der Beistrich vom dem ">"?

Der gehört zu dem Union. Das ist ein Überbleibsel von [Map CSS], da direktes Aneinanderschreiben dort eine implizite Rekursion bedeutet. Ich denke, ich werde ohnehin die Syntax dahingehend ändern, dass jedes Kommando auf einem Semikolon endet, weil dann diese Verwechslungsgefahr mit [Map CSS] nicht mehr besteht, und OverpassQL dann etwas mehr nach C++/Java/JavaScript aussieht.

Mit dem xapi interface komm ich zurecht aber halt nur bei einfachen Angfragen.

Wenn es jetzt aber hier ins technische geht. Speziell XML Schnittstellen sind meist deklarativ angelegt und der imperative Zugang ist mit neu. Vielleicht würde sich da eine jsonrpc Schnittstelle für Abfrage Schnittstelle eignen.

{union:[
   route:subway,
   bbox:[50.5,6.8,51.0,7.5],
   node:{
      ...
   }

]}

• Liste der U-Bahnen plus Haltestellen und Eingänge

Haltestellen sind oben dabei. Im Prinzip geht

union(rel[route=subway](50.5,6.8,51.0,7.5),node(r)->.foo,way(r),node(w),node(around.foo:200)[railway=subway_entrance]){xml;}

Aber hier rund um Bonn wird es kaum verwendet.

In xpath gibt es diesen syntax: *[position()<5]. Hier könnte man node[distance()<5] verwenden.

Ehrlich gesagt sehe ich noch nicht, warum das zu einer verständlicheren Notation führt. Im einen wie im anderen Fall zeigen Klammern an, dass es sich nicht um ein normales Key=Value handelt.

• Liste der Geschäfte einer Straße

Geht zur Zeit nicht. Ist aber schon deswegen Überlegungen wert, weil auch Haltestellen für manche Anwendungen auf die zugehörige Fahrbahn projiziert werden müssen.

• Liste der WCs im Umkreis von 500m

Ein gutes Beispiel, weil es einen sinnvollen Anwendungszweck dafür gibt, around auch zusammen mit Koordinaten statt existierender Nodes zu verwenden. Mann kann sich mit einer Bbox behelfen.

Funktioniert hier eine suche nach radius (around)?

Ja. Wenn ich eine Node (woher auch immer) gegeben habe, kann ich in deren Umkreis suchen:

node[name="Wall/Museum"]node(around:500)[amenity=toilets]{xml;}

Nur eben noch nicht um Koordinaten, an denen keine Node liegt.

• Augmented Reality - Bsp.: Berggipfel in Richtung 320° (ich steh auf einem Berg und möchte wissen wie der Berg heißt den ich sehe)

Spannend, aber im Moment noch nicht auf der Tagesordnung. Muss man mal drüber nachdenken.

• Routing

Ähnlich, aber eine ungleich größere Aufgabe. Bisher verwenden die Routing-Algorithmen eine alles andere als triviale Daten-Aufbereitung. Vermutlich wäre der erste Schritt, das mal zu verstehen und möglichst viele der Schritte noch auf dem Server zu ermöglichen.

Bei der API syntax kann man schon noch ein bisschen feilen. Bist du gut mit LeX und Yacc ? :-)

Oh, die beiden Dinosaurier :-) Eher nicht. Tatsächlich übernimmt intern aber ein abgespeckter C-Tokenizer und C-Parser das Parsen, so dass ich auch nur möglichst wenig von der C-artigen Syntax abweichen möchte.

Syntax Probleme

Eine Relation hat mehrere Bezeichungen. relation, rel, r - das ist unnötig kompliziert.

Das mit dem .foo hab ich noch nicht kapiert. Das Suchergebnis wird in die Variable gespeichert, wo wird diese Variable verwendet?

Wenn "Union" ganz weggelassen werden könnte, dann wäre das schon ein bisschen klarer.

Bedeutung der Klammern: Die Eckige Klammer bedeutet, dass etwas gefiltert wird. Die runde Klammer hat verschiedene Bedeutungen. Das ist verdammt schwer zu kapieren. --Robotnic 21:58, 15 January 2012 (UTC)

Rendering

Ich hab jetzt mal einen Client online gestellt: [1]

Man kann Bookmarks machen und anschauen. Die up/down keys sind in Verwendung um frühere Querys zu holen.

Wow. Das sieht sehr eindrucksvoll aus. Mal sehen, wie man OverpassQL dann noch hübscher als Einzeiler hinbekommt.

Danke, danke. Die Bookmarks kannst übrigens gerne füllen (description -> publish).

Old page content

Dies ist eine Brainstorming Seite für eine neue Abfragesprache für die [[Overpass API]]. Die Diskussion fand Ende 2011/Anfang 2012 statt. == Name == MapQL ist ein geschützer Name: [http://trademarks.justia.com/751/05/mapql-75105120.html] :Danke für den Hinweis, dann muss das Ding noch mal umbenannt werden. :Ist jetzt passiert. -- [[Roland.olbricht|Roland]] 2012 Jan 8 15h23 UTC == Use Cases == * map: alle Daten innerhalb einer BBox. :Möglich. Es ist nicht so ganz klar, ob bei Relationen auch die referenzierten Elemente dazugehören sollen, aber beide Varianten lassen sich umsetzen. * Liste aller Atomkraftwerke :Ist beim ersten Versuch daran gescheitert, dass ich kein klares Tagging gefunden habe. power=generator scheint ein Ansatz zu sein, liefert aber alle Kraftwerksarten. :<pre>node["generator:source"="nuclear"]{xml;}</pre> liefert immerhin zur Zeit 146 Fundstellen, aber das sind vermutlich nicht alle. * Liste aller Windkraftanlagen in einem Bundesland :Für ungefähr NRW geht z.B. :<pre>node["generator:source"="wind"](50.5,6.0,52.5,9.0){xml ids;}</pre> mit etwas über 1000 Fundstellen. * Liste der U-Bahnen in einer BBox :Das hat mal wieder ein Definitionsproblem im Detail. Alle U-Bahnen, die diese Bbox berühren, geht. Das Zuschneiden auf die Bbox geht bisher nicht. :<pre>union(rel[route=subway](50.5,6.8,51.0,7.5),node(r)->.foo,way(r),node(w)){xml;}</pre> liefert die Fundstellen für Bonn. :Speziell bei U-Bahnen kommen wir dann auch mal wieder in Tagging-Interpretationsspielraum, außer route=subway könnte auch route=light_rail passen. * Liste der U-Bahnen plus Haltestellen und Eingänge :Haltestellen sind oben dabei. Im Prinzip geht :<pre>union(rel[route=subway](50.5,6.8,51.0,7.5),node(r)->.foo,way(r),node(w),node(around.foo:200)[railway=subway_entrance]){xml;}</pre> :Aber hier rund um Bonn wird es kaum verwendet. * Liste der Geschäfte einer Straße :Geht zur Zeit nicht. Ist aber schon deswegen Überlegungen wert, weil auch Haltestellen für manche Anwendungen auf die zugehörige Fahrbahn projiziert werden müssen. * Liste der WCs im Umkreis von 500m :Ein gutes Beispiel, weil es einen sinnvollen Anwendungszweck dafür gibt, around auch zusammen mit Koordinaten statt existierender Nodes zu verwenden. Mann kann sich mit einer Bbox behelfen. * Augmented Reality - Bsp.: Berggipfel in Richtung 320° (ich steh auf einem Berg und möchte wissen wie der Berg heißt den ich sehe) :Spannend, aber im Moment noch nicht auf der Tagesordnung. Muss man mal drüber nachdenken. * Routing :Ähnlich, aber eine ungleich größere Aufgabe. Bisher verwenden die Routing-Algorithmen eine alles andere als triviale Daten-Aufbereitung. Vermutlich wäre der erste Schritt, das mal zu verstehen und möglichst viele der Schritte noch auf dem Server zu ermöglichen. * Watchdog Die Feuerwehr braucht eine Karte mit Hydranten. Wenn diese Daten in OSM sind, dann sollte es auch möglich sein die gültigkeit zu überprüfen. Der Feuerwehrhauptmann möchte also ein Tool mit dem Änderungen die z.B. innerhalb der letzten Woche gemacht wurden angezeigt werden. Die standard osm changesets api ist am langsamsten bei großen bboxen und gleichzeitig wenig edits. == Query language == Verbreitete Abfragesprachen: SQL, [http://www.w3.org/TR/selectors/ CSS-Selektoren], [http://www.w3.org/TR/xpath/ XPath], [http://www.w3.org/TR/xptr-framework/ xpointer], [http://www.tutorialspark.com/css3Reference/CSS3_Properties_Reference.php CSS-Selektoren] :Das Problem mit vorhandenen Sprachen ist, dass sie auf andere Benutzungsszenarien ausgelegt sind. :* SQL: Alle komplexeren Beziehungen, z.B. bboxen und Radius, haben zunächst keine kanonische Abbildung. Insofern ist noch nicht viel gewonnen. :* CSS-Selektoren, XPath, xpointer: Sind für ein doch sehr anderes Einsatzgebiet entworfen. Man könnte diese zudem auch so falsch verstehen, dass die Abfragesprache : als Semantik ein fikitves Planet.osm als XML-Dokument zugrunde legt. * Spatial Search:bbox; point + radius * Type: node, way, relation * tags (k,v): AND, OR, NOT * Kombinierte Abfrage * Rekrusive Abfagen Um hier eine gute Lösung zu finden muss auch klar sein was der Server auch kann. Es ist recht einfach einen spatial index zu setzen und es ist auch nicht schwierig eine k,v Kombination mit einem index zu belegen. Die Kombination macht aber dann doch Probleme. Also z.B. die Atomkraftwerke in Europa. :Generell führt eine Bbox bei einer k-v-Kombination fast immer noch zu einer Beschleunigung. Eine brauchbare Schätzung für die Laufzeit einer Abfrage ist: Je Sekunde ein Bbox-Teil mit 500 Tsd. Nodes, alternativ 10 verstreute Nodes. Für eine Abfrage der Art generator=power mit weltweit ca. 10 Tsd. Treffern würde jede Bbox eine Beschleunigung erbringen, die ihrerseits höchstens 500 Mio. Nodes enthält, was z.B. auf Europa zutreffen dürfte. Größere Bboxen verlangsamen, kleinere beschleunigen. Die Atomkraftwerke in Europa sind da tatsächlich eine Ausnahme mit wenig Fundstellen (ca. 300) gegenüber einer sehr großen Bbox. Es stellt sich die Frage ob der Anwender die Reihenfolge der Suche angeben kann. Also z.B. zuerst per bbox suchen und mit dem Ergebnis weitersuchen oder zuerst die Tags auswerten und auf das Ergebnis eine bbox suche machen. :Wenn man es drauf anlegt, dann schon. <pre>node[generator:source=nuclear]node._(30.0,-15.0,60.0,30.0){xml;}</pre> verschiebt die Bbox nach hinten und macht die Abfrage schneller. Weiters stellt sich die Frage wie aufwändig die Suche in einem Radius ist. :Im Wesentlichen äquivalent zur Bbox. Funktioniert die Radius Suche auf Ways oder nur Punkte? :Zur Zeit nur für Nodes rund um Nodes. Das soll aber mittelfristig auf alle Kombinationen erweitert werden. Macht es z.B. Sinn alle U-Bahnen einer Stadt zu suchen und dann im Umkreis von 100m die Stationen zu selectieren. :Ja, dafür ist die Umkreissuche ausgelegt. Sie verhält sich sehr ähnlich zur Bbox. === XPath änlicher Ansatz === <pre> relation[@id=4711]/way/node //alle nodes einer bestimmten relation way[@@bbox=48.2 16.5 48.3 16.6][@highway=primary] //ways in einer bbox mit highway=primary way[../../relation[@id=4711]] //alle ways die teil einer relation sind (gleich wie /relation[@id=4711]/way) way[@@position=48.2,16.5][@@radius=50] //alle wege die sich im umkreis von 50m zu einem Punkt befinden node[way[@id=4711]]/../way //alle wege die einen gemeinsamen Punkte mit dem way mit der id 4711 haben. way[@id=0815][@@radius=200]/node //alle nodes die in einem Abstand von bis zu 200m zu diesem Weg sind *[name=U4] //nodes,ways und relationen im Ergebnis </pre> Da die hierarchie immer gleich ist und z.B. ein way niemals Kind-Element eines nodes sein kann, sind die "../.." Angaben eigentlich überflüssig. === Mehrstufiger Ansatz === alle relationen (nur relationen haben way als child) einer bbox aus denen die ways mit k,v haben. <pre> *[@@bbox=48.2 16.5 48.3 16.6]{ way[highway=primary]/node //nodes werden ausgegeben way[highway=primary] //ways werden ausgegeben } oder *[@@bbox=48.2 16.5 48.3 16.6]/way[highway=primary]{ node . } </pre> Der {} Syntax ist nicht ideal falls man auch die CSS Eigenschaften dazugeben will weil CSS auch die geschwungenen Klammern verwendet. == Anders herum - zuerst tag filter== <pre> *[@power=generator][generator:source=wind]{ *[@@bbox= ...große bbox...]{ node way/node way } } </pre> === full oder id only === * nur way id oder way inklusive nodes * sollen die Tags mitgeliefert werden * soll zur Relation der komplette inhalt mitgeliefert werden. Relationen können Relationen beinhalten "full" wäre da ein bisschen viel. == Styling == Sehr oft sollen die Daten gleich auf einer Karte eingetragen werden. Ein Kombination mit einer [[MapCSS]] ähnlichen Sprache wäre wünschenswert. Den Server interessiert das Styling natürlich nicht. MapCSS hält sich bei den CSS Eigenschaften leider an keine Standard. Sinnvoller wäre es z.B. den SVG CSS Standard zu übernehmen und gegebenfalls zu erweitern: [http://www.w3.org/TR/SVG/styling.html] == Vector Tiles == Ganz nett wäre auch wenn der Server Vector Tiles liefern würde. Die Dinge kann man cachen. == Daten Reduktion == Wenn man z.B. das Europäische Autobahnnetz im Browser darstellen will dann hat man mit mehr als 100 MByte an Daten zu tun. Das sind zu viele Details und bringt Probleme bei der Übertragung und Darstellung. Es würde reichen nur z.B. jeden 10ten Node darzustellen und die restlichen Nodes zu ignorieren. Im einfachsten Fall wäre so eine Reduktion also machbar indem man nur jeden zweiten, vierten, achten,... node nimmt. Möglich wäre es natürlich auch Kurven durch die Punkte zu legen und den maximalen Fehler angibt. Für die Darstellung im Browser gibt es z.B.: http://www.w3.org/TR/SVG/paths.html#PathDataCurveCommands http://www.html5canvastutorials.com/tutorials/html5-canvas-bezier-curves/ http://www.tutorialspark.com/html5/HTML5_Canvas_Bezier_Curves.php == Rückgabe Datenformat == OSM XML, [[Xappy.js#JSON_output|JSON (OSM-Format)]], [http://geojson.org GeoJSON], [[PBF Format|PBF]] [[Category:Development]] [[Category:Overpass API]]