BRouter: offline Fahrrad-Routing für Android

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)

Um bei dem Beispiel oben von schiki zu bleiben: Ich denke, dass der “Fuss”-weg hier falsch getaggt ist. Wenn der Fußweg “keinerlei Beschilderung” hat, warum ist es dann ein Fußweg? Bei einem Fußweg parallel zur Straße (Sidewalk) ist es eindeutig, wenn kein Schild da steht. Aber ein (Fuß-)weg ohne Straße ist nicht zwangsläufig ein reiner Fußweg, oder?

PS: Wieso steht eigentlich in dem Bild ein Straßenname auf dem Kopf? Da ist doch ein kleiner Bug im Renderer… :smiley:

Dann ist footway aber eindeutig falsch.
Möchtest Du auch durch Fussgängerzonen und über Waldwege geroutet werden?

Gegen einen Schalter im Router (strikt / fuzzy - Routing) ist ja nichts einzuwenden aber standardmäßig sollte
er sich schon ein wenig an die Regeln halten.

ja schon. Mit Kostenfaktor 5 durch eine Fussgängerzone zu routen heisst ja nichts anderes als dass
es sich auch lohnt, wenn man da 5 mal langsamer (=20/5 = 4 kmh) unterwegs ist, sprich absteigen.

Gleiches gilt für Einbahnstrassen.

Gruss, Arndt

Hallo Arndt

Das soll dann bitte auch entsprechend hervorgehoben und als Alternative zum StVO-gerechten Routing eingezeichnet sein.
Mit einer Hervorhebung + Alternative könnte man Rad-Routing auch über Treppen zulassen. Mit einem Kostenfaktor von ca. 10 (entsprechend 2 km/h) würde das in etwa passen.

Edbert (EvanE)

Wieso routet mich der router über den Weg http://www.openstreetmap.org/browse/way/85416982
Tut OsmAnd im offline modus auch… (schon gemeldet als http://code.google.com/p/osmand/issues/detail?id=1380)
Als OsmAnd Plugin wäre dein Router super :slight_smile:

Wenn man so etwas einbaut sollte dies deutlich hervorgehoben werden bzw. schon gleich am Anfang drauf hinweisen das es solche Teilstücke gibt. Wenn man mit Gepäck und/oder Anhänger unterwegs ist dann sind Treppen auch nicht mit 2km/h zu bewältigen.

Welchen Router Du auch immer meinst. Wenn er über access=no routet ist er defekt.

Hallo Holger,

Access=no genauso wie vehicle=no wird zur Zeit vom BRouter nicht ausgewertet, siehe auch https://groups.google.com/forum/#!topic/osm-android-bikerouting/CZ3HK64AMgA

Gruß Schiki

Ich schrieb nicht umsonst “als Alternative”. Jeder kann dann selbst entscheiden, ob das für ihn/sie machbar ist. Die ‘alte Oma’ wird diese ‘Alternative’ ggfs. auch nicht nutzen wollen.

Darüber hinaus sollten solche rechtlich oder physisch problematischen Stellen per Einstellung von Vermeidungen ausgeschlossen werden können.

Edbert (EvanE)

Nahmd,

.oO( zum Beispiel sac_scale=demanding_mountain_hiking )

Gruß Wolf

Ganz so einfach ist es nicht. access=no definiert ja nur den default-acess, der dann von bicycle=… oder foot=… wieder überschrieben werden kann.

Ich habe jetzt zwei Anpassungen gemacht (in allen Profilen ausser "shortest):

  1. zum Problem access=no und HolgerJeromin’s Beispiel in Hilden

switch and access=unknown
and or bicycle= bicycle=no
or highway=track or highway=road or highway=path or highway=footway highway=service
100000

Tatsächlich ist access=no nicht in der atuellen lookup.dat, also musste ich access=unknown benutzen (=alles, was nicht leer ist und und in lookup.dat aufgeführt). Durch jedes “bicycle” tag ausser “no” wird es wieder aufgehoben. Ausserdem musste ich den Filter auf den highway-typ ergaenzen, sonst hatte ich beispiele in meiner Testsuite mit highway=residential, access=designated, die auch den Ausschluss getriggert haben.

Das in der google-group genannte Beispiel an der Kaiserbrücke in Mainz lässt sich damit aber nicht erschlagen, weil hier nur die access=no und barrier=gate tags an den Nodes stehen und nicht am way, und node-tags kann brouter noch nicht.

  1. zum Problem cycleway=opposite*

Habe ich ergaenzt in der oneway-berechnung als:

   switch or cycleway=opposite cycleway=opposite_lane 0

(=keine oneway-strafe für diese beiden werte) cycleway=opposite_track fehlt leider auch in lookups.dat, aber so viele sind das nicht.

Sobald ich die Beschränkung für die Menge von Tags in den routing-data-files nicht mehr habe, kann man das sicher noch besser machen.

Steht drin im trekking-profil, allerdings mit Kostenfaktor=40. Mit 10 hat er mir persönlich zu viele Treppen gefunden.

Gruss, Arndt

Hallo Arndt

Sehr schön, kommt mir aber sehr viel vor. Muss man aber vielleicht vom Typ des Radfahrers abhängig machen. Ein MTBler käme wahrscheinlich mit Kostenfaktor=20 klar. Beim Rennrad weiß ich es nicht so genau. Einerseits wollen die schnell sein und ihr Rad ist eher leicht, anderseits steigen die ungern ab.

Wie sieht es mit einem Profil für Räder mit Anhänger aus? Das hat auf meinen Treppenvorschlag hin jemand als Einwand gebracht. Anhänger unterliegen ja besondere Einschränkungen / Notwendigkeiten (Mindestbreite, Gewicht, sperrig, …).

Um klar zu machen, um was es mir geht, hier ein Beispiel einer Eisenbahnbrücke mit Radweg über die Sieg.
Ohne Beachtung der Treppe ergibt das folgende hübsche Route. Da die vorgeschlagene Route vor Ort nicht direkt erkennbar ist, nehmen viele, die zum Weg entlang der Sieg wollen, halt die Treppe.

Edbert (EvanE)

Mal ne Zwischenfrage zu meinem besseren Verständnis: “Kostenfaktor=1” heisst bei Euch “man kann da mit 20 km/h fahren”? Welchem key bei OSM entspricht das?
Grüße, Max

Hallo Max

Ich denke man kann mit der einem eigenen Geschwindigkeit fahren ohne weitere Beschränkungen. Das kann in deinem Fall 10 / 15 / 20 / 25 / 30 oder 35 km/h sein. Ein besonderes Tag braucht es dafür wohl kaum.

Die Menschen und ihre Fahrräder sind verschieden, was zu sehr unterschiedlichen Durchschnittswerten auf gerader, ebener Strecke führt. Oder wie sagte ein Bekannter, der täglich 12 km zur Arbeit und wieder zurück fährt:
30 km/h ist doch gemütliches Einrollen (auf einem Rennrad in der Gruppe).
Ich selbst bin froh, wenn ich (allein) auf ebener Strecke mit meinem Rad zwischen 20 und 25 km/h schaffe.

Der Kostenfaktor dient vor allem dazu, Wege mit Eigenschaften, die man vermeiden möchte, mit einem Malus bei der Berechnung der Route zu belegen. Daneben fließt der Kostenfaktor wahrscheinlich in die Berechnung der Zeit für die Route ein. Und ja, es wäre schön, zu wissen, wie das im konkreten Fall des Brouter gehandhabt wird.

Nur meine Vermutungen
Edbert (EvanE)

Mit Faktor 40 für Treppen macht BRouter auch den langen Looping, bis 30 hätte er die Treppe genommen. Man kann sowas in der Online Version selber ausprobieren, indem man über den Upload-Button ein modifiziertes Profil hochlädt (was dann als “custom” in der Auswahlbox steht)

Ich hatte den Fall noch nicht, aber ich würde, ausgehend from trekking-profil, Fusswege und Treppen konsequenter vermeiden.

Ja genau, nur dass BRouter keine Zeiten ausrechnet.

Der Router sucht den Weg mit den geringsten “Kosten”, was aber ein rein abstraktes Konzept ist. Die Kosten werden zwar in Metern gezählt, meinen aber was anderes als die Länge der Route.

Der Hauptteil der Kostenfunktion ist dieser entfernungsabhängige Teil, also immer Wegstrecke mal Kostenfaktor, und das über alle Wegstücke aufsummiert. Es gibt aber noch zwei andere Teile in der Kostenfunktion, dass eine sind die Winkelkosten (“turncost”) und das andere die Höhenkosten (“elevationcost”).

Gerade am Beispiel der “turncost” wird deutlich, dass das Konzept tatsächlich abstrakt ist. Er rechnet für eine 90-Grad Ecke Zusatzkosten von 90m. Das wäre aus der Sicht einer Zeitbetrachtung ja viel zu viel (man braucht keine 16 Sekunden zusätzlich, um um eine Ecke zu fahren). Man muss das eher als Filter verstehen, der verwinkelte Wege vermeidet, weil in verwinkelten Wegen mehr böse Überraschungen stecken als in geraden.

Der Kostenfaktor muss möglichst nahe bei 1 sein für die Art von Wegen, die man sucht, weil sonst durch die Art der Berechnungsmethode das “Suchgebiet” zu gross wird und die Berchnung dann zu lange dauert. Und er darf nicht kleiner als 1 sein, weil sonst die Berechnung nicht mehr funktioniert.

Interessant, also durchaus so wie ich es erwartet hätte.
Schön dass man bei Brouter das im Detail sehr genau einstellen und auch probieren kann.

Kommt wie immer darauf an. Rechts abbiegen verursacht (bei uns) relativ wenig Kosten, man sollte allerdings auf den Querverkehr achten. Beim links abbiegen hingegen muss man ggfs. recht lange auf den Gegenverkehr warten. Solange man rechts/links abbiegen nicht unterscheidet, scheint mir das ein recht guter/brauchbarer Mittelwert zu sein.

In der Tat gibt es viele (mich eingeschlossen) die eher eine einfache (wenige Abbiegevorgänge), leicht zu merkende Route auswählen, wenn sie ohne Router selber planen, als die letzten Meter sparen zu wollen.

Wie sieht es mit Kreuzungen (gleichrangig, niederer / höher Rang, mit Ampel geregelt) aus. Werden die in der Kostenfunktion berücksichtigt? (Für Bahnübergänge und Fähren ergibt sich die gleiche Frage.)

Edbert (EvanE)