OverpassQL

From OpenStreetMap Wiki
Jump to: navigation, search

Das ist kein fertiger Standard sondern nur mal ein Brainstorming.

MapQL ist ein geschützer Name: [1]

Danke für den Hinweis, dann muss das Ding noch mal umbenannt werden.
Ist jetzt passiert. -- Roland 2012 Jan 8 15h23 UTC

Contents

Use Cases

Möglich. Es ist nicht so ganz klar, ob bei Relationen auch die referenzierten Elemente dazugehören sollen, aber beide Varianten lassen sich umsetzen.
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.
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.
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.
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.
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.
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.
Spannend, aber im Moment noch nicht auf der Tagesordnung. Muss man mal drüber nachdenken.
Ä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.

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, CSS-Selektoren, XPath, xpointer

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.

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. 
node[generator:source=nuclear]node._(30.0,-15.0,60.0,30.0){xml;}
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 

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

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. 

*[@@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
    .    
}

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

*[@power=generator][generator:source=wind]{
   *[@@bbox= ...große bbox...]{
       node
       way/node
       way
   }

}

full oder id only

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: [2]

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/


Rückgabe Datenformat

OSM XML, JSON (OSM-Format), GeoJSON, PBF

Retrieved from "http://wiki.openstreetmap.org/wiki/OverpassQL"
Personal tools
Namespaces
Variants
Actions
site
Toolbox