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

Hallo zusammen,

habs leider noch nicht geschafft längere Strecken tatsächlich nachzufahren, mir scheint das FLUXX Profil passendere Steigungen und Gefälle rauszusuchen (also die, die ich mir aus Erfahrung und "per Hand" auch raussuchen würde), wenn ich die ersten Zeilen wie folgt ändere (in der Hoffnung ich hab das Prinzip auch richtig verstanden, als: cutoff ist der Wert ab dem bestraft wird;-):

assign downhillcost 80
assign downhillcutoff 0.08
assign uphillcost 80
assign uphillcutoff 0.005

jedenfalls scheint's in der näheren Umgebung gut zu passen.

Gruß, Dan
 
Habe das ganze auch mal ausprobiert. Die ausgerechnete Strecke vom Triketreffen in Schwalmstadt ins Rhein-Main-Gebiet war gut. Ich habe auch mal meine Alltagsstrecken hier in meiner Gegend durchrechnen lassen, da waren die Ergebniss auch ganz ok. Von Ampeln weiss das Progrämmchen halt z.B. nichts, da sind Strecken teilweise etwas suboptimal wenn es gute Umfahrungen gibt. Auf meinem Unterklasse weil Dual-Sim Alltagshandy gab es bei längeren Strecken Probleme mit dem Speicher, die Berechnung brach dann ab. Mit meinem Nexus5-Cyanogenmod Rumspieltelefon hat er alles klaglos durchgerechnet. Die Tracks konnte ich dann ja aufs andere Telefon rüberkopieren.
 
...
assign downhillcost 80
assign downhillcutoff 0.08
assign uphillcost 80
assign uphillcutoff 0.005
...
Gruß, Dan

Die Höhendaten sind meist nicht so genau um mit solchen kleinen cutoffs wirklich etwas zu erreichen. Bei den uphillcutoffs habe ich 1% gewählt, weil solche Steigungen noch problemlos zu fahren sind und wenn sie nicht bestraft werden, werden damit solche flachen Steigungen bevorzugt gewählt. Die gesammten Höhenmeter werden dann über die downhillcutoff vermieden, denn wo man unötig hoch fährt muss man auch wieder herunter.

... Von Ampeln weiss das Progrämmchen halt z.B. nichts, da sind Strecken teilweise etwas suboptimal wenn es gute Umfahrungen gibt. Auf meinem Unterklasse weil Dual-Sim Alltagshandy gab es bei längeren Strecken Probleme mit dem Speicher, die Berechnung brach dann ab. Mit meinem Nexus5-Cyanogenmod Rumspieltelefon hat er alles klaglos durchgerechnet. Die Tracks konnte ich dann ja aufs andere Telefon rüberkopieren.

Doch Ampeln werden, soweit sie in Openstreetmap eingetragen sind, mit jeweils mit 200 Meter bestraft. Wenn man mehr nimmt führt es nur dazu dass die Ampeln über die teilweise ohne Ampeln eingetragenen Rad- und Fußwege die parallel verlaufen umfahren werden obwohl man dort über noch mehr Ampeln muss.

Die maximale Strecke die man mit dem Smartphone berechnen kann ist von der Speichergröße, der Netzdichte, Höhenprofil und vom Profil abhängig. Meine Profile erzeugen recht hohe Kosten, was zu einem großen Suchgebiet und damit kürzeren Strecken führt die geroutet werden können. Mit dem Xperia V kam ich in Süddeutschland ungfär 200km weit und das Xperia Z1compact hat auch bei 500km und über 45 Minuten Rechenzeit nicht aufgegeben.

Gruß Volker
 
Hallo Volker,

Bist du sicher, dass die Steigungs-Werte in Prozent sind? wenn ich die Routing-Ergebnisse vergleiche hätte ich gedacht, dass die Werte in "1"=100% sind?

Gruß, Dan
 
Hallo Volker,

Bist du sicher, dass die Steigungs-Werte in Prozent sind? wenn ich die Routing-Ergebnisse vergleiche hätte ich gedacht, dass die Werte in "1"=100% sind?

Gruß, Dan

Hallo Dan,

Ja da bin ich mir sicher. Die cutoffs (und die up- und downhillcost) wirken erst bei längeren Strecken da noch ein 10 Meter Puffer verwendet wird um seltsame Schlangenlinien in der Ebene aufgrund der ungenauen SRTM Höhendaten zu vermeiden.

Gruß Volker
 
Hallo Volker,

;-o, naja routet aber trotzdem flacher als Deins ;-) - nur macht es keine 300km Touren mehr am Stück online.. . ;-(

Gruß, Dan
 
Hallo Volker,

;-o, naja routet aber trotzdem flacher als Deins ;-) - nur macht es keine 300km Touren mehr am Stück online.. . ;-(

Gruß, Dan
Hallo Dan,

Mit deinen Parametern bekommt man weil die uphillcost bis 1% auch zählen schon flachere aber auch längere Routen. Ist halt auch eine Abwägungsache wieviel Umweg man für weniger Höhenmeter bereit ist zu fahren.

Man kann den BRouter auch per Komandozeile (leider ohne nogo Bereiche) auf auf dem PC ausführen. Dann gehen auch 1000km in ca. 15 Minuten.

Gruß Volker
 
Hallo Volker,
Naja, auf langen Touren würde ich schon zum 300hm bei 6% Einsparen 15km bei 0,5% in Kauf nehmen - was das Profil aber nicht machte - Nun hab ichs ja. Ist doch gut wenn man seine Präferenzen so definieren kann, das Profil für alle wirds nicht geben.
Gruß, Daniel
(Schurwald und Filstal queren wenn man gar nicht muss?)
 
Jetzt stehe ich vor einem Rätsel.
Von Bassum nach Nordloh war die Strecke zwar brauchbar, aber es gibt wesentlich bessere und deutlich kürzere Alternativen.
Richtig heftig wird es, wenn ich Sandhatten als Zwischenziel angebe. Dann will mich der BRouter mitten durch Oldenburg schicken, was wirklich nicht nötig ist.

Alle bisherigen Strecken waren ja echt super, aber was ist das jetzt ?
So schlecht können die Daten in Openstreetmap gar nicht sein.

Gruß
Bernd
 
Jetzt stehe ich vor einem Rätsel.
Von Bassum nach Nordloh war die Strecke zwar brauchbar, aber es gibt wesentlich bessere und deutlich kürzere Alternativen.
Richtig heftig wird es, wenn ich Sandhatten als Zwischenziel angebe. Dann will mich der BRouter mitten durch Oldenburg schicken, was wirklich nicht nötig ist.

Alle bisherigen Strecken waren ja echt super, aber was ist das jetzt ?
So schlecht können die Daten in Openstreetmap gar nicht sein.

Gruß
Bernd

Hallo Bernd

In dieser Region sind einige Kreistraßen die von Radwegen begleitet werden mit bicycle=no getaggt. Da hat wohl jemand das Fahrbahnverbot für Radfahrer durch die blauen Lollies an die Kreisstraßen getaggt was aber bei Openstreetmap so nicht üblich ist. Radwege mag das VM Profil nicht und über bicycle=no will es auch nicht also bekommt man erhebliche unschöne Umwege. Verwende dort mal das fluxx Profil, da es eher Radwege verwendet kommt es zu besseren Ergebnissen.

In der angehängten Zip ist ein VM Profil das bicycle=no nicht berücksichtigt. Damit schaut es dort viel besser aus.

Gruß Volker
 

Anhänge

  • vm test.zip
    1,2 KB · Aufrufe: 88
Zuletzt bearbeitet:
Hallo Volker,

du bist genial.
Mit diesem Profil wäre ich genau die Strecke gefahren, die mich Philip mit seiner Ortskenntnis geführt hat. Auch die restliche Strecke entspricht damit fast dem mir bekannten optimum. Da ist nur eine Kreisstrasse dabei, welche ich wegen des starken Verkehrs gerne umfahre.

In dieser Region sind einige Kreistraßen die von Radwegen begleitet werden mit bicycle=no getaggt.

Fragt sich also, ob man in diesem Bereich nicht lieber alle bicycle=no entfernen sollte. Aber ist so was in einem Rutsch bei Openstreetmap möglich ?
Oder gibt es gar eine Auswertemöglichkeit für Openstreetmap, mit der man solche örtlichen Auffälligkeiten ermitteln und korrigieren kann ?

Gruß
Bernd
 
Fragt sich also, ob man in diesem Bereich nicht lieber alle bicycle=no entfernen sollte. Aber ist so was in einem Rutsch bei Openstreetmap möglich ?
Oder gibt es gar eine Auswertemöglichkeit für Openstreetmap, mit der man solche örtlichen Auffälligkeiten ermitteln und korrigieren kann ?

Gruß
Bernd

Hallo,

Das beste zum Darstellen der bicycle=no das ich gefunden habe ist das. Dort kann man sie in der Karte einblenden. Meiner Meinung nach sollten die bicycle=no (und auch die foot=no, von denen wimmelt es dort auch) nur bei direkten Verbot z.B. durch Zeichen 254 verwendet werden. Das scheint aber im Openstreetmap Wiki nirgends so dokumentiert zu sein. Alle bicycle=no in einer Region generell zu entfernen ist glaube ich auch nicht gut, weil damit auch die berechtigten Taggs entfernt werden. Da bleibt wahrscheinlich nur die mühevolle Arbeit von ortskundigen Leuten in der Region um das zu ändern.

Gruß Volker
 
......... Alle bicycle=no in einer Region generell zu entfernen ist glaube ich auch nicht gut, weil damit auch die berechtigten Taggs entfernt werden. Da bleibt wahrscheinlich nur die mühevolle Arbeit von ortskundigen Leuten in der Region um das zu ändern....

Nach meiner Meinung wird das kaum Jemand ändern. Wenn man aber alle Einträge löscht, ist es recht warscheinlich, dass die wenigen wirklich gesperrten Strecken recht zügig wieder korrigiert werden.

Aber das ist wohl eher eine Diskussion für's Openstreetmap-Forum.

Gruß
Bernd
 
......Das beste zum Darstellen der bicycle=no das ich gefunden habe ist das. ..

Schöne Seite, so habe ich auch den Grund gefunden, warum mein Arbeitsweg vom BRouter nicht gefunden wurde.
Einige Strassen in meiner Umgebung habe ich gerade korrigiert.
Ich bin mal gespannt, wieviele Strassen, die angeblich für Fahrräder verboten sind, ich noch finde.
Bei einigen Bundesstrassen habe ich den Eintrag gelassen, obwohl die eigentlich freigegeben sind. Es ist dort aber schon recht extrem für Fahrräder, da diese Strecken ähnlich wie Autobahnzubringer ausgebaut sind.

Gruß
Bernd
 
Bei mir sind meist Waldwege so gekennzeichnet.
...Ich bin mal gespannt, wieviele Strassen, die angeblich für Fahrräder verboten sind, ich noch finde....
Google fand hierzu z.B. das: http://wiki.openstreetmap.org/wiki/DE:Key:access#Werte
...Wert no --- Benutzung nicht erlaubt oder nicht möglich. ...

Bei einigen Bundesstrassen habe ich den Eintrag gelassen, obwohl die eigentlich freigegeben sind. Es ist dort aber schon recht extrem für Fahrräder, da diese Strecken ähnlich wie Autobahnzubringer ausgebaut sind.

Wie währe es mit:
"unknown " --- Zufahrtsbeschränkungen sind unbekannt bzw. nicht geklärt. "

Währe schön, wenn sich eine Eindeutige Verkehrszeichen-Kennzeichnung durchsetzt, und dann auch vom Router und onlinekarten zuverlässig auswertbar währe / bzw. bereits ist? :
http://wiki.openstreetmap.org/wiki/DE:Road_signs_in_Germany
http://osmtools.de/traffic_signs/

... oder habe ich da etwas grundsätzlich falsch verstanden?

Gruß, Martin
 
Hallo zusammen,

vermutlich wurde das schon einmal diskutiert, aber ich finde leider nichts hierzu: Wie verlässlich sind die Höheninformationen die BRouter verwendet? Hintergrund ist, dass eine meiner Standardrunden per Aufzeichnung mit navi2coach 457 hm hat, per Garmin BaseCamp angeblich 581 und per Brother Web Client sind es dann gar 902.
Heute bin ich eine Runde durchs Siegtal gefahren. Da hat mir der navi2coach 316 hm angezeigt, während BRouter mir 1117 hm anzeigt. Da es nahezu flach ist sind 316 hm glaubhafter. Sollten die Höheninformationen wirklich so daneben liegen und was bedeutet das dann für die Routenplanung?

-- Alex
 
Was für eine Höhe BRouter verwendet, ist Sache des zugrundeliegenden Kartenwerkes. Dieses ist meistens OSM, also crowdsourced. Je mehr Leute tracks erstellen, desto besser wird der Mittelwert der tatsächlichen Höhe. Das ganze ist leider alles andere als einfach, wie Arndt Brenschede hier selber erklärt:


Kurz: GPS ist ziemlich ungenau, und Waldränder oder Häuserschluchten können Messergebnisse sehr verfälschen. Ja, darum sind die selben Routen mit unterschiedlichem Kartenwerk bzw. unterschiedlichen Routing-Service (BRouter oder andere Onlinedienste wie Komoot, GPSies, OpenRouteService, Google Maps, etc.) durchaus unterschiedlich im Ergebnis.
 
BRouter als WebClient rechnet Höhensummen aus, die generell zu hoch sind, vergleichbar mit GPSies. Am Smartphone dagegen rechnet BRouter sehr exakte Höhensummen, die mit Bikeroutetoaster jedes Mal bestätigt werden und dann auch vom Garmin Edge 810 nach der Tour so angegeben werden. Wo der Unterschied liegt, kann ich nicht sagen.

fluxx.
 
Hallo,

BRouter verwendet SRTM Höhendaten. Beim berrechnen verwendet er einen 10 Meter Puffer um das Rauschen in diesen Daten zu unterdrücken. Beim brouter-web werden die ungefilterten Höhendaten angezeigt. In der gpx Datei (mit Texteditor öffnen) stehen die gefilterten Höhenmeter aus der Berechnung die den tatsächlichen Höhenmeter recht nahe kommen und auch von der Android App angezeigt werden.

Gruß Volker
 
Ziel-Ordner: brouter/segments2
........
Diese (und andere) Dateien können hier runtergeladen werden: Klick!

Ich bin gerade mal am weiter einrichten. Auf dem Handy liegen die Daten. BRouter muckt beim Starten aber, weil die lookup.dat fehlt. Die finde ich aber nicht. Habt ihr mir da eine Quelle?

Viele Grüße,
Roland
 
Zurück
Oben Unten