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

Rudiwilli schrieb:
Hi,

nachdem ich erst ein paar Wochen mit einem "VM-wenig Verkehr und geteerte Wege"-Profil experimentiert, Volker mir geduldig gute Hinweise gegeben hat und ich es danach für gut befunden und in den letzten drei Monaten zig Strecken berechnet und abgefahren habe (Bereich NRW, Belgien und NL-da ist es aber nicht nötig, man kann auch gut nach Schildern fahren) bin ich immer begeisterter von der App. Gerade die Ballungszentren Köln-Düsseldorf-Ruhrgebiet werden gut durchschifft. So am letzten Wochenende Köln-Hattingen-Essen-Köln. Wo ich früher mehrere Stunden über MagicMaps gehockt habe, reichen jetzt fünf Minuten am Rechner. Manchmal prüfe ich den Track in GoogleMaps nach oder ich verbinde ihn mit meinen Lieblingsstrecken. Dabei ist das Gesamtergebnis meist besser als früher "von Hand".



Ich lade mal mein Profil hoch. Vielleicht interessiert es Toni oder andere.

Für schnell von A nach B ist das VM-schnell-Profil so gut, daß ich keine Verbesserungsvorschläge habe.

Grüße, Thomas
Zum Vergrößern anklicken....

Hallo @Rudiwilli,
Vielen Dank für dein Profil!
Du nutzt in den Zeilen 3-7 Zuweisungen zu 5 Variablen (allow_steps, allow_ferries usw.), die du danach aber garnicht in deinem Script benutzt. Da es sich, soweit ich verstanden habe, aber nicht um pre-defined Variablen handelt, werden diese Variablen aber nie zur Ermittlung der Route eingesetzt oder?
Vielleicht kann Volker da noch etwas zu schreiben.

Dank an Euch

Grüsse Toni
 
So, jetzt hab ich gestern auch mal das Webfrontend genutzt für Wegevorschläge für die Weihnachtstour.

Weiß wer wie ich die angegebenen Höhenmeter interpretieren soll? 830 m auf 220 km dünken mich mit Überquerung Alb und Nördlinger Ries doch geringfügig optimistisch.
Muß ich das jetzt auf bikeroutetoaster draufhauen und dort die Höhenangaben interpretieren, oder gibts schon Erfahrungswerte, wie sich das unterscheidet? Hier die erste Wahl. Mit Schieber auf 30 komme ich ungefähr in die Richtung, die mir mein Navi zum Schluß anzeigt. Das wären 950 m statt 830. Kann ich davon ausgehen, daß die Fehlweisung verlässlich ist, oder schwankt die wie bei gpsies?
Was ist ascent plain, Start gegen Ende? Oder irgendein Zwischenergebnis?

Warum mit VMschnell Eriskirch-> Wilburgstetten die erste Wahl ab Weingarten bescheuert den Buckel maximal mitnimmt, während die Alternative mit 100 m Maximalhöhe weniger auskommt und diese dafür die Höhenmeter am Schluß großzügiger ignoriert und dafür meine optimierte Strecke ab Stuttgart fährt (aber eben über Eck am Berg) ist mir auch nicht ganz klar. Wird da streng darauf geachtet, die erste Wahl komplett zu ignorieren?

Danke schonmal fürs Aufschlauen,

Tim
 
Wenn Du die betreffenden Tracks hier mal anhängen würdest, kann man vermutlich mehr dazu sagen ... Und, welches Profil nutzt Du genau? Das oben im Web-Frontend ist alt ...
 
Hallo Reinhard,

ich nutze das VM-schnell vom Webfrontend. Hatte ich hier nicht geschrieben.
Kannst ja mal ein Ergebnis eines verbesserten Profils (warum hats im Frontend noch das alte? Kann man ne Änderung triggern?) probieren.

Mir gehts vor allem um die Vergleichbarkeit der Höhenmeterangaben (ich kann mit gemessenen Garmin Etrex am meisten anfangen, das hab ich selber. GPSies wechselt von -10 bis +80%, je nach Strecke. Bikeroutetoaster mit Glättung 30 passt ganz gut mit meinen Messwerten, +-10%) und wie die Alternativen geroutet werden. Ob es z.B. was bringt, den ungewünschten Teil einer Route einzeln nachzurouten.

Gruß,

Tim
 

Anhänge

  • broutertracks.zip
    173,8 KB · Aufrufe: 89
Hi nochmal,

auch wenn ich Volker D. Und Rudiwilli direkt angesprochenen habe, so würde ich mich natürlich auch über jede Antwort von jedem Anderen, der Antworten zu meinen posts #420 und #421 weiß, freuen. Hier haben doch schon einige Leute Profile veröffentlicht.

Schöne Grüße Toni
 
Zuletzt bearbeitet:
fluxx schrieb:
@TimB: Ich lasse mir die brouter.gpx in ShowGPX anzeigen,
Zum Vergrößern anklicken....
Der untersucht nur den Track selber und glättet die Höheninformation noch mal zusätzlich. Aus brouter kommt aber schon der gefilterte Track, oder nicht?
Jedenfalls bekomme ich mit den tracks aus unterschiedlichen Routern auch unterschiedliche Anzeigen - die aber wieder von denen der Erzeugerprogramme abweichen. Bringt mir also nichts.

Gruß,

Tim
 
Hallo Toni

Toni Gemütlich schrieb:
Greift die Routing-engine selbst auf die von dir 5 genannten neuen Variablen zu?
Zum Vergrößern anklicken....

Ja

Toni Gemütlich schrieb:
Gibt es noch mehr neue Variablen, die nicht im Developersguide stehen?
Zum Vergrößern anklicken....

Nein, diese fünf sind die einzigen die neu hinzugekommen sind.

Toni Gemütlich schrieb:
Achso, kannst du mir bitte sinnvolle Ranges für elevationpenaltybuffer, elevationmaxbuffer und elevationbufferreduce nennen?
Zum Vergrößern anklicken....

Das kann man so generell schwer sagen, da sie mit den anderen Variablen zusammenhängen, die wieder vom Fahrzeug abhängig sind. Ich denke für den Anfang reicht es die Standardwerte zu verwenden und nur wenn du mit dem Ergebnis also die Erkennung von Gefälle, Ebene und Steigung nicht zufrieden bist die Werte anzupassen. Dafür solltest du die .csv-Dateien ansehen ob die Kosten an den entsprechenden Stellen passen, wobei du beachten musst dass SRTM-Höhendaten verwendet werden und diese teilweise mehr als 10 Meter von der tatsächlichen Höhe abweichen.

Gruß Volker
 
Toni Gemütlich schrieb:
Du nutzt in den Zeilen 3-7 Zuweisungen zu 5 Variablen (allow_steps, allow_ferries usw.), die du danach aber garnicht in deinem Script benutzt. Da es sich, soweit ich verstanden habe, aber nicht um pre-defined Variablen handelt, werden diese Variablen aber nie zur Ermittlung der Route eingesetzt oder?
Zum Vergrößern anklicken....
Hallo Toni,
ich habe das so verstanden, daß die globalen Parameter primär eingesetzt werden und nicht später noch einmal zu konkretisieren sind. Auf alle Fälle verhält sich die Berechnung so (z.B keine Treppen, nicht ausschließlich Radrouten, Fähren erlauben etc). Probier's mal aus.
Ich sehe, Du willst auch noch Ortschaften umfahren. Das könntest Du über eine Erhöhung der Kosten für Geschwindigkeitsbegrenzungen - hättest die aber auch außerhalb von Ortschaften. Das kommt in meiner Gegend recht oft vor. Deshalb lege ich in solchen Fällen ein oder zwei Zwischenpunkte um solche nicht gewünschten Ortschaften herum, oder Du legst in Locus einen nogo-Punkt an. Z.B. nogoxxxnamedesOrtes, wobei xxx die Meter der nogo-area definiert.
Wenn Dir Verbesserungen einfallen, ich bin interessiert.
Ciao, Thomas
 
Rudiwilli schrieb:
Hallo Toni,
ich habe das so verstanden, daß die globalen Parameter primär eingesetzt werden und nicht später noch einmal zu konkretisieren sind. Auf alle Fälle verhält sich die Berechnung so (z.B keine Treppen, nicht ausschließlich Radrouten, Fähren erlauben etc). Probier's mal aus.
Ich sehe, Du willst auch noch Ortschaften umfahren. Das könntest Du über eine Erhöhung der Kosten für Geschwindigkeitsbegrenzungen - hättest die aber auch außerhalb von Ortschaften. Das kommt in meiner Gegend recht oft vor. Deshalb lege ich in solchen Fällen ein oder zwei Zwischenpunkte um solche nicht gewünschten Ortschaften herum, oder Du legst in Locus einen nogo-Punkt an. Z.B. nogoxxxnamedesOrtes, wobei xxx die Meter der nogo-area definiert.
Wenn Dir Verbesserungen einfallen, ich bin interessiert.
Ciao, Thomas
Zum Vergrößern anklicken....

Hallo Thomas,

da habe ich mich missverständlich ausgedrückt: die von mir angesprochen Variablen werden meines Wissens nicht von der Routing-engine genutzt (oder doch? Steht nix von im Developersguide) Eine Definition eigener Variablen bringt nur etwas wenn man sie dann auch irgendwie in seinem Script auch später nutzt. Aber wenn trotzdem schöne Routen rauskommen, who cares!

Viele schöne Routen noch

Toni
 
Zuletzt bearbeitet:
Hi Rudiwilli,

Jetzt will ich es aber wissen: :D habe mal dein Profil mit und ohne die Zeilen 3-7 über eine Strecke von 165km routen lassen, kommt exakt die gleiche Route raus.
Fürs Nachvollziehen ist es wichtig, dass man entweder das Profil umbenennt oder die erste Berechnung aus dem Zwischenspeicher löscht damit brouter nicht annimmt, dass man eine Alternative berechnen lassen will.
Trotzdem finde ich dein Profil schon ganz gut gelungen. Ich werde zur Vermeidung von Innenstädten es nur mit maxspeed=50 und Source:maxspeed=DE:urban versuchen.

Schöne Grüße Toni
 
Ich versuche gerade eine vernünftige Strecke von Dronten nach Nijmegen zu finden und bin sehr verwirrt, dass Brouter für VM eine 20 km längere Strecke ermittelt wie für Liegeräder.
Kann es sein, dass in Holland das Profil Liegerad-schnell besser geeignet ist, da das VM-Profil versucht die "guten" Radwege zu vermeiden ?
In Deutschland dürfte es wohl erheblich sinnvoller sein die Radwege zu vermeiden.

Gruß
Bernd
 
berbr schrieb:
Ich versuche gerade eine vernünftige Strecke von Dronten nach Nijmegen zu finden und bin sehr verwirrt, dass Brouter für VM eine 20 km längere Strecke ermittelt wie für Liegeräder.
Kann es sein, dass in Holland das Profil Liegerad-schnell besser geeignet ist, da das VM-Profil versucht die "guten" Radwege zu vermeiden ?
In Deutschland dürfte es wohl erheblich sinnvoller sein die Radwege zu vermeiden.

Gruß
Bernd
Zum Vergrößern anklicken....
Hallo,

in den Niederlanden (in Deutschland gibt es auch solche Stellen) werden Straßen mit parallel verlaufenden Radwegen mit bicycle=no getaggt. Da die Radwege im VM-schnell Profil auch hoch bestraft werden, bleiben kaum noch "gute" Wege. Die einzige Möglichkeit ist im VM-schnell Profil bicycle=no zu entfernen und das Risko von tatsächlich verbotenen Wege in Kauf zu nehmen.

Gruß Volker
 
Hallo Volker,

gibt es irgend eine Möglichkeit diese Straßen zu identifizieren und somit in ein VM-Profil zu integrieren ?
Volker D. schrieb:
Straßen mit parallel verlaufenden Radwegen
Zum Vergrößern anklicken....
Notfalls müsste man dann halt den Radweg nutzen, würde aber zumindest nicht auf wirklich gesperrte Strecken kommen und müsste andererseits keine unnötigen Umwege fahren.

Gruß
Bernd
 
berbr schrieb:
Hallo Volker,

gibt es irgend eine Möglichkeit diese Straßen zu identifizieren und somit in ein VM-Profil zu integrieren ?

Notfalls müsste man dann halt den Radweg nutzen, würde aber zumindest nicht auf wirklich gesperrte Strecken kommen und müsste andererseits keine unnötigen Umwege fahren.

Gruß
Bernd
Zum Vergrößern anklicken....

Hallo Bernd,

um eher Radwege zu verwenden müssen dafür die Kosten gesenkt werden, das läuft aber dem Gedanke dieses Profils entgegen. Man ist dann eher bei lr-schnell. Mit BRouter ist es nicht möglich parallel verlaufende Straßen abzufragen (das wirft auch die Frage auf ab wann die Wege als parallel zählen sollen und wann nicht) und damit die Kosten zu modifizieren. Falsches taggen ist mit einem Router kaum zu korrigieren.

Gruß Volker
 
Habe ich das richitg in Erinnerung, dass die Alternativrouten entstehen, indem die erstgerechneten Routen mit erhöhten Kosten belegt werden ?

Könnte man diese Technik nutzen um vorher ermittelte Routen mit Minderkosten zu belegen ?

Wäre es so möglich bereits bekannte GPX-Files als Vorzugsrouten einzubinden ?

Gruß
Bernd
 
berbr schrieb:
Habe ich das richitg in Erinnerung, dass die Alternativrouten entstehen, indem die erstgerechneten Routen mit erhöhten Kosten belegt werden ?

Könnte man diese Technik nutzen um vorher ermittelte Routen mit Minderkosten zu belegen ?

Wäre es so möglich bereits bekannte GPX-Files als Vorzugsrouten einzubinden ?

Gruß
Bernd
Zum Vergrößern anklicken....

Hallo Bernd

Prinzipiell schon, ist aber mit Schwierigkeiten verbunden, da die einzelnen Segmente exakt denen von Openstreetmap entsprechen muss (und allen Änderungen die kommen werden).

Gruß Volker
 
Oben Neue Beiträge
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten