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
Die 10px die ray angemerkt hat, treten hier nicht mehr auf, wenn man im Firebug die Eigenschaft height: 100%; für html, body deaktiviert.
Dafür habe ich ein anderes kleines Problem mit der Suche unter FF18: dort erscheint nur eine große Dropdown-Box ohne Inhalt. Bei Chrome funktioniert es.
Ja, kann ich bestätigen, danke für den Tipp - Jetzt weiss ich auch endlich, warum bei meiner Diaschau-Webseite teilweise so ein seltsamer weisser Balken war…
mfg~ray
Habe gerade ein Update hochgeladen.
-
implemented auto-repairing of queries with a possible lack of recurse statements
-
upgrade to leaflet 0.5
-
disabled “start at current location” by default
-
added keyboard shortcuts for saving/loading and help
-
bugfixes
-
some internal code restructuring
Das coolste neue Feature sollte aber die automatische Query Reparatur/Vervollständigung sein: 
. Die Idee dafür stammt von Roland.
Hallo,
besteht noch die Möglichkeit das man die Trennlinie zwischen Editor und Karte verschieben kann?
Auf einem großen Bildschirm hat man so mehr Platz für die Karte.
Die Links im Wiki sind super, endlich braucht man die Bsp. nicht mehr selbst auswerten.
Grüße
Andreas
kommt demnächst
Das ist sehr schön geworden.
Fehler, die von der Overpass-API zurück gemeldet werden, können zwar (noch) nicht automatisch korrigiert werden. Immerhin jedoch wird die Fehlerstelle farbig (ein Art rot) hervorgehoben. So kann man gezielt schauen, was da wohl nicht stimmt.
Verrätst du uns auch die neuen Shortcuts?
Nicht nötig sind in der Doku bereits aufgeführt. für alle, die wie ich zu faul sind nachzusehen, hier eine Kopie aus der Doku:
Edbert (EvanE)
nächstes Update (seit ein paar Stunden online):
-
resizable panels (editor/map)
-
tooltips for map controls
-
auto-repair also for “JOSM” export
-
enabled “include current map state in shared link” by default
-
bugfixes
Das nächste Update wartet auf Tester 
Als besonderes Schmankerl gibts turbo ab jetzt auch auf Deutsch! (sollte automatisch erkannt werden; alternativ kann man die Sprache auch in den Einstellungen erzwingen).
Auch cool: Wenn Linien- oder Flächen-Features durch Herauszoomen so klein werden, dass sie kaum noch erkennbar sind, werden sie jetzt wie POIs als Kreis angezeigt (mit roter anstatt gelber Füllung).
Restliches Changelog:
-
added “fullscreen” (wide) map view
-
handle untagged nodes as POIs when they are member of at least 1 relation
-
implemented first set of unit tests
-
bugfixes
Tolles Werkzeug. Hab’s jetzt schon ein paar Mal gebraucht.
Danke!
Thomas
Hallo,
wie wäre es eigentlich mit ein bisschen Syntaxhervorhebung.
vg
Andreas
Neueste Version ist online. Neu dabei:
Ich hätte da mal noch 2 Wünsche:
- Links im Popup sollten in einem neuen Fenster aufgemacht werden. Rechts klicken und “Open in new tab” vergißt man zu oft.
- Zusätzliche Abfrage, wenn eine große Ergebnismenge angezeigt werden soll => letzte Chance bevor der Browser abraucht oder sehr langsam wird.
Auch überlagert die Suchbox das Popup, aber das ist m.E. nicht so wichtig.