bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.

Ja, da im Südharz (?) funktioniert anscheinend die Abfrage. In unserer Gegend kommt da nix.

Super wäre es, wenn das "normale Wanderwegeoverlay" einfach entsprechend beschnitten werden würde, so dass man gleich sieht, welche Pfade mit welcher Markierung vorhanden sind und nicht die kompletten markierten Wege dargestellt werden (also auch auf Schotter und Asphalt).
Bei deinem Beispiel sind die entsprechenden Wegabschnitte alle blau mit einer Lupe dargestellt und erst wenn man auf die Lupe klickt, bekommt man weitere Infos, um welche Markierung es sich handelt.
 

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
@mw.dd, wo wir gerade beim Thema Overlays sind. Markierte Pfade kann man sich natürlich auch einfach via overpass query einblenden lassen. Das ist natürlich schon recht umständlich, aber besser als nichts:
Code:
( way[highway=path]["osmc:symbol"]; way[highway=path]["symbol"]; way[highway=path][trailblazed]; );
Naja, das nützt mir nicht so viel, weil angezeigt werden die auch auf der Karte, die ich benutze.
Es soll dort bevorzugt geroutet werden 😉
 
Das ist kein valides GPX-Format. Damit kannst Du so nix anfangen.
🤔 ähm - bei mir läd das (in Chrome - Firefox will nicht). Aber das Teil ist recht umfangreich und wirft auch nen GeoJSON Fehler, aber es läd die POIs. Meine CPU (oder eher: Einer der Threads) war aber auch einige Sekunden gut beschäftigt.

1682953163505.png
 
ich nutze auch für Bikerouter Firefox (leider wird Safari auf Mac und iOS nur sehr schlecht unterstützt)
wie hast du das geladen? als Route geladen oder in den benutzerdefinierten Ebenen?
 
mit chrome bekomme ich auch diese Fehlermeldung aber die Pointe werden geladen.

Die Fehlermeldung lässt sich relativ leicht umgehen, bikerouter-web erwartet scheinbar ein <trgseg> mit mindestens einem <trkpt>.

Also wenn Du Dir das File im Editor deiner Wahl öffnest und diese Zeilen mit nem Dummytrack unten vor dem schließenden </gpx> einfügst, verschwindet die Fehlermeldung:

Code:
 <trk>
  <name>test04</name>
  <link href="https://bikerouter.de/">
   <text>bikerouter.de</text>
  </link>
  <trkseg>
    <trkpt lat="47.6313500866174" lon="9.361082694762093"/>
    <trkpt lat="47.63181261181244" lon="9.453801172994647"/>
  </trkseg>
 </trk>

1682956988400.png


Das Ding bleibt halt recht umfangreich und daher recht fordernd fürs Rendering im Browser. Da ließe sich sicher auch was Scripten was Dir nur die POIs in nem definierten Umkreis einer Koordinate in deiner Wunschregion im File drin lässt (oder über ein .gpx verarbeitendes Tool deiner Wahl was eine Crop-Funktion o.Ä. anbietet). Aber wenn wir sowas anfangen gibts nachher wieder von @CC. aufn Deckel dass man in 2023 keine solchen Aufwände mehr treibt. :rolleyes: :D
 
Zuletzt bearbeitet:
komoot wollte mich bei Bitburg auf die B51 leiten. Das ist eine baulich getrennte Schnellstraße und es erschien mir doch etwas ungesund da drauf zu fahren. Außenrum war es dann doch schöner. Bei komoot habe ich die Stelle dann auch als gefährlich gemeldet.

Heute hab ich mal mit bikerouter nachgesehen, und je nach Profil leitet der mich auch auf die B51:
https://bikerouter.de/#map=15/49.94...,49.95149;6.535428,49.942298&profile=trekking

Was ist denn da los? Und was kann ich machen, damit die Daten an der Stelle bereinigt werden? Oder gehört das so?
 

Anhänge

  • B51.png
    B51.png
    167,2 KB · Aufrufe: 68
Ja, hier: https://www.openstreetmap.org/changeset/127704933
Was ist denn da los?
Das Trekkingprofil ist so ausgelegt, dass es auch im Ausland funktioniert und dort liegen Fernradwege durchaus häufiger auf highway=trunk und deshalb wertet das Profil die Kombination aus bicycle=yes und highway=trunk als bedingt befahrbar:
Code:
# actuals roads are o.k. if we have a bike hint
#
     if ( highway=trunk|trunk_link         ) then ( if isbike then 1.5 else 10  )
 
Heute hab ich mal mit bikerouter nachgesehen, und je nach Profil leitet der mich auch auf die B51:
Das liegt in Deinem konkreten Fall aber daran, daß Du Start- und Zielpunkt recht alternativlos (topologisch) eng an die Bundesstraße gesetzt hast. Mit etwas mehr Abstand = Wegoptionen sieht das auch im Trekkingprofil anders aus: Klick
 
Das liegt in Deinem konkreten Fall aber daran, daß Du Start- und Zielpunkt recht alternativlos (topologisch) eng an die Bundesstraße gesetzt hast. Mit etwas mehr Abstand = Wegoptionen sieht das auch im Trekkingprofil anders aus: Klick
Ob und wie gut das Trekkingprofil 4-spurige Straßen vermeidet, ist für mich erstmal nebensächlich. Bei den Bikerouter-Profilen würde keines der Profile die ich bisher verwendet habe, mich über die B51 leiten. Das ist erstmal ganz beruhigend. Ich habe vor den Routing-Profil-Erstellern hochgradig Respekt - ganz schön komplex.

Ich habe heute gelernt:
  • die Daten sind korrekt - man dürfte die B51 lang. Krass.
  • manche Profile routen drumherum, andere nicht
 
Dass die QR-Code Erstellung die Straight-Lines nicht unterstützt ließe sich vllt. mit weniger Aufwand beheben? Wäre nach meiner Einschätzung wahrscheinlich schonmal eine gute "80% Verbesserung mit 20% des Aufwandes"... 😅 Wobei Du da ja glaube ich auch was vorgefertigtes nutzt für die QR-Code-Generierung, evtl. müsste ich dann vllt. auch hier das Feature Request an anderer Stelle einbringen.

Hierfür kommt kurzfristig ein Fix. Ich baue gerade den QRCode-Export auf ein allgemeineren Share-Dialog um. Die neue Variante des QRCodes triggert dann nicht mehr den Download direkt, sondern öffnet die Routenplanung und zeigt den Export-Dialog an - so hat man noch die Möglichkeit ein anderes Export-Format auszusuchen oder sogar die Route zu ändern usw.
 
Hierfür kommt kurzfristig ein Fix. Ich baue gerade den QRCode-Export auf ein allgemeineren Share-Dialog um. Die neue Variante des QRCodes triggert dann nicht mehr den Download direkt, sondern öffnet die Routenplanung und zeigt den Export-Dialog an - so hat man noch die Möglichkeit ein anderes Export-Format auszusuchen oder sogar die Route zu ändern usw.
Sehr cool, das klingt super und nach einem sinnvollen Umbau 🙏

Einziger Nachteil der mir da einfällt ist dass sehr lange Routen die bei mir am Desktoprechner schon ne Weile "Denkzeit" brauchen, dann u.U. auf dem Smartphone noch etwas mehr "Bedenkzeit" brauchen um als File exportiert werden zu können. Kann man aber wahrsch. gut umgehen solange man sich einzwei Zwischenpunkte mehr auf lange Distanzen setzt.

(Mir ist nur ab und zu aufgefallen, dass ab einer gewissen Langstrecke zwischen 2 Punkten die Bedenkzeit ordentlich ansteigt, also nicht-linear, was auch Sinn ergibt, da sich so Wegfindungslösungen über die Distanz um ein Vielfaches komplexer gestalten.)
 
Hier stand unvollständig analysierte Thesen :( Sorry.
Mein GPX Editor macht die gpx'e kaputt, wenn man die editiert und abspeichert. Beim wiederöffnen kommt dann eine Fehlermeldung bzgl link tag Syntax error aus'm Brouter. Sorry für die Verwirrung.
Wer hat einen Tip für einen guten GPX Editor?
 

Anhänge

  • link_tag.jpg
    link_tag.jpg
    89,5 KB · Aufrufe: 73
Zuletzt bearbeitet:
Und das Schöne: Man kann sich das einfach als Baselayer oder Overlay-Layer im bikerouter-web einbinden:

Code:
https://sgx.geodatenzentrum.de/wmts_basemapde_schummerung/tile/1.0.0/de_basemapde_web_raster_hillshade/default/GLOBAL_WEBMERCATOR/{z}/{y}/{x}.png

Anhang anzeigen 1685493

Noch ein kleiner Overlay-Tipp den ich seit einiger Zeit nutze:
Ich hab mir die ESRI Weltbilder nochmal als eigenen Overlay-Layer eingebunden, so kann ich z.B. meinen Favoritenlayer CyclOSM mit Luftbildern kombinieren und habe so etwas mehr Kontext und erkenne z.B. auch auf niedrigen Zoomstufen so schneller wo Felder, wo Häusersiedlungen etc. sind - für mich ein guter Mix ("best of both worlds"):

Code:
https://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer/tile/{z}/{y}/{x}.png

bikerouter_de.png
bikerouter_de.png
 
Zurück
Oben Unten