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

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
Ob man am Ende 40 Sekunden oder 30 Sekunden wartet, ist nämlich auch komplett egal – beides erscheint nicht akzeptabel.

Sehe ich auch so - deswegen hab ich das mit dem Hardware-Flaschenhals auf deinem Server nur als zusätzliche Möglichkeit angeführt, da ich auch eher denke, dass im BRouter Wegfindungsalgorithmus im Moment vllt. einfach gewisse Limitationen für diese Fälle herrschen. Über die Distanz erhöht sich die Komplexität und die Anforderungen an die Wegfindung natürlich um mehrere Größenordnungen.

Sieh meinen Kommentar oben auch bitte nicht als Form irgendeiner Forderung, Ziel war es eher einfach etwas mehr über die Hintergründe der Limitationen von BRouter oder anderen Einflussfaktoren die zu Fehlern / abgebrochenen Berechnungen führen zu erfahren.

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.

Ebenfalls völlig verständlich und sinnvoll so vorzugehen.

Antwortzeit BRouter Engine, Maximalwert sind 300 s bzw. 5 Minuten (maximale Rechenzeit bevor Routing abgebrochen wird)

Routen zwischen 2 Punkten werden allerdings gerne mal bei weitaus niedrigeren Rechenzeiten mit Fehlermeldungen abgebrochen. Und das geht je nach Profil, Beispiel Trekking-Valley, schon einigermaßen schnell z.B. mit einer Route 180 km Luftlinie über die Alpen, z.B. Bregenz-Lugano, während es dann manchmal ein paar km kürzer einwandfrei funktioniert und das in ein paar Sekunden - Da scheints schon mehr also nur das "Problem" der Rechenzeit von maximal 500 Sekunden zu geben, sondern irgend ein inkonsistentes Verhalten dass der Server wohl gerade zu viel zu tun hat und nicht ausreichend Rechenpower für die Anfrage bereitstellen kann (scheinbar wird in dem moment gerade ein anderer Task priorisiert?)

Mit bissl Warten hab ich für Langstrecken Routenberechnung eigtl. auch nicht so das Problem. Hab aber eigtl. nie das Problem dass die Zeit von 500s nicht reicht, sondern öfters mal solche Fehler kommen, deren genauen Hintergrund kenne ich aber auch nicht. Hängt evtl. auch wieder mit der Komplexität des jeweiligen Profils ab.. Hab gerade über die Suche gesehn, dass der Fehler schonmal erwähnt wurde, vllt. hast Du da ja schon ein paar Erkenntnisse gesammelt @Marcus?

bikerouter_de_error.png


Komoot verwendet afaik GraphHopper und GraphHopper unterstützt contraction hierarchies. Ob die sich mit vertretbarem Aufwand in BRouter einbauen ließen, kann ich dir aber leider nicht beantworten.

Interessant, Danke für die Info 👌
Letzten Endes ist ja wie Marcus schon sagt seine Instanz völlig geeignet für 99,(man setze hier eine beliebige Anzahl von 9 ein) % der Usecases und daher macht es natürlich auch wenig Sinn da zu viel Energie reinzustecken. Denke auch, dass eine Verbesserung der Schnelligkeit auf Langstrecke eher mit einer Verfeinerung von BRouter selbst erreicht werden könnte. Da weiß ich allerdings auch nicht, ob Arndt weiter aktiv an BRouter entwickelt.

Danke auf jeden Fall für die Insights schonmal 🙏
 

Anhänge

  • 1684866219113.png
    1684866219113.png
    44,6 KB · Aufrufe: 14
Zuletzt bearbeitet:
mit vertretbarem Aufwand in BRouter einbauen ließen

Ich denke mal, da müsste man schon einmal alles komplett umkrempeln.

Und - ohne viel von den Innereien zu verstehen - würde ich darauf tippen, dass das alles sehr unhandlich werden würde, im Sinne von Speicherplatzbedarf für vorprozessierte Daten sowie Zeitdauer der Erstellung dieser Daten - mit 4x täglich dürfte es dann aus sein.

Und, viel schlimmer, man kann dann vermutlich nicht mal so eben derart detaillierte Profile wie jetzt bauen, ohne selbst auch gleichzeitig die Pipeline zur Routingdatenerstellung unter Kontrolle zu haben. (wie gesagt, eine Vermutung).
 
Re Watchdog Error: ich werde der JVM noch mal ein paar Bytes mehr Speicher spendieren ... der Grund ist in diesen Fällen, dass dem Prozess der verfügbare Speicher ausgeht (entweder ist da etwas zu komplex im Routing oder es ist ein Bug).
 
Hallo Zusammen,
ich bin gerade etwas am Planen für eine eventuelle, längere Tour dieses Jahr und würde gerne wissen, welches Profil bei Bikerouter dafür am besten geeignet wäre. Evtl. auch mit Anpassungen.
Meine Kriterien wären folgende:
  • Vermeidung von Höhenmetern
  • Route, die schnelles Vorankommen ermöglicht, evtl. Radwege, Long Distance Radwege?
  • Jedoch so wenig Straßen mit viel Verkehr, gefährliche Straßen wie z. B. Bundesstraßen
  • Es darf auch Offroad dabei sein, es sollte aber nicht Offroad sein, damit Offroad gefahren wird, also nicht extra Umwege.
Die Route soll in etwa vom Fichtelgebirge nach Cuxhafen gehen und das in relativ kurzer Zeit von drei Tagen Fahrt. Übernachtung bevorzugt auf Campingplätzen, Kein Kochen, Verpflegung durch Geschäfte, Restaurants.

Und vielleicht können ein paar Leute, die mehr Erfahrung haben im Planen solcher Routen ein paar Kniffe verraten. Wie checkt ihr die Route, nach welchen Kriterien etc. damit ihr nicht auf Strecken fahrt, die ihr nicht fahren wollt z.B.?
 
@r4n: Ich habe gestern Stunden an der Planung einer 200km Route gesessen, erst viele Profile ausprobiert, Rennrad sehr wenig Verkehr und FFMbyBycycleLong Distance waren meine Favoriten, dann habe ich diese Profile durchprobiert inklusive Varianten. Das dauert leider etwas, beide Profile haben Höhenmeter gut vermieden, allerdings variierte die erwartete Zeit von 10,5 bis 13,5 Stunden, Höhenmeter auch beachten! Hilfreich auch die Aufschlüsselung zum Asphaltanteil.
Die Favorisierte Linie habe ich dann anschließend etwas angepasst, die Strecke aus Ortschaften rausgezogen. etc. Teils wird dann allerdings die gesamte Reststrecke auch geändert.
Als die Strecke dann grob stand habe ich sie in komoot importiert. Da konnte ich dann besser Detailannpassungen machen, das geht dort schneller und ändert nur die direkt angrenzende Route, bikerouter legt oft eine komplett neue Teilstrecke an.
Was bei den Routingprofilen im großen und ganzen Sinn macht, ist im kleinen Detail nicht immer sinnvoll. Sie schicken einen gerne in Ortschaften in Seitenstraßen, bei kleinen Orten bevorzuge ich die Hauptstraße, die Profile schicken einen auch gerne auf Landstraßen direkt neben Autobahnen oder Radwege an vielbefahrenen Bundesstraßen. Lässt sich hinterher alles vermeiden.

Allerdings verplempert man auch viel Zeit mit der Planung. Bewährt ist meist doch eine schnelle Planung mit Bikerouter/Komoot und auf der Tour fahre ich dann spontan parallele Wege und lasse die Karte am Navi zur Orientierung laufen. Erst vor Ort weiß man tatsächlich, ob der Radweg eine schöne Variante ist oder eine Beleidigung unseres Sports.
 
Wer
benutzt, hat die Kontrolle über seine Jogginghosen verloren...
na dann verratet mir doch gerne mal wie ihr das anstellt. Bikerouter ist ein super tool, aber so geduldig bei jeder minimalen Streckenänderung auf die Neuberechnung zu warten bin ich dann doch nicht. Unterwegs bevorzuge ich Locus , gibt es leider nicht für den Desktop. Also Meister der Jogginghosen, wie stellt ihr das an?
 
@r4n, ich hab dir mal als Inspiration das Ergebnis vom Gravel "quaelnix" (minimized traffic) Profil ohne Zwischenpunkte angehängt (die assume_wet_conditions und consider_elevation Optionen waren aktiv).
 

Anhänge

  • Wunsiedel -_ Cuxhaven (695.7km).gpx
    881,5 KB · Aufrufe: 28
@r4n: Ich habe gestern Stunden an der Planung einer 200km Route gesessen, erst viele Profile ausprobiert, Rennrad sehr wenig Verkehr und FFMbyBycycleLong Distance waren meine Favoriten, dann habe ich diese Profile durchprobiert inklusive Varianten. Das dauert leider etwas, beide Profile haben Höhenmeter gut vermieden, allerdings variierte die erwartete Zeit von 10,5 bis 13,5 Stunden, Höhenmeter auch beachten! Hilfreich auch die Aufschlüsselung zum Asphaltanteil.
Die Favorisierte Linie habe ich dann anschließend etwas angepasst, die Strecke aus Ortschaften rausgezogen. etc. Teils wird dann allerdings die gesamte Reststrecke auch geändert.
Als die Strecke dann grob stand habe ich sie in komoot importiert. Da konnte ich dann besser Detailannpassungen machen, das geht dort schneller und ändert nur die direkt angrenzende Route, bikerouter legt oft eine komplett neue Teilstrecke an.
Was bei den Routingprofilen im großen und ganzen Sinn macht, ist im kleinen Detail nicht immer sinnvoll. Sie schicken einen gerne in Ortschaften in Seitenstraßen, bei kleinen Orten bevorzuge ich die Hauptstraße, die Profile schicken einen auch gerne auf Landstraßen direkt neben Autobahnen oder Radwege an vielbefahrenen Bundesstraßen. Lässt sich hinterher alles vermeiden.

Allerdings verplempert man auch viel Zeit mit der Planung. Bewährt ist meist doch eine schnelle Planung mit Bikerouter/Komoot und auf der Tour fahre ich dann spontan parallele Wege und lasse die Karte am Navi zur Orientierung laufen. Erst vor Ort weiß man tatsächlich, ob der Radweg eine schöne Variante ist oder eine Beleidigung unseres Sports.

Ich kann da eigentlich nicht mitreden, weil unsere Touren erstens viel zu kurz sind, als dass wir da lange warten müssten und zweitens habe ich meist eine relativ genaue Vorstellung, wo die Tour lang gehen soll und somit viele Zwischenpunkte.
Aber so wie ich es bei dir lese und verstehe, würde ich auf der berechneten Route einfach z.B. vor und nach dem Ort einen Zwischenpunkt setzen und dann innerhalb der Ortschaft die Route so ziehen wie ich es mir vorstelle. So würde er nicht alles komplett neu durchrechnen müssen und auch nicht die anderen Abschnitte ändern. Also erstmal lange Abschnitte grob planen lassen und dann entsprechend in die Details gehen und optimieren.
Auf die Idee, in Bikerouter zu starten und dann in Komoot zu vervollständigen wäre ich jedenfalls nicht gekommen und kann mir auch nicht vorstellen, dass es da einfacher/schneller geht. Aber wie gesagt, meine Bedürfnisse unterscheiden sich da signifikant und von dem her kann es auch sein, dass mein Anwendungsfall auf deinen überhaupt nicht passt. :ka:
 
Ich kann da eigentlich nicht mitreden, weil unsere Touren erstens viel zu kurz sind, als dass wir da lange warten müssten und zweitens habe ich meist eine relativ genaue Vorstellung, wo die Tour lang gehen soll und somit viele Zwischenpunkte.
Aber so wie ich es bei dir lese und verstehe, würde ich auf der berechneten Route einfach z.B. vor und nach dem Ort einen Zwischenpunkt setzen und dann innerhalb der Ortschaft die Route so ziehen wie ich es mir vorstelle. So würde er nicht alles komplett neu durchrechnen müssen und auch nicht die anderen Abschnitte ändern. Also erstmal lange Abschnitte grob planen lassen und dann entsprechend in die Details gehen und optimieren.
Auf die Idee, in Bikerouter zu starten und dann in Komoot zu vervollständigen wäre ich jedenfalls nicht gekommen und kann mir auch nicht vorstellen, dass es da einfacher/schneller geht. Aber wie gesagt, meine Bedürfnisse unterscheiden sich da signifikant und von dem her kann es auch sein, dass mein Anwendungsfall auf deinen überhaupt nicht passt. :ka:
Mit Zwischenpunkten habe ich es auch probiert, leider berechnet bikerouter da die Strecke auch neu. Ich müsste also dreimal warten, (1) am Anfang der Ortschaft, (2) am Ende und (3) die neue Route innerhalb der Ortschaft, nur (3) ist dabei schnell und die anderen Änderungen dauern mehr als eine Minute.
Kann aber auch sein, dass es am Profil "Rennrad sehr wenig Verkehr" in Kombination mit dem starken Wegenetz im Rhein Main Gebiet einfach nicht gut läuft. Das mag in einer anderen Gegend und mit anderem Profil schneller gehen.
Wenn ich ausschließlich mit Bikerouter planen wollte, müsste ich wohl erst eine durchgehende Route planen und diese dann auf mehrere Teilstrecken aufteilen, diese anschließend einzeln optimieren und am Ende die einzelnen GPX Segmente zusammenfügen. Da erscheint mir Komoot in der Nachbearbeitung als praktischeres Tool.

Aber wer weiß, dank der fleißigen Entwicklung läuft das vielleicht auch in ein paar Monaten rund.
 
Wenn ich ausschließlich mit Bikerouter planen wollte, müsste ich wohl erst eine durchgehende Route planen und diese dann auf mehrere Teilstrecken aufteilen, diese anschließend einzeln optimieren und am Ende die einzelnen GPX Segmente zusammenfügen.
Wie wäre es, wenn du stattdessen mit einem Luftlinienrouting zwischen Start und Ziel beginnst und dann häppchenweise Zwischenpunkte einfügst und das Luftlinienrouting auf den kurzen Teilstrecken wieder abschaltest?
Aber wer weiß, dank der fleißigen Entwicklung läuft das vielleicht auch in ein paar Monaten rund.
An der Berechnungsdauer wird sich auf absehbare Zeit nichts ändern.
 
Wenn ich ausschließlich mit Bikerouter planen wollte, müsste ich wohl erst eine durchgehende Route planen und diese dann auf mehrere Teilstrecken aufteilen, diese anschließend einzeln optimieren und am Ende die einzelnen GPX Segmente zusammenfügen
Das ist imho der falsche Ansatz. Setze die Punke, wo Du unbedingt vorbeifahren möchtest, und optimiere dann dazwischen. Bei dieser Vorgehensweise hast Du keinmal eine komplette Neuberechnung über die gesamte Strecke, sondern immer nur Neuberechnungen der angepaßten Teilstrecken.
In der Zeit, wo Du aus dem Brouter exportierst und in Komoot importierst, kannst Du auch drölfzig mal Neuberechnungen der Gesamtstrecke durchführen lassen ... oder Deine Jogginghose waschen und bügeln ;)
 
Und vielleicht können ein paar Leute, die mehr Erfahrung haben im Planen solcher Routen ein paar Kniffe verraten. Wie checkt ihr die Route, nach welchen Kriterien etc. damit ihr nicht auf Strecken fahrt, die ihr nicht fahren wollt z.B.?
Lange Strecken in kurzer Zeit, da plane ich gar nix!
Für sowas nehm ich fertige Strecken von https://cycling.waymarkedtrails.org/ und den Derivaten. Und stelle mir aus denen was zusammen.
Jüngst hab ich mir so fürs letzte Brückenwochenende Prag-Freising zusammengestückelt.
 
  • Vermeidung von Höhenmetern
  • Route, die schnelles Vorankommen ermöglicht, evtl. Radwege, Long Distance Radwege?
  • Jedoch so wenig Straßen mit viel Verkehr, gefährliche Straßen wie z. B. Bundesstraßen
  • Es darf auch Offroad dabei sein, es sollte aber nicht Offroad sein, damit Offroad gefahren wird, also nicht extra Umwege.
Die Route soll in etwa vom Fichtelgebirge nach Cuxhafen gehen und das in relativ kurzer Zeit von drei Tagen Fahrt. Übernachtung bevorzugt auf Campingplätzen, Kein Kochen, Verpflegung durch Geschäfte, Restaurants.

Und vielleicht können ein paar Leute, die mehr Erfahrung haben im Planen solcher Routen ein paar Kniffe verraten. Wie checkt ihr die Route, nach welchen Kriterien etc. damit ihr nicht auf Strecken fahrt, die ihr nicht fahren wollt z.B.?

Ich plane eigtl. sehr oft mit identischen Anforderungen (wobei mir schnelles Vorankommen eigtl. nicht so wahnsinnig wichtig ist, sonst würde ich wahrsch. mehr Straßen fahren) und bin mit Trekking-Valley sehr glücklich (abgesehen von der Berechnungszeit wenn 2 Punkte über 150km auseinanderliegen) - Aber so ein-zwei-drei Zwischenpunkte bekommt man ja meist hin. Mit aktivem CyclOSM Layer dann noch bissl abgleichen ob ein paar Teilsegmente vllt auf noch mehr Radwege (blaue durchgezogene Linien auf CyclOSM für geteerte, blau-gestrichtelt für Gravel) optimiert werden können oder scheinbar unvermeidbare Straßenabschnitte (meist kleine Pässe) nicht vllt doch ein paar ruhige Gravel-Alternativen bieten, auch wenn das Höhenmeter Konto damit vllt. etwas steigt. Viel Erfolg!
 
Zuletzt bearbeitet:
Lange Strecken in kurzer Zeit, da plane ich gar nix!
Für sowas nehm ich fertige Strecken von https://cycling.waymarkedtrails.org/ und den Derivaten. Und stelle mir aus denen was zusammen.
Jüngst hab ich mir so fürs letzte Brückenwochenende Prag-Freising zusammengestückelt.
eigentlich eine gute Idee. Leider sind die gpxe dort teilweise ziemlich unsauber. Dieser hier z.B:
https://hiking.waymarkedtrails.org/#route?id=124118&type=relation&map=11.0/50.1103/12.0782
Da bin ich auf der sicheren Seite, wenn ich im Brouter das schnell zusammenklicke.
 
@quaelnix @CC. meine Strecke ist nicht direkt Luftlinie, spare viele Höhenmeter. Euren Tipps kann ich aber einen Workaround für besonders lange Strecken entnehmen. Strecke mit bikerouter.de planen, neues Fenster öffnen und genau die vorgeschlagene Strecke Stückweise nachplanen und gegebenenfalls anpassen und optimieren. Dann dürfte das von der Berechnungszeit auch passen.
 
meine Strecke ist nicht direkt Luftlinie, spare viele Höhenmeter.
Ich meinte auch eher so:
beeline.jpg

Den groben Streckenverlauf muss man sich halt entweder aus den Fingern saugen oder man lässt sich zunächst von einem anderen Router (Komoot, ...) inspirieren, der schneller ein Ergebnis liefert.
Strecke mit bikerouter.de planen, neues Fenster öffnen und genau die vorgeschlagene Strecke Stückweise nachplanen
Ja, so mach ich es im Prinzip auch, aber auf bikerouter.de funktioniert das aktuell leider nicht, da die Berechnung bei so langen Strecken fast immer mit operation killed by thread-priority-watchdog after xx seconds abbricht.
 
Ich habe jetzt ein paar weitere CPU-Cores dazugestellt. Guck mal ob's jetzt seltener zu den Abbrüchen kommt

Hintergrund: BRouter hat einen Thread-Pool für aktive Berechnungen und wirft den jeweils ältesten Thread weg, wenn ein neuer Request reinkommt und der Pool voll ist; die Größe des Pools kann man über verfügbare CPU-Cores und ein dazu passendes Config-Setting anpassen.

Das Routing wird dadurch nicht schneller, es lassen sich aber mehr Anfragen parallel bearbeiten.

Die verfügbare Rechenkapazität lässt sich so nahezu beliebig erhöhen, es ist am Ende aber natürlich ein finanzieller Constraint.
 
Letztes Jahr war ich in heftige Planungen für Deutschland- Ungarn- Rumänien involviert und habe nicht einmal einen Watchdog gesehen oder mich bei Neuberechnungen gelangweilt. Was hab ich verkehrt gemacht?
Brauchen wir jetzt ein Spendenkonto?
 
Zurück
Oben Unten