BRouter, ein konfigurierbarer Offline-Streckenrouter [Web + Android]

[Gear7Lover]

Kann das sein dass die Iteration Vollzug meldet weil das Ergebnis bereits als gut genug gilt bevor die letzten paar Kostenpunkte rausoptimiert sind?
Oder ist der Algorithmus mit dem Ameisenrennen nicht treffsicher?

Es passiert aber auch mit Google Maps dass man durch abweichen von der Route die geschätzte Ankunftszeit ein wenig verbessert. Die "Grossen" sind also auch nicht vor kleinen Berechnungsfehlern sicher.

 

[crummel]

Gestern hatte ich einen track für einen kleinen Ausflug erstellen wollen. Da ich im Urlaub bin, musste mein Android-Handlich dafür genügen.

Dass das Auswählen der Profile mobil nicht funktioniert, ist mir bekannt. Dafür habe ich entsprechend bookmarks gesetzt. Wegmarken setzen funktionierte, dann kann aber nur noch "an error has occurred", irgendwie etwas mit "only secure endpoints accepted".

Also weiter mit der mobilen Seite. Mit der erhielt ich schnell die gewünschte gpx-Datei.

Wir geht es jetzt weiter?

Das Öffnen der gpx-Datei erfolgte mit Garmin Connect, was dazu führte, dass eine neue Strecke importiert wurde. Dafür musste ich nur noch einen Typ der Strecke vergeben, sinnigerweise Rennrad auf befestigter Strasse o.ä.. Nächster Schritt war die Übertragung auf meinen Garmin. Die Beschreibung ist dann mit "Radfahren 16. Juli" vorgegeben gewesen, aber auf dem Garmin konnte ich das wieder umbenennen.

Optional kann man per Funktion "Geräteübertragung" auf einem Gerät die Strecke freigeben, um sie dann von anderen Geräten herunterladen zu können. So hat jeder Mitfahrende den track.

 

[Gwynfor]

Moin,

dass die Kosten falsch berechnet werden

über welche Kosten sprechen wir? Navigation sollte nicht nur die Kosten für Höhenmeter und Entfernung berücksichtigen, sondern auch Kosten für z.B. Abbiegen. Außerdem könnte auch Wolfgang recht haben, dass

die Iteration Vollzug meldet

Jede neue Berechnung kostet Zeit, wenn aber die zu erwartende Verbesserung nur minimal ist, wird der Algorithmus irgendwann einen Schlußstrich ziehen (der alte mathematiker Scherz: ich fahre 100m hinter meinem Vordermann hinterher, wenn ich jetzt alle 5 Minuten den Vorsprung halbiere, wann werde ich ihn überholt haben?)

Ciao,
Andreas

 

[AxelK]

Dass das Auswählen der Profile mobil nicht funktioniert, ist mir bekannt.

Das hier meinst du?

 

[crummel]

Das hier meinst du?

Nein, das in der brouter-web-Onlineversion im Browser.

 

[klein]

An manchen Knoten hat man verschiedene Höhenmeter in den Puffern, es wird aber die Alternative mit den bisher niedrigsten Kosten ausgewählt. Diese Höhenmeter in den Puffern können dann aber in den nächsten Segmenten zuschlagen.

Ich hab bei mir die Höhenpufferei mal deaktiviert und siehe da, die Ungereimtheiten waren verschwunden. Vielen Dank für die Erklärungen, Volker. Krass, wie du dich da auskennst. Hast du beim Projekt mitentwickelt?
[DOUBLEPOST=1531864752][/DOUBLEPOST]

über welche Kosten sprechen wir?

Sorry, aber wie die Kosten genau berechnet werden, ist an dieser Stelle nicht relevant.

wenn aber die zu erwartende Verbesserung nur minimal ist, wird der Algorithmus irgendwann einen Schlußstrich ziehen

Ich hatte den Algorithmus aber explizit auf volle Genauigkeit getrimmt. Egal, der Fehler hat ja nun einen Namen, siehe Post #1166.

 

[klein]

Ach ja, darf ich noch was Kleines fragen? Ist es via Profil möglich, Linksabbiegen gegenüber Rechtsabbiegen besonders zu bestrafen? Oder müsste man sich dazu am Quellcode selber zu schaffen machen?

Finde dieses Tool echt grossartig, bin ganz aus dem Häuschen ob all den Möglichkeiten. Vielen Dank all den Machern! Kann man sich da irgendwie erkenntlich zeigen?

 

[Volker D.]

Hast du beim Projekt mitentwickelt?

Nur ganz wenig.

Ist es via Profil möglich, Linksabbiegen gegenüber Rechtsabbiegen besonders zu bestrafen?

Nein, ich denke aber dass es auch nicht viel bringt, denn wie will man es effektiv vermeiden ohne das Abbiegen insgesamt zu vermeiden oder im Kreis zu fahren und damit unötigen Umweg zu fahren.

Kann man sich da irgendwie erkenntlich zeigen?

Am einfachsten ist denke ich geholfen wenn man bei Openstreetmap mithilft die Daten zu verbessern. Wie man hier sehen kann arbeitet auch Arndt an diesem Problem. BRouter kann nur so gut sein wie die Daten die er bekommt.

Gruß Volker

 

[Fanfan]

Nein, ich denke aber dass es auch nicht viel bringt, denn wie will man es effektiv vermeiden ohne das Abbiegen insgesamt zu vermeiden oder im Kreis zu fahren und damit unötigen Umweg zu fahren.

Genau der Umweg könnte eine Zeitersparnis bringen, wenn man dadurch über eine Ampelkreuzung kommt, vielleicht sogar als Geradeausfahrer, statt auf einer stark befahrenen Straße ewig auf's Abbiegen in eine kleine Gasse zu warten.
Aber eine allgemeine Strafe für's Linksabbiegen scheint mir auch nicht sinnvoll bei den Szenarien, die mir vorschweben. Das müsste an mehr als nur der Eigenschaft "Linksabbiegen" in OSM festgemacht werden.

 

[Volker D.]

Genau der Umweg könnte eine Zeitersparnis bringen, wenn man dadurch über eine Ampelkreuzung kommt, vielleicht sogar als Geradeausfahrer, statt auf einer stark befahrenen Straße ewig auf's Abbiegen in eine kleine Gasse zu warten.

Hast du oder jemand anderes Beispiele bei denen höhere Linksabiegekosten zu einer tatsächlich besseren Route führen könnte?

Gruß Volker

 

[Fanfan]

An dieser Stelle von Süden nach Westen abzubiegen ist bei stärkerem Verkehr sehr unerfreulich, egal ob mit Auto oder mit Fahrrad: klick Da kann man auch schonmal >10min warten (gemessen, nicht nur gefühlt, aber bisher nur mit dem Fahrrad erlebt). Allerdings hängt das Problem dort nicht am Abbiegen, sondern am Überqueren der beiden Fahrspuren der Lochhausener Str. Geradeausfahren ist genauso betroffen, und für Fahrräder wegen des einseitigen Geh- und Radwegs auch das Rechtsabbiegen. Ich fahre eigentlich immer zur Unterführung am S-Bhf. Lochhausen.
Linksabbiegespuren mit ewigen Wartezeiten fallen mir keine ein. Abbiegespuren gibt's ja nur an größeren Straßen, und auf denen gibt's dann entweder Ampeln oder ein Linksabbiegeverbot.

@klein, an was für Szenarien hattest Du gedacht?

 

[klein]

an was für Szenarien hattest Du gedacht?

Mir fällt's halt besonders in der Stadt auf. Nirgends steht man länger still als bei Linksabbiegern mit Ampeln, separate Abbiegespur hin oder her. Hängt natürlich auch stark von der Verkehrsbelastung ab. Verbessern kann man die Route, indem man die "Linkskorrektur"

• auf Linkskurven statt Kreuzungen verschiebt (yeah )
  
• auf Kreisel verschiebt
• auf Kreuzungen ohne Ampeln verschiebt, z.B. kleinere Kreuzungen in Quartierstrassen oder Situationen mit Verkehrsinseln zum "Durchmogeln"..

Ich muss auf meinem Arbeitsweg quer durch Zürich, d.h. es gibt wirklich hunderte von möglichen Routen. Es hätt mich halt einfach mal wunder genommen, was der BRouter ausspucken würde, wenn Linksabbiegen (an Ampeln) bestraft werden würde.

Wenn man in eine befahrene oder mehrspurige Strasse links abbiegen will oder diese überqueren muss (wie z.B. die Lochhausener Str.), dann kann es tatsächlich von Vorteil sein, zuerst rechts abzubiegen (das geht meistens schnell) und dann bei der nächstbesten Gelegenheit zu wenden bzw. links abzubiegen. Zugegeben, es ist nicht einfach, dies in der Kostenfunktion abzubilden, aber ich hätt sicher gerne mal damit herum experimentiert..
[DOUBLEPOST=1531915709][/DOUBLEPOST]

wenn man bei Openstreetmap mithilft die Daten zu verbessern

Ich hab gleich mal einen OSM Account erstellt und mich einer kleinen Ausbildung im Karten Editieren unterzogen. Soweit so gut. Seitens BRouter hab ich in der Schweiz aber nicht viele Issues gesehen (nur ein paar Autobahnzubringer).. und wenn ich die allgemeinen OSM-Notes für meine Gegend betrachte, dann geht's da eigentlich fast ausschliesslich um Gebäude/Geschäfte/Flächen und nicht um Strassen. Wie könnt ich mich denn nun konkret behilflich machen? Müsste ich aktiv auf Fehlersuche gehen?

 

[Volker D.]

Die entscheidende Frage bei Linksabiegekosten ist: Wie hoch müssten die Zusatzkosten bei diesen Beispielen sein um eine bessere Alternative zu erreichen und welche unerwüschte Nebeneffekte handelt man sich ein. Ich sehe da zu wenig mit sinnvollen Kosten erreichbare Alternativen, was vielleicht auch daran liegt dass ich zu wenig in so großen Städten unterwegs bin bei denen es viele Alternativen gibt.

auf Kreisel verschiebt

Kreisverkehre sind im VM- und Liegeradprofil schon jetzt von den Abbiegekosten befreit.

Wie könnt ich mich denn nun konkret behilflich machen?

Ich weiß nicht wie vollständig die OSM-Daten bei dir sind aber manchmal fehlen noch Oberfläche, Geschwindigkeitsbegrenzungen und solche Sachen. Mit overpass-turbo.eu kann man OSM grafisch nach tags und tag-Kombinationen durchsuchen. Wenn du mit brouter-web Profile testest mal auf "Data" Ansicht wechseln (oder Data CSV herunterladen) und die Kosten und tags die dazu geführt haben prüfen (mit "assign processUnusedTags = true" im globalen Bereich kann man alle vorhandene tags anzeigen, das hilft auch sehr bei der Profiloptimierung).

Gruß Volker

 

[Mips]

Profilanpassung BRouter

Bin zuletzt auf La Palma ein wenig Rad gefahren und hatte dabei folgendes Problem:

Die Navigation mit BRouter war wie immer tadellos, aber da waren ja noch die Steigungen.
Ein kürzerer Weg bedeutet dort aber immer eine teils extreme Zunahme des Anstiegs (Abstiegs).
Das ändern des uphillcutoff auf z.B. 8 half nur bedingt, da hierbei alles über 8% mit den gleichen Kosten belegt wird.
Allerdings ist es für mich mit meinen bescheidenen Möglichkeiten nicht egal ob ich Anstiege mit 10%, 15% oder gar noch darüber fahren muss.
Ich suche daher nach einer Möglichkeit Steigungen stufenweise mit entsprechend höheren Kosten zu belegen.
Hat dazu jemand einen Vorschlag?

Danke
Gruß Mike

 

[klein]

Die entscheidende Frage bei Linksabiegekosten ist: Wie hoch müssten die Zusatzkosten bei diesen Beispielen sein

Ich denke, das müsste man mit 2 Profilen lösen: low und high traffic.. low traffic von mir aus wie gehabt und high traffic halt mit satteren Strafen fürs Linksabbiegen.. Jemand anderes hat irgendwo mal geschrieben, dass eine "Stadterkennung" was Gutes wäre, damit der BRouter auch Städte bestrafen könnte. Das wär hier fürs Abbiegeproblem natürlich auch ganz chic.

Kreisverkehre sind im VM- und Liegeradprofil schon jetzt von den Abbiegekosten befreit.

Warum eigentlich? In der Schweiz kommt man nie ungeschoren durch einen Kreisel (ausser es geht bergauf und hat keinen Verkehr). Ich hab da schon gleich zu Beginn eine kleine Strafe eingesetzt, was höchstens fürs Rechtsabbiegen etwas zu hart ist.

Mit overpass-turbo.eu

Danke für die Tips. Uff, die Abfragesprache auch noch zu lernen war mir dann vorerst noch etwas zu viel. Aber ich konnt nun einiges mit KeepRight machen und konnt auch schon aus dem BRouter heraus was korrigieren. Geht schon, vielen Dank!

 

[Volker D.]

Warum eigentlich? In der Schweiz kommt man nie ungeschoren durch einen Kreisel (ausser es geht bergauf und hat keinen Verkehr). Ich hab da schon gleich zu Beginn eine kleine Strafe eingesetzt, was höchstens fürs Rechtsabbiegen etwas zu hart ist.

Wenn man es gnau nimmt sind die Kreisverkehre nicht ganz von den Kosten befreit, die Ausfahrt kostet wieder. Gerade aus oder rechts weg kommt man bei einem Kreisel mit 30 - 40 km/h durch, das bremst die meisten nicht besonders. Links weg gehen auch 20 - 30 km/h. Bei stärkerem Verkehr ist er sowieso im Vorteil weil die Wartezeiten meist geringer sind.

Uff, die Abfragesprache auch noch zu lernen war mir dann vorerst noch etwas zu viel.

Man kann bei overpass-turbo.eu auf Wizard klicken und den gesuchten tag eingeben. Dann wird die Abfrage für einen erstellt.

Gruß Volker

 

[Volker D.]

Das ändern des uphillcutoff auf z.B. 8 half nur bedingt, da hierbei alles über 8% mit den gleichen Kosten belegt wird.

Das stimmt so nicht. Wenn man den Höhenpuffer außer acht lässt, wird eine Steigung von 10% je Strecke doppelt so stark bestraft wie eine mit 9%. Der cutoff muss ein gutes Stück unter deiner zu großen Steigung liegen um ausreichend Kosten für einen Umweg zu generieren. Wenn dann immer noch zu viele Steigungen dabei sind, sind entweder die uphillcost zu klein oder BRouter findet keine bessere Alternative. Man darf auch den Höhenpuffer und die Ungenauigkeiten der SRTM-Hohendaten nicht vergessen, so können kurze Steigungen mit weniger als 10-20 Höhenmeter nicht sinnvoll erkannt weden.

Gruß Volker

 

[Mips]

Wenn man den Höhenpuffer außer acht lässt, wird eine Steigung von 10% je Strecke doppelt so stark bestraft wie eine mit 9%.

Dank erst einmal für die Antwort.
Ich habe jetzt ein wenig im BRouter-Web mit uphillcutoff / uphillcost herum experimentiert und bin zu guten Ergebnissen gekommen. Die besten Werte erreichte ich mit uphillcutoff=6 (bis 8) und uphillcost=80.
Wieso erhalte ich aber bei uphillcutoff=1,5 schlechtere Ergebnisse, obwohl doch bei angenommenen 10% Steigung pro km eine größere Strafe (85m*80=6800m) anfällt als bei uphillcutoff=6?

Zudem ist mir die Sache mit dem Höhenpuffer noch immer nicht ganz klar.
Um beim Beispiel zu bleiben:

assign elevationpenaltybuffer 10 (Strafen fallen erst ab 10m Höhenunterschied an)
assign elevationmaxbuffer 15 (max. Puffergröße in Metern, alles darüber wird mit 80m pro Meter bestraft)​

soweit ist noch alles klar, aber wie errechnet sich die Strafe zwischen 10m und 15m bei

assign elevationbufferreduce 1 (Strafe ??? und der Puffer wird um 1 reduziert) ?
​

Gruß
Mike

 

[Volker D.]

Wieso erhalte ich aber bei uphillcutoff=1,5 schlechtere Ergebnisse, obwohl doch bei angenommenen 10% Steigung pro km eine größere Strafe (85m*80=6800m) anfällt als bei uphillcutoff=6?

Warscheinlich bekommen die nicht ganz so steilen Alternativen auch mehr Kosten wodurch sich der Umweg nicht mehr lohnt. Es ist auch möglich dass die Segmente anders bewertet werden weil sie mit uphillcostfactor anstatt mit costfactor bestraft werden.

aber wie errechnet sich die Strafe zwischen 10m und 15m bei
assign elevationbufferreduce 1 (Strafe ??? und der Puffer wird um 1 reduziert) ?

Es werden Kosten berechnet und Höhenmeter aus dem Puffer genomen die 1% über dem cutoff entsprechen. Bei einem 100 Meter langen Segment wäre das 1 Hohenmeter und Zusatzkosten von 80 Meter (bei uphillcost 80).

Schau dir auch mal den Data-Reiter bei brouter-web an. Da siehst du welche Kosten bei dem jeweiligen Segment berechnet wurden.

Gruß Volker

 

[Mips]

Der cutoff muss ein gutes Stück unter deiner zu großen Steigung liegen um ausreichend Kosten für einen Umweg zu generieren

Stimmt!
Ich bin Deinem Hinweis mal in den DATA-Reiter zu schauen gefolgt, und habe folgende Beobachtung gemacht.
Setze ich den cutoff ca. als 1/2 Wert der von mir maximal gewünschten Steigung (8%) auf 4 und setze die uphillcost hoch (z.B. 100) erhalte ich auf der Teststrecke das gewünschte Ergebnis.
Die Auswirkungen bei Nutzung des Höhenpuffers sind mir noch immer nicht ganz klar.
Diese scheinen in bergigen Gebieten doch eher gering zu sein, da m.E. sinnvolle Puffergrenzwerte sehr schnell überschritten werden.
Der Besuch auf https://github.com/poutnikl/Brouter-profiles/wiki/Glossary lässt vieles jetzt zwar klarer, aber dennoch nicht vollumfänglich verständlich erscheinen.

z.B.

Es werden Kosten berechnet und Höhenmeter aus dem Puffer genomen die 1% über dem cutoff entsprechen

Gelten diese 1% immer, oder nur weil in meinem Beispiel der elevationbufferreduce=1 ist?

Im Bereich zwischen elevationpenaltybuffer <-> elevationmaxbuffer werden die Kosten aus einem Verhältnis, abhängig wiederum von elevationbufferreduce, von costfactor und up/downhillcostfactor berechnet.
Was ist bei fehlen der Sektion up/downhillcostfactor, wird jetzt ausschließlich mit costfactor weitergerechnet?

Ich würde meine "Teststrecke" ja auch gern als Link angeben, kenne aber das Vorgehen um aus BRouter-Web den entsprechenden Link mit Start/Ziel/Profil etc. zu generieren nicht.

Gruß
Mike