BRouter: offline Fahrrad-Routing für Android

Hallo,

ich bin darauf aufmerksam gemacht worden, dass hier in diesem Forum Interesse daran bestehen könnte:

Ich habe meinen eigenen OSM-Fahrrad-Router so halb veröffentlicht: http://brouter.de/brouter

Es ist primär ein Offline-Router für Android, der zusammen mit OsmAnd für Fahrrad-Navigation benutzt werden. Beim Fahrrad-Routing kann er sich gut mit der Konkurrenz messen, insbesondere durch die Integration der SRTM-Höhendaten, aber auch durch die sehr flexiible Konfiguration, die Berücksichtigung von Fernradwegen, die Möglichkeit, Alternativen zu berechnen.

Das Feedback, was ich bisher bekommen habe ist, dass die Routing-Ergebnisse erstaunlich gut sind, das Handling fürs Offline-Routing aber noch etwas sperrig und eher was für Techies.

Es gibt aber auch eine Online-Version, die einfacher zu verdauen ist und auch schon viel Freude macht.

Viel Spass damit,

Gruss, Arndt

Dann habe ich gleich mal eine Frage: Was bedeutet diese Fehlermeldung.

Was noch schön wäre, wenn man Zwischenziele setzen könnte.

Hast Du den Favoriten vielleicht To statt to genannt? Ist mir zu Anfang auch passiert.

Ich habe inzwischen mal getestet, wie gut die Routen aus 15-20 km Entfernung zum Terminal 1 von FRA sind.
Das Fahrrad ist ja dafür nicht gerade das gängige Verkehrsmittel, es müssen Autobahnen, Bahnlinien und der Main irgendwo vernünftig überquert werden. Anstiege spielen dabei so gut wie keine Rolle, wenn man in der Nähe des Mains startet.

Es ist damit in erster Linie ein Test der Qualität des Routers und der Fahrrad-relevanten Tags im Umkreis des Flughafens.

Das Ergebnis war wirklich beeindruckend, auch die in der Online-Version möglichen 3 Alternativen machten absolut Sinn.

Herausragendes Merkmal des Router’s ist, dass man den Kostenfaktor abhängig von den Tags quasi selbst programmieren kann und Anstiege auf Wunsch mit berücksichtigt werden.

Wer kein OSMAND hat, kann auch die Onlineversion benutzen, der GPX-Track mit Höhenangaben lässt sich herunterladen und mit einem beliebigen Tool darstellen.

Gruß Schiki

Es bedeuted, er hat die Startposition zwar aus der OsmAnd-Favoriten-Datei lesen können, aber keinen “closest distance node” dazu gefunden innerhalb seines Suchquadrats (ca 6*6 km).

Grund kann entweder sein, dass es (unwahrscheinlich) wirklich keinen gibt, oder (wahrscheinlich), dass für das Gebiet kein Routing-Data file (rd5) hinterlegt ist. Die Files tragen immer die Süd-West-Ecke des 5 Grad*5 Grad Quadrats im Namen, also braucht man z.B. für 8 Grad Ost / 48 Grad Nord die Datei E5_N45.rd5

Ich weiss :slight_smile: Ich will aber diese Hilfskonstruktion mit der Parameterübergave über die Favoriten-Datei nicht weiter aufbohren und arbeote stattdessen an einer besseren Integration, bei der man den internen Router von OsmAnd durch einen externen ersetzen kann, den aber genauso bedienen.

Die Routen sind in der Tat top.

Mit einem guten Userinterface könnte es einer der besten OSM-Rad-Router werden.

Chris

Finde die Routen auch interessant, allerdings wird ähnlich wie bei Navit vor surface=“cobblestone” nicht zurückgeschreckt.

Nach diesem Satz ist es wie auch bei Navit allein deine Schuld! Es hat jeder andere Präferenzen und Vorstellungen. Daher ist es schön einen Standardprest zu haben, welcher möglichste vielen hilft (Mehrzahl der Beiträge klingen sehr zu frieden) und für den Rest eine Möglichkeit zur Anpassung bieten. Du kannst ja auch damit etwas spielen und dann deine Parameter hier vorstellen. Vielleicht sind sie in der Tat noch besser.

Radfahrer oder Weichei? :wink: duckundweg

Ich finde den Router auch nicht schlecht. Die Routenvorschläge sind in Ordnung, obwohl ich ein Seitenstraßenundwirtschaftswegeradfahrer bin. :slight_smile:

Schick finde ich v.a. die Einbeziehung der Höhe, und überhaupt den Router nicht nur für Radfahrer, sondern auch für Fußgänger sehr interessant. Nach so etwas war ich eine Weile auf der Suche, und hier scheint es mal gut zu funktionieren. Bisschen schade vielleicht, dass es (nach der Tabelle im Wiki) nicht open source ist, aber vielleicht ändert sich das ja nochmal?

Wie genau ist das mit der Steigung denn realisiert, ließen sich damit auch Profile wie “vermeide Steigungen > 7 %” oder ähnliches realisieren oder geht das mit dem Datenmodell nicht?

Ja vielleicht. Es ist ein Hobbyprojekt. Im Moment will ich’s einfach nur gut hinkriegen bevor im Sommer die Radler wach werden, danach will ich’s irgendwie vom Tisch kriegen. Im Moment bekomme ich tollen Feedback, auch über Fehler, und da ist noch was zu tun am Router selbst.

Es geht mit den Daten nicht. Die SRTM Daten haben ein 90-Meter Raster, was z.B. in engen Flusstälern zu erheblichen Gitterfehlern führt, ausserdem hat der Radar nicht immer den Boden gemessen sondern auch Dächer und Baumwipfel. Deswegen verwendet der Router ein 10-Meter hohes “Hysterese-Band”, das diese Effekte rausfiltert. Das führt aber dazu, dass die Kosten aus der Steigung nicht lokal zugeordenet werden können, sodass man nicht wirklich lokal die Steigung bewerten kann (Nebenbei führt so eine “nicht-Lokalität” in der Kostenfunkion auch dazu, dass Dijkstra’s Algorithmus eigentlich nicht funktioniert, aber das ist ein anderes Kapitel)

Ich habe mich beim Test des brouters mal etwas näher mit dem Thema Routing basierend auf OSM-Daten, im besonderen beim Fahrrad-Routing, beschäftigt. Aufgefallen ist mir dabei folgendes:
Laut deutschem Wiki gilt in Deutschland für einen footway ohne weitere Tags implizit bicycle=no. Ob das praxisgerecht ist, kann man lange diskutieren, meist sind es nur kurze Wege, wo man auch absteigen könnte, wenn man sehr gesetzestreu ist. Die einzigen von mir gefundenen Router, die solche Wege wirklich ausschließen, sind der brouter und openrouteservice.org. OsmAnd Local, Yours und Cloudmade routen bedenkenlos über solche Wege. Vielleicht sollte man für das Fahrrad-Routing das implizite bicycle=no auf auf foot=designated beschränken, bei weitem nicht jeder Weg highway=footway hat das entsprechende blaue Schild.

Gruß aus Rheinhessen Schiki

Ausschluss war garnicht mein Gedanke. Mein Hauptaugenmerk war, nicht im Matsch versinken zu wollen. Und da habe ich gelernt, dass man sich auf track/path/footway ohne weitere Tags nicht verlassen kann. Trotzdem gilt im trekking-Profil Kostenfaktor 5, das ist noch kein Ausschluss. Anbei der Ausschnitt aus dem Skript - die allerletzte Zahl ist diese 5. Aber beachte: z.B. highway=footway surface=paved bekommt die 1. Aber praktisch ist mir noch kein Fall vorgekommen, wo ich dadurch ein blaues Fussgängerschild misachten musste.

tracks and track-like ways are rated mainly be tracktype/grade

But note that if no tracktype is given (mainly for road/path/footway)

it can be o.k. if there’s any other hint for quality

switch or highway=track or highway=road or highway=path highway=footway
switch tracktype=grade1 switch probablyGood 1.0 1.3
switch tracktype=grade2 switch probablyGood 1.1 2.0
switch tracktype=grade3 switch probablyGood 1.5 3.0
switch tracktype=grade4 switch probablyGood 2.0 5.0
switch tracktype=grade5 switch probablyGood 3.0 5.0
switch probablyGood 1.0 5.0

naja, sagen wir, weil sie falsch getaggt sind ignorieren wir auch die richtig getaggten oder sagen wir, sie sind falsch getaggt, lasst uns das korrigieren?

Zwischenfrage zum Thema: Hier in der Gegend gibt es mindestens eine Brücke über den Küstenkanal, die von beiden Seiten bis zur Brücke einen kombinierten Rad- und Fußweg aufweist (getrennt von der Straße gemappt), der aber auf der Brücke (also für < 20m) nur für Fußgänger erlaubt ist (weil eng). Das ist hier http://www.openstreetmap.org/browse/way/40691688 noch falsch getaggt, aber ich bin mir nicht sicher, ob ich, wenn ich das korrigiere, nicht das Fahrradrouting “kaputt” mache. Trotzdem ändern?

Nach meiner Ansicht sollte der Weg als footway getaggt werden, wenn das blaue Schild vorhanden ist. Falls nicht, dann eher path.
Zusätzlich noch bicycle=dismount setzen - siehe http://wiki.openstreetmap.org/wiki/Bicycle. Ein besserer Fahrradrouter sollte damit umgehen können.
Beim BRouter kann man dismount im Profil verwenden und er berücksichtigt auch noch, dass der Weg Teil einer Radroute ist.

Rein nach StVo gibt es zwei Dinge, die ein Radfahrer in der geschilderten Situation machen darf:

  • Auf die Straße wechseln
  • Absteigen und damit zum Fußgänger werden.

Ich würde (soweit es in der Realität möglich ist) den Fahrradweg an die Straße anbinden und das Wegstück über der Brücke als Fußweg erfassen. Laut Bing sieht es so aus, als wäre das möglich.

Ob ein Radfahrer das beachtet oder nicht, liegt in der Verantwortung des Einzelnen. Vor allem von Süden nach Norden ist der Aufwand mit zweimal Queren der Fahrbahn durchaus hoch. Am falschen Routing aufgrund fehlerhafter/unvollständiger OSM-Daten liegt es dann jedoch nicht mehr.

Edbert (EvanE)

Ich bin schon oft dort vorbeigefahren. Einen Radfahrer auf der Straße habe ich dort noch nie gesehen. Zuviel Verkehr. Zu gefährlich.

Das wundert mich nach dem Anschein des Luftbildes nicht wirklich.
Ausgeschilderte Regelungen und gelebte Praxis sind halt manchmal zwei sehr verschiedene Dinge.

Dennoch sollten wir es in den OSM-Daten so eintragen, wie es beschildert ist. Auf dem kurzen übersichtlichen Stück kann jeder Radfahrer selber entscheiden, ob er/sie die Regeln befolgt oder es vorzieht nicht die Straße zu benutzen.

Edbert (EvanE)

Was herauskommt, wenn ein (Fahrrad)-Router primär nur mit den impliziten restrictions arbeitet, kann man in dem Beispiel aus Wiesbaden für openrouteservice sehen.
Zwei kurze Fußwege, die breit genug zum Fahrradfahren sind, keinerlei Beschilderung haben und entsprechend nur mit hiqhway=footway getagged sind, werden zugunsten eines großen Umwegs über stark befahrene Hauptdurchgangsstraßen nicht gewählt. BRouter und OsmAnd-Local dagegen routen beide direkt über die Fußwege.

Bild leider weg

DU willst also ernsthaft vorschlagen, dass Fahrrad-Router die Verkehrsregeln missachten sollen.
Nun ja seien wir nicht so bescheiden, warum sollen Fahrrad-Router nicht auch über Treppen routen. Ist doch meist viel kürzer?

Ausnahmen von den Verkehrsregeln mag ein einzelner Radfahrer in seiner eigenen Verantwortung ja mal machen. Ein Router sollte so etwas jedoch wirklich nicht von sich aus vorschlagen.

Edbert (EvanE)