Hallo Geli,
nein, einfach das Profil (*.brf) in den profiles2 Ordner vom BRouter kopieren und schon kann es verwendet werden und wenn gewünscht im Server-Mode einem Profil von Locus zugeordnet werden.
Gruß Volker
BRouter, ein konfigurierbarer Offline-Streckenrouter [Web + Android]
- Ersteller Reinhard
- Erstellt am
-
- Schlagworte
- brouter navigation routing
Hallo Geli,
nein, einfach das Profil (*.brf) in den profiles2 Ordner vom BRouter kopieren und schon kann es verwendet werden und wenn gewünscht im Server-Mode einem Profil von Locus zugeordnet werden.
Gruß Volker
- Beiträge
- 99
Hallo Geli,
da Interesse an einem profile für VM "verkehrsarm" besteht, hier mein bisheriger Stand der Dinge:
Volker D's Vorschlag, vom Fluxx-Profil auszugehen habe ich aufgegriffen.
Aktuelle Änderungen im Abschnitt context:global
downhill- und uphillcost 50 (statt 80; ich fahre nicht so ungern Berge)
downhill- und uphillcutoff 1.5 (statt 1)
Mit diesen Einstellungen bekomme ich im Bergischen Land gute Ergebnisse.
Aktuelle Änderungen im Abschnitt context:way
assign initialcost switch route=ferry 1500 0 (statt 15000 - 2 schlechte Rheinfähren habe ich als nogo-punkte eingestellt)
assign speedpenalty habe ich geöscht ebenso wie die Zeile add speedpenalty (Geschwindigkeitsbeschränkungen schränken mich in der Regel nicht ein)
assign surfacepenalty .. surface=compacted 25 (statt 4) ... surface=pabblestone 50 (statt 10) und surface= dirt 75 (statt 50)
Schotter- Sand und unbefestigte Pfadwege mag ich mit dem VM überhaupt nicht. Das habe ich übrigens auch im Profil VM-Schnell geändert.
Bei den highway-Variablen:
=ferry 5 (statt 10)
=trunk 10 (statt 3)
=primary 5 (statt 1.25)
=secondary 2 (statt 1)
bei highway=track:
=grade1 1 (statt 1.7)
=grade2 10 (statt 7)
...
=grade5 50 40 (statt 50 20)
...
=footway 20 (statt 15)
=pedestrian 20 (statt 15)
=steps 30 (statt 20)
Insgesamt sind es nicht viele Änderungen; sie haben aber eine große Wirkung. Ich habe schon ein paar Strecken damit abgefahren und war mit dem Ergebnis sehr zufrieden. Jetzt habe ich 2 Profile: Schnell von A nach B und Genußradeln auf möglichst verkehrsarmen und dabei asphaltierten Strecken.
Hat jemand noch andere Erfahrungen?
Grüße, Thomas
da Interesse an einem profile für VM "verkehrsarm" besteht, hier mein bisheriger Stand der Dinge:
Volker D's Vorschlag, vom Fluxx-Profil auszugehen habe ich aufgegriffen.
Aktuelle Änderungen im Abschnitt context:global
downhill- und uphillcost 50 (statt 80; ich fahre nicht so ungern Berge)
downhill- und uphillcutoff 1.5 (statt 1)
Mit diesen Einstellungen bekomme ich im Bergischen Land gute Ergebnisse.
Aktuelle Änderungen im Abschnitt context:way
assign initialcost switch route=ferry 1500 0 (statt 15000 - 2 schlechte Rheinfähren habe ich als nogo-punkte eingestellt)
assign speedpenalty habe ich geöscht ebenso wie die Zeile add speedpenalty (Geschwindigkeitsbeschränkungen schränken mich in der Regel nicht ein)
assign surfacepenalty .. surface=compacted 25 (statt 4) ... surface=pabblestone 50 (statt 10) und surface= dirt 75 (statt 50)
Schotter- Sand und unbefestigte Pfadwege mag ich mit dem VM überhaupt nicht. Das habe ich übrigens auch im Profil VM-Schnell geändert.
Bei den highway-Variablen:
=ferry 5 (statt 10)
=trunk 10 (statt 3)
=primary 5 (statt 1.25)
=secondary 2 (statt 1)
bei highway=track:
=grade1 1 (statt 1.7)
=grade2 10 (statt 7)
...
=grade5 50 40 (statt 50 20)
...
=footway 20 (statt 15)
=pedestrian 20 (statt 15)
=steps 30 (statt 20)
Insgesamt sind es nicht viele Änderungen; sie haben aber eine große Wirkung. Ich habe schon ein paar Strecken damit abgefahren und war mit dem Ergebnis sehr zufrieden. Jetzt habe ich 2 Profile: Schnell von A nach B und Genußradeln auf möglichst verkehrsarmen und dabei asphaltierten Strecken.
Hat jemand noch andere Erfahrungen?
Grüße, Thomas
- Beiträge
- 2.378
Hab grad mal damit ein paar Routen generiert, von mir bekannten Strecken. Das funktioniert ganz gut.
Was mir noch fehlt ist, dass vielbefahrene Straßen auf denen 100 kmh erlaubt sind und dabei keinen Fahrradweg haben (Bundes-, Kreis- und Landstraßen), möglichst gemieden werden, ohne ganz verboten zu sein.
Hab schon ein paar Änderungen versucht, aber erfolglos, bzw. es kamen nur noch Fehlermeldungen und kein Ergebnis mehr.
Wenn mir da noch jemand helfen könnte, welche Parameter ich wie ändern muss?
Danke
Geli
- Beiträge
- 1.046
Dazu würde mich mal eine Anleitung interessieren. Ich verwende Locus pro und habe noch nicht rausbekomme, wie ich die zusätzlichen Profile für VM etc. in brouter hinein bekomme
Gruß
Benno
Dazu würde mich mal eine Anleitung interessieren. Ich verwende Locus pro und habe noch nicht rausbekomme, wie ich die zusätzlichen Profile für VM etc. in brouter hinein bekomme
Gruß
Benno
Hallo Benno,
in diesem Beitrag habe ich es beschrieben.
Gruß Volker
- Beiträge
- 2.378
Hier ist noch eine Anleitung, die mir (als völlig Unbedarfte in dieser Hinsicht) sehr geholfen hat.
Um die nötigen Karten für BRouter am PC runterzuladen, hab ich mich an dieser Grafik orientiert.
Gruß
Geli
- Beiträge
- 1.046
Vielen Dank für die Tipps! Einige kannte ich bereits. Mich interessierte insbesondere, wie ich zusätzliche Profile in die brouter-app bekomme oder diese individuell an meine Bedürfnisse anpassen kann. Lassen sich die Profile im Handy aufrufen und bearbeiten? Ein Profil habe ich mir jetzt zusätzlich in den Ordner von brouter/profiles2 kopiert. Funktioniert auch. Das würde ich gern noch etwas vervollständigen.
Gruß
Benno
Gruß
Benno
- Beiträge
- 2.378
Wenn Du im Handy einen Texteditor hast geht das, aber............
Am besten testen kann man die Änderungen eines Profils auf der online Karte.
Mir ist es noch nicht gelungen, diese online Karte in einem Handybrowser sichtbar zu machen.
Ich finde den Bildschirm meines Laptop zum editieren der Profile schon viel zu klein, um einigermaßen die Übersicht zu behalten brauch ich dafür den großen Bildschirm meines PC. Auf einem Smartphone würd ich mir das nicht antun wollen.
@Volker D.
eine Verständnisfrage hab ich noch.
Die BRouter app braucht ja eigene Karten, um die Routen zu generieren. Wenn die Route dann in z.B. Locus geladen ist, werden dann die Informationen für den Navigations Guide aus den BRouter Karten generiert oder aus den openandromaps, die ich für Locus geladen habe?
Danke
Geli
Reinhard
Team
- Beiträge
- 23.191
BRouter verwendet keine Karten; was Du da runterlädst sind nur Infos fürs Routing. Daraus wird dann bspw. eine .gpx Datei erstellt, die wiederum Locus nutzt, um den Track auf der OSM-Karten darzustellen.
Locus => Karten App
BRouter => Routing App
- Beiträge
- 2.378
Danke, wieder um eine Information reicher, aber was ich eigentlich verstehen will, ist woher Locus die Detailnformationen über die Strecke nimmt.
Villeicht schilder ich besser mal das Problem, weil ich meine Frage wohl nicht verständlich formulieren kann.
Die von BRouter generierte .gpx Datei wird in Locus dargestellt. Dann starte ich in Locus den Guide mit Sprachausgabe, weil ich während der Fahrt das Display nicht ablesen kann.
Manchmal passiert es dann, dass unsinnige Anweisungen erteilt werden.
Screen_01: Die Route folgt den roten Pfeilen. Kurz bevor ich von der Strandstraße (K67) in den Rolf Dirksen Weg abbiegen muss meldet Locus, dass ich dem Straßenverlauf folgen soll. Offensichtlich fehlt die Info, dass die Haupstraße verlassen wird.
Screen_02: Ich fahre immer geradeaus am Seedeich, weit und breit keine Abbiegemöglichkeit und Locus meldet: nach 20 Metern rechts halten. Offensichtlich wird der sanfte Bogen des Weges für eine Abbiegung gehalten.
Ich wollte jetzt einfach nur wissen, ob diese mangelnden oder fehlerhaften Informationen aus der OSM Karte stammen oder ob die vom BRouter generiert werden, oder ob vielleicht Locus irgendwas falsch interpretiert.
Gruß
Geli
Villeicht schilder ich besser mal das Problem, weil ich meine Frage wohl nicht verständlich formulieren kann.
Die von BRouter generierte .gpx Datei wird in Locus dargestellt. Dann starte ich in Locus den Guide mit Sprachausgabe, weil ich während der Fahrt das Display nicht ablesen kann.
Manchmal passiert es dann, dass unsinnige Anweisungen erteilt werden.
Screen_01: Die Route folgt den roten Pfeilen. Kurz bevor ich von der Strandstraße (K67) in den Rolf Dirksen Weg abbiegen muss meldet Locus, dass ich dem Straßenverlauf folgen soll. Offensichtlich fehlt die Info, dass die Haupstraße verlassen wird.
Screen_02: Ich fahre immer geradeaus am Seedeich, weit und breit keine Abbiegemöglichkeit und Locus meldet: nach 20 Metern rechts halten. Offensichtlich wird der sanfte Bogen des Weges für eine Abbiegung gehalten.
Ich wollte jetzt einfach nur wissen, ob diese mangelnden oder fehlerhaften Informationen aus der OSM Karte stammen oder ob die vom BRouter generiert werden, oder ob vielleicht Locus irgendwas falsch interpretiert.
Gruß
Geli
Gear7Lover
gewerblich
- Beiträge
- 14.149
Unsinnige Sprachanweisungen kenne ich. Ist glaube ich kein Problem was sich schnell lösen lässt. OSM mit Locus wie auch Komoot kennen keine Verkehrsschilder/Vorfahrtsregel.
Am Kreisverkehr geradeaus: 2 Ansagen rechts abbiegen. Abknickende Vorfahrtsstrasse, kennt er nicht.
Wenn die Landstrassd eine Rechtskurve macht und geradeaus ein Fussweg geht, den man auch mit dem Mountainbike fahren könnte, dann heisst es rechts abbiegen.
Die Ansagen könnte man sich auch sparen. Ich hab sie nur an, damit ich weiss wann ich mal wieder auf den Bildschirm kucken soll. Auch geht je nach Einstellung bei Ansagen der Bildschirm an, der ansonsten aus ist.
Am Kreisverkehr geradeaus: 2 Ansagen rechts abbiegen. Abknickende Vorfahrtsstrasse, kennt er nicht.
Wenn die Landstrassd eine Rechtskurve macht und geradeaus ein Fussweg geht, den man auch mit dem Mountainbike fahren könnte, dann heisst es rechts abbiegen.
Die Ansagen könnte man sich auch sparen. Ich hab sie nur an, damit ich weiss wann ich mal wieder auf den Bildschirm kucken soll. Auch geht je nach Einstellung bei Ansagen der Bildschirm an, der ansonsten aus ist.
Reinhard
Team
- Beiträge
- 23.191
Gib doch zum Spaß als Ziel mal "Am Wremer Tief" oder etwas danach ein. Dann wird Dir Locus vermutlich an der selben Stelle melden, dass Du rechts abbiegen (also weiter auf K67 fahren) und nicht dem Straßenverlauf folgen sollst ...
A
abrensch
Locus (genau wie auch OsmAnd...) generiert die Sprachanweisungen (bisher..) nur aus dem GPX-Track selbst, an dieser Stelle ist also keine Karte im Zugriff.
Das ist schon lange Thema und auch sicherlich weit oben auf der Prioritäten-Liste. Gibt wohl online-Dienste, aus denen Locus auch jetzt schon netzwerk-basierte Sprachanweisungen generieren kann, aber it BRouter geht's noch nicht. Für's Radrouting m.E. nach nicht sooo tragisch, aber fürs Autorouting schon ein NoGo, weil man ggf. nicht auf eine Abbiegung hingewiesen wird, z.B. an einem Autonbahndreieck.
Gruss, Arndt
- Beiträge
- 1.331
Beim Autorouting hat Skobbler diese Probleme auch. Da heisst es auf der Landstraße plötzlich, dass man rechts abbiegen soll, obwohl die Strasse nur einen Bogen nach rechts macht. Manchmal sind auch die Kreisel in OSM unterbrochen und das Programm betrachtet das als eigene "Wegstücke". So kommt es dann zu solchen irrwitzigen Anweisungen "rechts, links, rechts" anstatt "2. Ausfahrt aus dem Kreisverkehr" benutzen bei Lochs.
Vielleicht kann man hier noch nachbessern.
Vielleicht kann man hier noch nachbessern.
Hallo,
@abrensch hat meinen Vorschlag für unterschiedliche Wegekosten für Gefälle, Ebene und Steigung noch etwas verbessert und in den BRouter ab Version 1.03 aufgenommen. Um die neue Funktion nutzen zu können müssen die alten Profile ergänzt werden. Neu hinzugekommen sind im Bereich "---context:way" die beiden Variablen "uphillcostfactor" und "downhillcostfactor" mit denen man die Kostenfaktor für den jeweiligen Weg bei Steigung und Gefälle definiert, wobei der bisherige "costfactor" dann nur noch für die Ebene gilt. Um besser definieren zu können wann ein Weg als Steigung oder Gefälle erkannt wird, sind im Bereich "---context:global" weitere Variablen zum konfigurieren des Puffers hinzugekommen der für das Filtern der ungenauen SRTM Höhendaten notwendig ist. Mit "elevationpenaltybuffer" wird die untere Puffergrenze definiert ab der eine Wegsegment als Steigung oder Gefälle erkannt wird, wenn nicht verwendet wird er auf den Standardwert von 5 Meter gesetzt. Mit "elevationmaxbuffer" wird die maximale Puffergröße definiert, wenn nicht verwendet wird er auf den Standardwert von 10 Meter gesetzt. Dies ist auch die bisher nicht veränderbare maximale Puffergröße für den Höhenfilter ab der die Höhenstrafen fällig werden. (Aber nur für die Kostenberechnung, die angezeigte gefilterte Höhe hat weiterhin immer den 10 Meter Filter.) Da meiner Meinung nach jeweils 5 Meter für den Pufferbereich zu wenig sind, aber keine schlechtere Höhenvermeidung haben wollte habe ich mit "elevationbufferreduce" eine weitere Variable hinzugefügt. Mit dieser Variablen legt man fest wie stark (in % von der Wegstrecke) der Puffer, wenn er größer als "elevationpenaltybuffer" ist, reduziert wird und diese entnommenen Höhenmeter in Strafen umgesetzt werden. Wird "elevationbufferreduce" nicht verwendet, wird er auf Null gesetzt. Die bisherigen Profile ab Version 1.01 funktionieren daher weiterhin wie zuvor.
Im Anhang ist das VM-schnell und LR-schnell Profil mit den neuen Parametern was bei manchen Strecken zu interessanten Unterschieden führt.
Gruß Volker
@abrensch hat meinen Vorschlag für unterschiedliche Wegekosten für Gefälle, Ebene und Steigung noch etwas verbessert und in den BRouter ab Version 1.03 aufgenommen. Um die neue Funktion nutzen zu können müssen die alten Profile ergänzt werden. Neu hinzugekommen sind im Bereich "---context:way" die beiden Variablen "uphillcostfactor" und "downhillcostfactor" mit denen man die Kostenfaktor für den jeweiligen Weg bei Steigung und Gefälle definiert, wobei der bisherige "costfactor" dann nur noch für die Ebene gilt. Um besser definieren zu können wann ein Weg als Steigung oder Gefälle erkannt wird, sind im Bereich "---context:global" weitere Variablen zum konfigurieren des Puffers hinzugekommen der für das Filtern der ungenauen SRTM Höhendaten notwendig ist. Mit "elevationpenaltybuffer" wird die untere Puffergrenze definiert ab der eine Wegsegment als Steigung oder Gefälle erkannt wird, wenn nicht verwendet wird er auf den Standardwert von 5 Meter gesetzt. Mit "elevationmaxbuffer" wird die maximale Puffergröße definiert, wenn nicht verwendet wird er auf den Standardwert von 10 Meter gesetzt. Dies ist auch die bisher nicht veränderbare maximale Puffergröße für den Höhenfilter ab der die Höhenstrafen fällig werden. (Aber nur für die Kostenberechnung, die angezeigte gefilterte Höhe hat weiterhin immer den 10 Meter Filter.) Da meiner Meinung nach jeweils 5 Meter für den Pufferbereich zu wenig sind, aber keine schlechtere Höhenvermeidung haben wollte habe ich mit "elevationbufferreduce" eine weitere Variable hinzugefügt. Mit dieser Variablen legt man fest wie stark (in % von der Wegstrecke) der Puffer, wenn er größer als "elevationpenaltybuffer" ist, reduziert wird und diese entnommenen Höhenmeter in Strafen umgesetzt werden. Wird "elevationbufferreduce" nicht verwendet, wird er auf Null gesetzt. Die bisherigen Profile ab Version 1.01 funktionieren daher weiterhin wie zuvor.
Im Anhang ist das VM-schnell und LR-schnell Profil mit den neuen Parametern was bei manchen Strecken zu interessanten Unterschieden führt.
Gruß Volker
Hallo Roland,
Bei brouter-web sind es noch alte Profile. Man kann aber das neue Profil in das Textfeld kopieren und die Berechnung damit durchführen lassen.
Gruß Volker
- Beiträge
- 4.927
Mit brouter-web habe ich "just jetzt" das Problem, dass es mir konsequent "error: error re-tracking track" oder "track not found" meldet; unabhängig vom gewählten Profil und konkreten Start- und Zielpunkten.
Hab nur ich das, oder ist da zwischen gestern (da ging es noch) und heute irgendetwas entscheidendes vorgefallen? (Software-Update o.ä. z.B.)
-Andreas
Hab nur ich das, oder ist da zwischen gestern (da ging es noch) und heute irgendetwas entscheidendes vorgefallen? (Software-Update o.ä. z.B.)
-Andreas