OverpassApi- Wanderweg-Relationsdaten für aktuellen Karten-Ausschnitt

Hi !

kennt einer ein Beispiel wo die Daten eines Wanderweges für den akteullen Ausschnitt mittels der OverpassApi gezogen werden (und in einer OpenLayers-Karte dargestellt werden) ?

Gruß Jan :slight_smile:

Hallo Jan

Du kannst dir eine solche Anfrage (inklusive Kartendarstellung) leicht mit dem Overpass_turbo selbst erstellen.

Edbert (EvanE)

hi !

dann sage mir doch mal eben wie ich bei

automatisch den Ausschnitt aus der Karte übernehmen kann ?!?!

Gruß Jan :slight_smile:

Hallo Jan

Redest du von der API (da geht das nicht) oder vom Turbo?

Im Overpass-Turbo sind einige ‘Shortcuts’ (im Wiki z.B. als Template bezeichnet) definiert. Der wichtigste dürfte der {{bbox}} Shortcut sein. Damit wird der Kartenausschnitt oder ein explizit festgelegter Ausschnitt verwendet. Die Bbox-Querry lautet dann: <bbox-query {{bbox}}/>

Das Lesen der Abschnitte Shortcuts und Map Controls von Overpass turbo oder der Hilfe Funktion in der GUI hätte dir diese Erkenntnis allerdings auch gebracht.

Edbert (EvanE)

Nahmd,

Der Bereich enthält über 6500(!) Wanderweg-Relationen. Die alle in einer Karte darzustellen überfordert den Browser.

Ich würde die angezeigten Wege von der Zoomstufe abhängig machen, also bei kleinem Zoom nur die internationalen und nationalen Wanderwege abfragen, und erst bei hinreichen großem die regionalen und dann endlich die lokalen Wanderwege. Wenn nicht nur die Existenz, sondern auch der Verlauf der Wege dargestellt werden soll, sind die Zoomgrenzen noch einmal deutlich höher.

Gruß Wolf

PS: Sint-Quintens ist immer einen Besuch wert: zurücklehnen und staunen.

HI !

danke - das sollte auch nur ein Beispiel sein. Ich möchte derzeit z.b. nur den Hanseatenweg (http://www.openstreetmap.org/browse/relation/1928226) im aktuellen Kartenausschnitt anzeigen lassen.

Gruß Jan :slight_smile:

Ich hätte da ein Beispiel für Wanderwege im Kartenausschnitt (genauer: Wanderwege, die den Ausschnitt berühren, die können ausserhalb noch viel weiter gehen und werden dann auch geholt)

Dass erst mal nichts passiert, liegt daran dass es ziemlich viele Daten sind, die da geholt werden und dass die auch erst mühsam in den Vektorlayer gestopft werden müssen, ein einzelner Weg kann ja schon auch paar 1000 Punkte haben.

Da müsste man die Leute noch ein bisschen Unterhalten, während sie warten, mit einer lustigen Eieruhr zum Beispiel. Auf jeden Fall muss man sie in einer richtigen Anwendung daran hindern, die Karte weiterzuschieben, weil das löst ja gleich wieder eine Anfrage aus, noch während die erste läuft.

Aber da es Dir ja in erster in erster Linie um die Übernahme des Ausschnitts geht: Das sind die Zeilen 67 bis 75 und die laufen performant.

Grüße, Max

Moins,

Möglicherwese willst Du die Daten des Gesamtweges einmalig komplett abrufen und dann intelligent selber bereitstellen?

Sooo oft ändert sich die Routenführung eines Fernwanderweges ja nicht, dass Du ihn minutengenau aktualisieren müsstest.

Gruß Wolf

hi !

das wäre ein wirklich “geile” Lösung für einen Weg den man betreut und ggf. auch in OSM fit ist.

Der Ursprungsgedanke der Bereichsabfrage war eben das Problem bei sehr langen Wegen das sich ansonsten die Downloads teilweise aufhängen.

Werde mir gleich einmal den Source ansehen. Also das Prinzip ist ja irgendwie einfach - es werden einfach Punkte weggelassen. Aber wo hast Du die Daten liegen / gezogen.

Vielleicht könntest Du noch einige Kommentare ergänzen ?

Gruß Jan :slight_smile:

Moins

Eher nicht die Abfrage oder der Download, sondern der Browser beim Versuch, das zu zu verarbeiten und zu rendern.

Das kann vermeiden, wenn der Server bereits vorfiltert, sowohl nach Boundingbox als auch nach nötiger Auflösung. Ein schlauer Mensch hat das mal so formuliert: “Daten, die nach dem Filtern nicht mehr da sind, müssen auch nicht verarbeitet werden.”

Eine Filterung je Way funktioniert nicht (denn dann wären bei Zoom=0 je Way noch zwei Punkte in der Karte); unter anderem deshalb klebt man die Ways zu so langen Stücken wie möglich zusammen.

Die Vorverarbeitung der Daten ist die Hauptaufgabe. Natürlich kann man einfach alle Wege in einen Pool werfen. Wegen des oben genannten Punktes und weil bei teiltransparenter Darstellung an jeder Stoßstelle ein unschöner dunklen Fleck erscheint, hält man möglichst lange Teilstücke vor.

Das habe ich noch nicht fertig, also händisch: mit JOSM die Relationen gezogen, alles weggelöscht bis auf die Ways (und danach höllevorsichtig nicht wieder hochzuladen). Danach die Ways zusammenkleben lassen soweit möglich; da, wo es nicht passte (rausstehende Schwänzchen und kurze fehlende Stücke), die Daten geflickt (konnte ich leider nicht hochladen wegen des vorherigen Löschens), sodann den einen als GPX exportierten Weg in eine Textdatei gewandelt.

Sind drin. Nützen aber nichts, weil der eigentliche Arbeitsschritt das Preprozessing der Daten ist, und danach die Online-Filterung.

Der allerschwierigste Schritt aber ist gedanklicher Natur: feststellen, dass sich die Routenführung eines Wanderweges nicht minütlich ändert, dass man also hinreichend Zeit für ein Preprocessing hat.

Gruß Wolf

hi !

dann habe ich das vorerst verstanden - alles wesentliche läuft out of the browser.

Für meinen Fall sollte aber so flexible auf die Relationen reagiert werden können das auf die Originaldaten zugegriffen werden muss. Also erst einmal mit Overpass weiterarbeiten (verfolgen).

Aber interessant ist es allemal - hatte ich bei meinen Jakobskarten schon einmal in Betracht gezogen - ohne Lösungsergebnis.

Gruß Jan .-)

Hallo Jan

Statt einer Bbox-Querry kannst du auch das Area-Konstrukt verwenden. In Kurzform dein Weg in Rostock oder in einem Kreis oder in Meck-Pom usw. Das Problem kann dabei nur sein, den richtigen Namen der administrativen Relation zu finden.

Edbert (EvanE)