Ich habe nix verlangt, es ist ein Gedanke/Idee um die Web-Gui noch attraktiver zu machen. Auf welche Art sich das realisieren läßt (oder vlt. auch überhaupt nicht), davon war keine rede. Gedacht habe ich dabei jedoch an etwas was ich schon aus verschiedenen Webseiten für HTML kenne und benutze (z.B. im Zusammenhang mit OSC): TinyMCE. Ob es so in der Art für die Overpass-API ebenfalls möglich ist, weiß ich nicht…
Wie kellerma schon schrieb wäre das schon ein heftiger Aufwand.
Die Leute von der Struktur der Overpass-API fernzuhalten, scheint mir allgemein problematisch zu sein. Dinge wie recurse (Relation → Weg, Weg → Knoten, …, Knoten → Weg, Weg → Relation, …) oder union (zusammenfassen mehrerer Fragen/Ergebnisse) sind wichtig für das Konzept und sollten nicht wirklich verborgen werden.
Woran man denken kann, ist die Struktur noch besser hervorzuheben und mehr Erklärungen anzubieten.
- Einrücken (pretty-print) auf Knopfdruck
- Highlighting eines Bereiches, wenn man Anfang/Ende mit Modifier klickt
- Tooltipps sobald man mit dem Cursor über einem Keyword verweilt
- kurzer Hilfetext (mit Link), wenn man ein Keyword mit Modifier klickt
- Syntax-Check auf Knopfdruck.
Ein Problem, das dabei zusätzlichen Aufwand bedeutet, sind die zwei Abfragesprachen (XML und QL).
Edbert (EvanE)
Hallo Edbert,
prinzipiell stimme ich deinen Punkten, die die aktuelle Anwendung betreffen, zu. Vielleicht würde es auch Sinn machen, eine Wiki-Seite mit einer kommentierten Sammlung an “Overpass-Snippets” einzurichten, auf der jeder seine eigenen Praxis-Beispiele eintragen kann. Ich sehe das als gute Ergänzung zur offiziellen Dokumentation und könnte Einsteigern helfen, schnell ein passendes Script zu finden.
Jetzt nochmal zu der anderen Idee: Ziel eines grafischen Editors soll ja gerade nicht sein, die Struktur (oder Konzepte) der Overpass API zu “verstecken”, sondern eine Unterstützung bieten, damit der Anwender sich nicht mit der Syntax der Overpass API zu sehr beschäftigen muss. Mir geht es selbst so, dass ich nach einigen Tagen wieder Details vergessen habe und immer wieder in der Doku nachschauen muss, wie jetzt was funktioniert.
@kellerma: Der Aufwand ist sicherlich heftig, keine Frage. Es war auf nicht als direkte Aufforderung zu verstehen, d.h. als Idee formuliert. Für Javascript gibt’s bestimmt schon fertige Libraries für Flowcharts, vermutlich ist aber der Aufwand für die Konvertierung zwischen Overpass QL/XML und Flowchart nicht zu unterschätzen.
Gruß,
mmd
Du sprichst mir aus der Seele 
Zusätzlich stellt diese Funktion vollautomatisch quasi eine Hilfe dar, denn ich sehe anschließend in der Syntax was ich gemacht habe und kann daraus lernen.
Excellent tool, very useful!
BTW, can anybody check and correct this? I see two nodes for place=state of Bremen. And Node 2050186944 the name:en=Free and Hanseatic City of Hamburg, don’t think this is intended? 
Bremen corrected. TODO: fix international names.
@mmd, @reneman: Danke für den Input. Und ja, ich plane schon in einer der nächsten Versionen etwas in die Richtung Einsteiger-Freundlichkeit zu verbessern. Ob das genau so eine WYSIWYG/Flowchart/whatever Lösung wird kann ich nicht garantieren. Zur Zeit hätte ich eher an eine Art Dialog-basierenden Wizard (“Query-Builder”) gedacht, der dann (kommentierten) Quelltext ausgibt. Den Overpass Quellcode ganz zu verstecken, ist ja (wie ihr auch sagt) nicht im Sinn dieser GUI.
@EvanE: danke für die Ideen, einige dieser “kleinen Verbesserungen” (z.B. tooltips, pretty-print) sind unter Umständen sogar relativ leicht zu implementieren. Werde ich auf jeden Fall bei der weiteren Entwicklung berücksichtigen.
Ja natürlich, Mehrsprachigkeit ist definitiv auch geplant (und sogar weit oben auf der Liste ^^).
Hallo mmd
Ein wichtiger Schritt wäre die Möglichkeit, einen Link auf eine Overpass-Turbo Seite mit einem Beispiel (ggfs. nur das Beispiel ohne ein Ergebnis) setzen zu können. Dazu habe ich bis jetzt noch keine Möglichkeit gefunden (falls ich etwas übersehen habe bitte melden). Eine Ergebnisseite (und damit einen Link dorthin) kann man ja bereits über die save - load Kombination erzeugen.
Eine Sammlung von Beispielen ist natürlich immer sinnvoll (bitte dann auch gut mit Kommentaren bestückt). Zu so einer Seite werde ich gerne meine bisherigen Ergebnisse beisteuern. Auch dort wäre ein Link auf die Overpass-Turbo Seite mit dem Beispiel gut zu gebrauchen.
Nachtrag: Unter dem Button “Share” findet sich die gewünschte Funktion. 
und
Eine Prüfung auf Syntax und korrekte Keywords mit gegebenenfalls Vorschlägen wie es richtig sein könnte, wäre natürlich sehr nützlich. Ebenso eine kurze Übersicht über die meisten Elemente der Overpass-API und ihre Bedeutung.
Etliche Probleme mit der Overpass-API sind aber Probleme des grundsätzlichen Verständnises. Wenn ich nach einer Relation frage, bekomme ich nur die Relation, ihre Taggs und ihre Mitglieder-Liste. Ich bekomme jedoch nicht die Mitglieder als Objekte. Dafür braucht es ein recurse und ein union. Das sind prinzipielle Fragen, die man erst einmal verstanden haben muss, bevor man überhaupt ein Ergebnis auf einer Karte sieht.
Ich halte es für äußerst schwierig, solche ‘Probleme’ zu finden und entsprechende Ratschläge sinnvoll aufzubereiten. Schön wäre es natürlich, wenn der Overpass-Turbo langfristig um eine Tutorial Komponente im obigen Sinne ergänzt werden könnte. Das würde die Nutzung der Overpass-API sicherlich noch um einiges erleichtern.
Wie du auch schriebst, sind das eher Ideen für zukünftige Entwicklungen, als Bitten das kurzfristig zu realisieren. Über das was sich einfach einbauen lässt, freuen wir uns natürlich gerne auch früher.
Um es nochmal zu betonen (ich denke die meisten werden meine Sicht teilen):
Der Overpass-Turbo ist auch jetzt schon eine tolle und ausgesprochen nützliche Sache.
Und nicht zu vergessen, der Dank an Roland, dessen Overpass-API das alles erst möglich macht.
Edbert (EvanE)
Im Prinzip gibt es ja bereits schon die Overpass API Language Guide Seite. Dort findet man schon eine Reihen von einfach gehaltenen Beispielen. Natürlich kann eine erweiterte Beispielseite auch nicht schaden.
Ich habe schon mal versucht im Language Guide überall Links zu turbo einzubauen. Einen Vorschlag habe ich schon erstellt (warte noch auf das OK von Roland das in die Seite zu integrieren).
Wieso das ?
Ein integriertes Tutorial klingt erstmal nicht schlecht. Allerdings könnte so etwas vielleicht auch mit relativ weniger Aufwand z.B. als wiki-Seite mit Links zu turbo realisiert werden…
freut mich
+1, das kann man gar nicht genug betonen!
Overpass-Turbo ist mir eben schon sehr hilfreich gewesen. Etwas vermisst habe ich dabei:
-
Umwandlung OP-XML <-> OP-QL (wie hier in relativ schlichtem Design)
-
Vorschläge, was man möglicherweise vergessen haben könnte (union, recurse, …)
-
Auto-Vervollständigung
mfg~ray
Hmmm, QL scheint kompakter zu sein als OP-XML. Sollte man also vielleicht eher die QL lernen? 
Kompakter sicherlich. (Das war ja wohl auch das Ziel)
Besser zu lesen/verstehen? Für die meisten wohl nicht. (Für die API vielleicht schon)
Edbert (EvanE)
Sieht gut aus.
Ich würde aus optischen Gründen die Reihenfolge der Kästen mit XML (meist größer) und QL (meist deutlich kleiner) vertauschen.
Das “:(” steht für den Ärger über mich selbst, Share erst nach Schreiben meiner Zeilen gefunden zu haben.
Das “:)” steht für die Freude, dass das, was ich mir wünschte, doch schon geht.
Der Unterschied zwischen einem Language Guide und einem Tutorial ist die Zielsetzung:
- Language Guide: Vorstellung der Elemente einer Sprache (die Wörter)
- Tutorial: Wie löst man mit den Elementen eine konkrete Aufgabe
Aus den Elementen Programme erstellen. Dazu braucht es noch
Zusammenhänge/Abhängigkeiten zwischen den Elementen.
Das bildet dann eine Art Grammatik.
Sozusagen aus Wörtern und Grammatik Sätze zusammenbauen.
Die Beispiele in einem Tutorial fragen dann nicht: “Ich habe das Sprachelement, was tut das?” sondern “Ich habe dieses Problem. Wie setze ich die Elemente/Bausteine der Overpass-API zusammen, um dieses Problem zu lösen, meine Daten zu erhalten und gegebenenfalls auf einer Karte darzustellen?”. Ich denke, das ist ein ganz anderer Ansatz.
Ein Entwickler kann einen Language-Guide erstellen (das hat Roland durchaus gut gemacht), aber er wird sich mit einem Tutorial meist schwer tun. Das können Anwender aus ihrer eigenen Erfahrung mit der Abfrage-Sprache sehr oft besser.
Mal als Beispiel mein erster Versuch für die PLZ-Gebiete in Bonn.
Ergebnis: Daten ja aber nicht auf der Karte (no visible data)
Also erst mal grübeln. Ah ja, in den Daten sind ja nur die Relationen enthalten. Wie bekomme ich die Wege und Punkte der Wege? Im Language Guide wurde recurse erwähnt. Eingebaut und mein zweiter Versuch.
Upps, das sind ja nur Punkte in der Karte. Zur Kontrolle in den Daten nach gesehen, sind dort nur Punkte und ihre Koordinaten.
Analyse: Es werden die Daten immer weiter gefiltert und nur das letzte recurse type=“way-node” liefert das Ergebnis.
Hmmh, da war doch noch was. Richtig, da gab es union, was die Ergebnisse mehrerer Abfragen sammelt. Das also auch noch integriert und mein dritter Versuch.
Jetzt erst sieht es aus, wie ich mir das vorgestellt hatte.
Du siehst ein Tutorial Beispiel hat eine ganz andere Qualität, es will/soll Zusammenhänge darstellen.
Übrigens bin ich mit den Postleitzahlen eigentlich noch nicht fertig. Ich möchte natürlich die PLZ in der Mitte des Gebietes sehen. Dazu habe ich aber bisher noch keine Idee, wie (und ob) das mit der Overpass-API geht.
Edbert (EvanE)
Ich habe das Tool jetzt mal mit diesen beiden Anfragen zur “Ermittlung von möglicherweise ungewollten Zugangsbeschränkungen auf Tracks” verprobt:
(way [highway=track] [access=forestry] [foot !~ ‘.’] (51.8, 7.4, 52.1, 7.8); >;); out meta;
oder
(way [highway = track] [access = agricultural] [foot !~ ‘.’] (51.8, 7.4, 52.1, 7.8); >;); out meta;
Die Visualisierung der Ergebnismenge ist wirklich sehr hilfreich … Respekt für die tolle Arbeit.
Da ich grundsätzlich Overpass-QL verwende, könnte das Eingabefenster “kleiner” ausfallen … ideal wäre die Möglichkeit einer Größenveränderung.
Gruß Klaus
PS: Zum Thema Tracks siehe auch http://forum.openstreetmap.org/viewtopic.php?id=19827
Damit hast du natürlich vollkommen recht! Ich wollte aber eigentlich darauf hinaus, dass so ein Tutorial erstmal am besten unter wiki.openstreetmap.org/Overpass_API/Tutorial (o.s.ä.) aufgehoben wäre.
+1
Definitiv! Ein gutes Tutorial wäre das Beste, das der API derzeit passieren könnte 
So etwas geht zur Zeit wirklich (noch) nicht. Der Punkt ist, dass sowohl die API als auch turbo so gut wie keine Datenmanipulationen machen. Die API filtert “nur” und die GUI zeigt “nur” an. Technisch gesehen kann natürlich Beides um (einfache) Geodaten-Manipulationen erweitert werden. Trotzdem wird immer irgendwann der Punkt kommen, wo man selbst Hand anlegen muss (siehe z.B. die turn-restriction Karte von Zartbitter). Ich habe da zwar schon etwas im Hinterkopf, wie man turbo als Basis für solche Dinge verwenden könnte, ist aber noch nicht viel mehr als ein Hirngespinst
Du hast recht. Flexible Panels wären auch bei überdurchschnittlich breiten oder schmalen Bildschirmen praktisch. Ist notiert.
Tja, dann muss ich wohl mal beginnen ein Tutorial (erst mal fürs Wiki) zu entwickeln.
Das kommt davon. Wenn man gute Vorschläge macht, sagt irgendeiner (z.B. man selbst), dann fang doch mal damit an. 
Gut das geht dann halt nicht auf einfache Art. Für meine Zwecke
“Kann ich die Postleitzahl von einem anderen Gebäude übernehmen?”
reicht mir ja zu wissen, dass ich ausreichend weit von der nächsten PLZ-Grenze entfernt bin.
Die offiziellen Unterlagen der Post darf ich dafür ja nicht verwenden.
Edbert (EvanE)
Dabei fällt mir gerade auf: Bei mir (FF18.0.1 @ WinXP MCE) wird eine Scrollleiste für ungefähr 10px eingeblendet, unterhalb der Karte ist wenn man runterscrollt eine weisse Fläche zu sehen, die zu gehören zu scheint (ermittelt über die Element-Auswahl von Firebug). Ich finde jetzt aber nichts, woran das liegen könnte. Wäre super, wenn du dass auch beheben könntest, wenn du schon dabei bist
mfg~ray