MTB-News.de

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

Danke @momentmal für den Tip.
Hier sind einige meiner Custom Layers:

Code: 
CX berlin    https://tiles.cxberlin.net/tile/{z}/{x}/{y}.png    Overlay
F4    https://tile1.f4map.com/tiles/f4_2d/{z}/{x}/{y}.png    Layer
Komoot    https://a.tile.hosted.thunderforest.com/komoot-2/{z}/{x}/{y}.png    Layer
mtb popularity    https://connecttile.garmin.com/MOUNTAIN_BIKING/{z}/{x}/{y}.png    Overlay
Positron    https://cartodb-basemaps-a.global.ssl.fastly.net/light_all/{z}/{x}/{y}@2x.png    Layer
ride heat    https://proxy.nakarte.me/https/heatmap-external-b.strava.com/tiles-auth/ride/hot/{z}/{x}/{y}.png?px=256    Overlay
road popularity    https://connecttile.garmin.com/ROAD_CYCLING/{z}/{x}/{y}.png    Overlay
run heat    https://proxy.nakarte.me/https/heatmap-external-b.strava.com/tiles-auth/run/hot/{z}/{x}/{y}.png?px=256    Overlay

EDIT: Komoot Layer über XYZ funktioniert nicht mehr
 
Zuletzt bearbeitet:

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
Overlay "OpenrailwayMap" anzeigen lassen? (ist bei Überlagerungen-Weltweit drin)


Ist zwar jetzt ziemlich OT, aber erstens finde ich kein passendes Thema und zweites denke ich, dass ich hier noch am ersten eine Antwort bekomme. ..deshalb sorry vorab für die Frage!
Kann man bei JOSM die Swisstopo Landeskarte, wie sie auch im bikerouter als Ebene ausgewählt werden kann, als Hintergrund einblenden? Falls ja, was muss ich da eingeben?
 
scratch_a schrieb:
Kann man bei JOSM die Swisstopo Landeskarte
Zum Vergrößern anklicken....


1. "Imagery" → "Imagery Preferences"
2. "+ TMS" Button klicken (unten rechts)
3. im Dialogfenster Punkt 1 genau lesen
4. Folgendes in die Felder eingeben:


URL: https://wmts.geo.admin.ch/1.0.0/ch.swisstopo.pixelkarte-farbe/default/current/3857/{zoom}/{x}/{y}.jpeg
Max Zoom: 19
Name: Was immer du möchtest

5. Speichern
6. Layer auswählen, done.



1684127513608.png



1684127569571.png
 
@Marcus
DaMoasta schrieb:
Mit Locus Maps (Pro Classic) hält es, je nach Einsatzbedingungen, ca. 6-8h, hab im Flugmodus auch schon 9h geschafft. Display ist so eingestellt, dass es 15 Sekunden nach der Anweisung wieder aus geht. Für mich überraschender Weise ist das Folgen eines heruntergeladenen Tracks von z.B. bikerouter.de energieaufwändiger. Hier schaltet das Display sehr oft ein, wenn z.B. der Untergrund wechselt, oder eine anderer OSM-Tag den Teil der Strecke als eigenen Abschnitt definiert. Navigiert man direkt über Locus (mit brouter), bleibt das Display die allermeiste Zeit aus und meldet sich nur bei Abbiegehinweisen.
Zum Vergrößern anklicken....
Kannst Du dazu was sagen? Ich würde die Zahl der Routinganweisungen auch gern auf das unbedingt notwendige begrenzen...
 
Hi!

Mir ist gestern aufgefallen, dass der GPX-Direktexport/Downloadlink via QR-Code nicht mehr existiert - man kann nur noch den Link auf die geplante Route teilen (via QR-Code), und dann am Smartphone runterladen.
Grundsätzlich das gleiche, allerdings muss so die Route erneut fürs Smartphone gerechnet werden, das ist bissl umständlicher als vorher.

Wirds den GPX-Downloadlink zum Teilen via QR-Code wieder geben?
 
Nein, ich gehe nicht davon aus.

Der Grund:

Der bisherige QR Code enthielt einen Link auf das rohe Ergebnis der BRouter-Routing-Engine. Das war im Grunde über viele Jahre der Standard und ist auch an sich in Ordnung. Problem bei dieser Variante: Luftlinien-Routing wurde hierbei nicht berücksichtigt. Hatte man also Luftlinien-Segmente in der Route, war der Export über den QR Code unvollständig.

Der jetzige QR Code nutzt die Export-Funktion, welche vor einiger Zeit in die BRouter-Web Anwendung (also die Webapp, nicht die Routing-Engine) Einzug gehalten hat. Hierbei werden auch die Luftlinien-Segmente korrekt berücksichtigt.

Da die BRouter-Engine Luftlinien-Segmente aktuell nicht unterstützt, lässt sich ein Export der vollständigen Route nicht sicherstellen. Solange das nicht der Fall ist, sehen wir den bisherigen Export auch nicht wieder - so jedenfalls meine Vermutung.

Ein Problem, welches beide Varianten teilen: Routenberechnungen für manuell angepasste Profile können nicht geteilt werden. Aber es gibt bereits einige Ideen, wie auch dieses Problem zumindest abgeschwächt werden kann.
 
Zuletzt bearbeitet:
Vielen Dank! Das war mir so alles nicht wirklich klar :daumen:
Also bei angepassten Profilen am besten direkt als GPX speichern und dann das GPX aufs Smartphone/Wahoo schicken.
 
Das mit dem QR Code ist echt Schade. Bei mir hat der Export zu Orux inkl. Abbiegehinweisen damit immer super funktioniert. Empfand es als eine sehr elegante Lösung, zumal man per Bluetooth auf Android keine gpx Dateien übertragen kann. Klar geht es auch so ist aber jetzt halt mit zwar überschaubaren aber doch unnötigem Mehraufwand verbunden.

Warum immer gleich alles wegmachen? Kleinen Warnhinweis dran, welche Einschränkungen damit verbunden sind und drin lassen. Ich hoffe es kommt wieder. Oder kann man irgendwo eine alte Version finden die das Feature noch unterstützt?
 
Du kannst den Download nach dem Öffnen des QR Code-Links mit nur einem einzigen Klick in dem erscheinenden Dialog starten.

Ich tue mich etwas schwer mit dem Begriff "Mehraufwand" wenn es am Ende des Tages nur ein Tap auf den Export-Button ist - alles andere verhält sich ja gleich.
 
Marcus schrieb:
Du kannst den Download nach dem Öffnen des QR Code-Links mit nur einem einzigen Klick in dem erscheinenden Dialog starten.

Ich tue mich etwas schwer mit dem Begriff "Mehraufwand" wenn es am Ende des Tages nur ein Tap auf den Export-Button ist - alles andere verhält sich ja gleich.
Zum Vergrößern anklicken....
Leider vergisst er dabei (also beim Neuaufruf des QR Links auf dem Smartphone) den auf dem PC zuvor zugewiesenen turnInstructionMode (steht wohl defaultmäßig auf auto-choose), sodass man diesen auf dem Smartphone zuerst explizit zuweisen muss, sonst werden keine Turn-by-Turn Wegpunkte in die Export-GPX-Datei geschrieben. Dann sind es leider ein paar Schritte mehr.

Vielleicht könnte man den auto-choose Mode durch einen fest zugewiesenen Mode ersetzen, dann wäre es in der Tat kein echter Mehraufwand, weil dann das manuelle Neuzuweisen entfiele. Ist aber nur relevant, falls man die Turn-by-Turn Anweisungen explizit benötigt: die eigentliche GPX-Datei wird ja sofort runtergeladen, aber mitunter ohne Cue-Sheets.
 
Exakt. Aktuell muss ich nach dem Link des QR Codes noch das Profil MTB/RR und den turninstructionmode setzen, dann auf Neuberechnung warten dann auf Export dann den Namen des Exports am Smartphone eintippen. Es ist natürlich kein Weltuntergang aber es war vorher eleganter. Scan->Download. Fertig.
 
Marcus schrieb:
Auch dafür ist bereits eine Lösung angedacht.
Zum Vergrößern anklicken....
Wenn wir schon bei Dingen sind die aktuell mittels des neuen QR Codes fehlen: Das Vergeben des Namens welchen ich normalerweise direkt beim Generieren des QR Codes am PC mit aus der Zwischenablage einfüge (und so direkt via QR Code in der .gpx und damit auch in der Wahoo App ankam) wird jetzt nicht mehr mitgegeben, so dass man die Benennung am Smartphone nochmal nachholen muss. Das ist tatsächlich ziemlich nervig und ein starker Rückschritt, weil ich meist recht viel Aufwand in den Namen stecke, da ich dort verkürzt nochmal wichtigste Eckdaten der Route mit einfüge.

Dennoch ist der Umbau sinnvoll, eben weil ich auch die Luftlinienfunktion stets vermisst habe in der über QR Code generierten Route.
 
Zuletzt bearbeitet:
Folgendes Problem, wenn ich eine sehr lange Strecke planen möchte, z. B. nur um mal gesamt zu sehen wie, wo, usw. dann dauert es entweder sehr, sehr lange bis es berechnet wurde oder es geht gar nicht, time out oder so.
Kann man da was dagegen tun, außer die Strecke in Teilen zu berechnen? Ich meine, bei Komoot geht das ruck zuck - ist aber vielleicht nicht vergleichbar?
Auf dem Ipad funktionieren so lange Strecken nicht, auf dem Rechner dauert es ewig.
Beispiel von Nordbayern an die Nordsee.
 
r4n schrieb:
Kann man da was dagegen tun, außer die Strecke in Teilen zu berechnen?
Zum Vergrößern anklicken....
Nein bis jein. Die Berechnung läuft serverseitig, demnach sollte es eigentlich keinen Unterschied zwischen den Endgeräten geben. Mit der Erfahrung bist du allerdings trotzdem nicht allein.
Was ich eben extra noch mal getestet habe: Die Profile sind deutlich unterschiedlich schnell. "Kürzeste Route" ist aus naheliegenden Gründen sehr schnell, wenn nicht sogar am schnellsten, während z.B. "Gravel Quaelnix (wenig Verkehr)" sehr langsam ist. Zur Einordnung: Das waren eben für Dresden-Rostock 13 vs 40 Sekunden.
Kann natürlich auch alles Zufall sein. Womöglich planen grade in der Mittagspause viele Leute ihre Feierabendrunde...oder so. Und Komoot ist schließlich kommerziell, die müssen ja auch irgendwas bieten fürs Geld.
 
Genau, je nach Profil variiert das stark. Bin leider kein Wegfindungs-Algorithmusexperte.. Wäre natürlich großartig, wenn BRouter von Arndt Brenschede noch weiter auf Geschwindigkeit optimiert werden könnte, denn ich habe das gleiche Problem, gerade wenns um Berechnung über Langstrecke mit wenig Höhenmetern (zB mein geliebtes Trekking-Valley Profil) geht, stoße ich auch öfters mal an die Grenzen von BRouter. Taste mich dann auch stückweise durch.

Ich weiß auch nicht, inwiefern da die auf @Marcus Server Bottlenecks bestehen könnten, meine aber im Kopf zu haben dass der Server schon ordentlich Dampf hat und wenn gerade nicht viele Anfragen bestehen das Bottleneck dann doch eher BRouter selbst (oder die Einlesezeit der ganzen Kartendaten oder der pro Anfrage bereitgestellte Arbeitsspeicher) ein Bottleneck darstellen könnte.

Vllt. gibts ja noch irgendwo optimierungspotential und vllt. kann man die Timeouts / RAM-Budgets ggf. auch etwas höher setzen? Verstehe natürlich, dass das für ein Hobbyprojekt was eigtl @Marcus zunächst mal für sich selbst bereitstellt man da keine Ansprüche wie an kommerzielle Services stellen kann und die Serverkosten auch im Rahmen bleiben sollten.

Wenns so sein sollte, dass es doch noch Luft nach oben gäbe was Schnelligkeit und Abbruchquote angeht, die aber mit Mehrkosten verbunden sind, könnten wir ja ein "Crowdsourcing" erwägen oder z.B. ein Ko-Fi Account mit dem wir Marcus regelmässig ein wenig Taschengeld fürs Hosting zukommen lassen können ;-)
 
Hier dürfte es kurzfristig nicht viel Spielraum geben.

Es müsste schon zu einer Verbesserung in der Höhe mindestens einer Größenordnung kommen. Ob man am Ende 40 Sekunden oder 30 Sekunden wartet, ist nämlich auch komplett egal – beides erscheint nicht akzeptabel.

Mit ein bisschen mehr CPU hier und etwas mehr RAM dort ist das aber einfach nicht machbar.

Ich weiß aber auch, dass das Planen von Touren mit hunderten Kilometern ohne Zwischenpunkte die absolute Ausnahme ist.

Schaut euch mal dieses Histogramm an (X-Achse: Antwortzeit BRouter Engine, Maximalwert sind 300 s bzw. 5 Minuten (maximale Rechenzeit bevor Routing abgebrochen wird), Y-Achse: Anzahl der Routinganfragen):

brouter-histogram-300000ms.png

Ihr seht nichts? Ich auch nicht.

Schauen wir genauer hin und betrachten alle Routing-Anfragen, welche innerhalb von 10 Sekunden beantwortet werden:

brouter-histogram-10000ms.png


Ah, es ist etwas erkennbar.

Schauen wir noch genauer hin und betrachten nur die Anfragen, welche unter 1 Sekunde laufen:

brouter-histogram-1000ms.png


Ihr seht (bzw. könnt anhand des Histogramms erahnen), dass es durchaus Routing-Anfragen gibt, welche auch mal ein paar Sekunden brauchen. Die sind aber in der Anzahl verschwindend gering. Die allermeisten Routing-Anfragen sind in unter 100 Millisekunden beantwortet (Maximum im Diagramm ist bei 10 ms - 20 ms).

Optimierungen an der Stelle nehme ich natürlich liebend gerne mit, aber in der Kosten-Nutzen-Betrachtung zeigt sich schnell, dass Verbesserungen an anderen Stellen (z. B. UX) deutlich sinnvoller sein dürften als hier etwas mehr Geld auf die Hardware zu werfen und am Ende vielleicht gerade mal 10% schneller zu sein.
 
Bitte beachte unsere Verhaltensregeln beim Antworten. Danke 🙂
Zurück
Oben Unten