BRouter: offline Fahrrad-Routing für Android

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)

Schlecht :slight_smile:

Mit Ampeln ( highway = traffic_signals als node-tag ) hatte ich experimentiert, aber davon gibts einfach zu wenig in der Karte, schon garnicht an den Nodes von strassenbegleitenden Radwegen.

Über so eine Bewertung von Kreuzungen nach Richtung und Rang habe ich tatsächlich nachgedacht und so könnte man, auch mit vorhandenen Kartendaten, wohl auch tatsächlich bessere Wege finden, aber das war mir bisher zu schwierig.

Bahnübergänge kennt BRouter bisher nicht.

Über eine Fähre bin ich letzte Woche selbst gestolpert, stand plötzlich am Main an so einer kleinen Schönwetter-Ausflugsfähre, weil ich vergessen hatte, das “no ferries” Profil zu benutzen. Fähren waren deswegen schwierig, weil sich kein Kostenfaktor finden liess, der für diese kleinen Main-Fähren genauso funktioniert wie für die Bodenseefähren. Deswegen habe ich die Berechnung von Fähren jetzt nochmal geändert: sie bekommen jetzt einmalige Zusatzkosten von 10km, unabhängig von der tatsächlichen Wegstrecke der Fähre, und dann noch Kostenfaktor 5 für die Wegstrecke. Damit werden die kleinen Main-Fähren nicht mehr gefunden (weil die nächste Brücke ja nie weit ist), die Rhein-Fähren aber doch.

Gruss, Arndt

Hallo Arndt,

war das zufällig diese Fähre? http://www.openstreetmap.org/?lat=50.05032&lon=8.50211&zoom=16
Hatte ich auch schon in einer vom Brouter berechneten Route drin, fährt aber nur an Ausflugstagen.

Mit den beschriebenen Modifikationen ist der BRouter sicher noch ein gutes Stück besser geworden, ich werde ihn mir in den nächsten Tagen auf mir bekannten Terrain nochmal anschauen, aber nur theoretisch - momentan zu kalt und zu viel Schnee.

So etwas ähnliches mit unterschiedlichen Profilen gibt es jetzt auch für Bergwander in den Alpen, allerdings auf ein bestimmtes Gebiet beschränkt und nicht als App für das Smartphone: http://geo.dianacht.de/topo/ - von Netzwolf entdeckt.
Für Wanderer im Gelände ist glaube ich die Berechnung deutlich einfacher, es müssen nicht so viele unterschiedliche Tags berücksichtigt werden.

Gruß Schiki

Jo, das ist kein Kunststück im Vergleich zu Arndts Fahrradrouting. Da stecken ein paar Verbotsregeln, paar Strassenklassen, Wanderwegrelationen, sac_scale und Höhenmeter drin. Fussgänger haben ja selten Einbahnstrassen, dürfen überall abbiegen und die Zielgruppe kann auch Treppen steigen. Das mit den Strafpunkten fürs Abbiegen finde ich als Idee gut, dann läuft man nicht im zickzack durch die Häuserblocks. Aber das ist auch eher in Städten interessant ist als im freien Gelände.

Grüße, Max

Hallo Max

Neben dem “zickzack durch die Häuserblocks” gibt es noch den Fall kurze, steile Zick-Zack Strecke gegen eine längere, weiter geschwungene, weniger steile Strecke einen Berg hinauf. Da können die Präferenzen durchaus unterschiedlich liegen. Auch beim Fußgängerrouting kann ein Malus fürs Abbiegen also sinnvoll sein. Über die Größe des Malus müsste man dann gegebenenfalls mal nachdenken.

Edbert (EvanE)