Es dürfte so sein, dass Fahrradnavigation keine Probleme verhindert, sondern hilft sie zu lindern. Dazu hilft Blick auf das Display und denken.
@ GS_E Ich treibe mich schon lange in Fahrradforen herum. Lies dir mal einfach Diskussionen durch, wie mancher über einen Routingalgorithmus schimpft, andere ihn loben. Dann gibt es die Neulinge, die versuchen ihre Unzufriedenheit wegzuorganisieren (zu denen ich dich einordnen würde). Letztlich kommt allen die Erkenntnis, man muss auf sein Routing aufpassen, und zwar deutlich mehr als beim Auto. @ aighes wird mir vermutlich zustimmen.
iD zeigt wahrscheinlich in den Eigenschaften die von Taginfo ermittelten 8 häufigsten Werte an (der Häufigkeit nach sortiert): tracktype | Keys | OpenStreetMap Taginfo
ob man Werte mit 0.01% noch anzeigen will ist vielleicht Geschmacksache, aber 0.00% wohl eher nicht
Die reine Anzeige schadet ja niemandem, aber ziemlicher Blödsinn ist m.E., dass man aus der Anzeige der Eigenschaften heraus auf einen der unsinnigen Werte (z.B. tracktype=3-5) klicken und damit als “Korrektur” übernehmen kann.
Dazu will ich noch ergänzen, dass es ja auch den umgekehrten Fall gibt, bei dem bestimmte Wegstücke überwiegend permanent nass sind, weil dort Sickerwasser austritt und es nur in lang anhaltenden sommerlichen Trockenperioden zur Abtrockung der Oberfläche kommt. Die müsste man dann eigentlich auch irgendwie berücksichtigen.
Über welche Art von “Restrouting” sprechen wir da? Wenn man sein Rad (und sich selbst) nicht einsauen will, dann ist doch eigentlich schon 1 Meter Matschpiste einer zu viel. Es gilt also nur diejenigen Wege, die bei Nässe ein hohes Risiko bergen, matschig zu sein, komplett vom Routing auszuschließen. Also je nachdem, wie risikofreudig man ist, alles bis runter zu tracktype=grade2.
Je nach Routingsoftware kann die Auswahl oder Ausschließung von bestimmten Wegeeigenschaften selbst konfiguriert werden.
Im bikerouter.de kann beispielsweise eine Auswahl von bestimmten Wegoberflächen erstellt werden und diese dann für das Routing ausgeschlossen werden.
Hier wäre beispielhaft eine Selektion von “festen” und “unfesten” Wegen. Die Liste kann ganz nach Belieben verändert werden. Eine Person auf einem TT-Rennrad würde hier wohl Werte wie “sett” oder “paving_stones” in unpaved zuordnen. Eine Person auf einem Downhill würde die Auswahl vielleicht komplett umdrehen, da diese mud lieber mag als asphalt.
assign ispaved = or surface=paved|asphalt|concrete|wood|paving_stones|metal|sett or cycleway:surface=paved|asphalt|concrete|paving_stones|sett ( and surface=concrete concrete=plates|lanes )
assign isunpaved = or surface=unpaved|compacted|gravel|pebblestone|ground|dirt|grass|mud|sand|cobblestone|fine_gravel|earth|grass_paver cycleway:surface=unpaved|compacted|gravel|cobblestone|fine_gravel
Im weiteren Schritt kann dann beispielsweise der tracktype eines highway=track in Kombination mit den oben definierten surface-Werten zu einer Berechnung des Cost Factor verwendet werden. (Je höher der Cost Factor, desto weniger wird dieser Weg für das Routing verwendet)
if ( highway=track|road|path|footway ) then
(
if ( tracktype=grade1 ) then ( 1.0 )
else if ( tracktype=grade2 ) then ( if ispaved then 1.1 else 2.5 )
else if ( tracktype=grade3 ) then ( if ispaved then 10.0 else 9999 )
else if ( tracktype=grade4 ) then ( if ispaved then 15.0 else 9999 )
else if ( tracktype=grade5 ) then ( if ispaved then 20.0 else 9999 )
else ( if ispaved then 1.1 else 3.0 )
)
Ein highway=track mit tracktype=grade3 und einer nicht befestigten Oberfläche (isunpaved) bekommt einen Cost Factor von 9999. Mit diesem Wert wird der Weg ganz niedrig für das Routing eingestuft und nur gewählt, wenn im Extremfall alle anderen Wege die in Frage kommen würden beispielsweise ein access=no haben. Man könnte hier auch ein Wert von 10000 definieren, dann würden die Wege nie verwendet werden.
Hier ein Beispiel von unterschiedlichen “Cost Factor”-Werten in der Spalte $/km:
In diesem Fall hat ein Fußweg mit bicycle=yes eine “schlechtere” Wertung / Cost Factor als eine Wohnstraße mit maxspeed=30. Zumindest in diesem (sehr guten) Fahrradprofil von FFMbyBicycle.
Wie man an dem Beispiel sehr gut sehen kann, reichen bereits drei Attribute in OSM um einen Weg für das Routing auszuschließen. Ein vorhandenes smoothness oder das Vorhandensein einer Fahrradroute auf dem Weg erlauben natürlich noch eine exaktere und detailliertere Berechnung des Cost Factor.
Beantwortet das deine Frage nach dem “Restrouting”?
Noch ein ergänzendes Beispiel zu dem obigen Text direkt im BRouter / bikerouter:
Sortiert man im Datenreiter nach $/km (absteigend), so gibt es drei Wege mit einem Kostenfaktor von 103050 pro km. Bei einem so hohen Wert versucht der Router mit allen Mitteln eine andere Route zu finden. Da aber zwischen Sölden und Meran keine günstigere Passstraße existiert, wird diese Verbindung dennoch verwendet.
@mcliquid, wenn ich es richtig in Erinnerung habe, dann sind Wege bei BRouter bereits ab einem Kostenfaktor von 9999 komplett vom Routing ausgeschlossen. 10000 (oder mehr) hat lediglich den Zusatzeffekt, dass sie auch nicht mehr beim Generieren der Navigationshinweise berücksichtigt werden.
Beim Thema “Matsch vs. kein Matsch” gibt es ja eigentlich keine sinnvolle Abwägung der Form “Tausche x Meter Matsch gegen y * x Meter Umweg”, denn mehr als dreckig kann das Fahrrad ja nicht werden. Deshalb wundere ich mich eben ein wenig über den Begriff und frage mich interessehalber, wie es genau gemeint war.
@Quaternion Wenn es keine andere (bessere) Variante gibt, kann auch ein Weg mit Wert 9999 verwendet werden, wie du in meinem Beispiel sehen kannst. In diesem Sinne hast du jedoch Recht, da "Wege bereits ab einem Wert von 9999 ausgeschlossen werden. Also 10000 und mehr.
Dann kann ich hier wohl nicht weiterhelfen und GUFSZ müsste wohl seine Wortwahl selbst erläutern.
Meiner Beobachtung nach zeigt iD auch nicht definierte Werte an, wenn sie in der aktuell bearbeitteten Region gebräuchlich sind. Bei mir z.B. wird grade6 nicht angezeigt. Da es innerhalb von OSM durchaus erlaubt ist, auch eigene Werte einzuführen, kann man schon eine gewisse Berechtigung darin sehen, dass OSM auch nicht definierte Werte aus dem Umgebung anbietet. Nur führt dass leider auch dazu, dass ein falsch eingetragener Wert anderen Mappern, die in der gleichen Ecke editieren, auch angeboten werden und diese denken fälschlich, es handele sich um einen offiziellen Wert.
Ich halte es für kaum möglich, diese Einflüsse sinnvoll zu kalkulieren. Es gibt dabei einfach zu viele Faktoren, die in OSM nicht erfasst werden. Natürlich ist die Beschaffenheit eines unbefestigten Wegs mehr vom Wetter abhängig als die eines befestigten Wegs. Aber es hängt auch davon ab, ob Regen von dem Weg gut abgeleitet wird oder auf ihm stehen bleibt. Oder bei einem unbefestigten Weg darauf, ob das das Material wasserdurchlässig ist. Ein Sandweg z.B. hat ganz andere Eigenschaftn als ein Lehmweg.
Am ehesten Rückschlüsse auf die Wetterabhängigkeit kann man meines Erachtens bei Feldwegen aus “tracktype” und aus “surface” ziehen, Allerdings sind Oberflächen wie “surface=earth” oder “surface=ground” sehr ungenau. Das kann klebriger Lehm oder durchlässiger Sand sein. Und wie sieht es unter der Oberfläche aus? Aus tracktype=5 kann man rückschließen, dass ein solcher Weg stärker durch Witterungseinflüsse beeinflusst ist als ein Weg mit tracktype=1. Will man also nach anhaltendem Regen mit dem Mountainbike nicht Gefahr laufen, im Schlamm zu versinken, sollte man Waldwege mit tracktype=5 meiden.
Meine Haltung daher: Es bräuchte für eine Auswertung der Wetterabhängigkeit des Zustandes oder der Befahrbarkeit von Wegen soviele zusätzlichen Informationen, die bislang in OSM nicht erfasst sind, zum anderen auch nur schwer vor Ort zu erkennen sind (man sieht ja bei einem Weg nur die Oberfläche. Wie es unter der obersten Schicht aussieht, kann man nicht sehen und daher auch nicht erfassen.Daher sollte man besser die Finger davon lassen, hier irgendetwas von der OSM-Datenbank zu erwarten, was diese gar nicht leisten kann.
Genau, der Router ist halt nur so schlau, wie man ihn programmiert hat und das geht meist nach Wegkosten, man könnte auch sagen: Der Rechnet für jedes Wegsegment einen Wert aus und versucht mit der geringsten Summe zum Ziel zu kommen. Beim Auto-Routing ist das recht einfach. Mit dem Auto ist es einem idR. egal ob man Wohnstraße oder Bundesstraße fährt, wenn auf beiden 50km/h erlaubt sind. Sprich die Kosten sind mehr oder weniger Zeit.
Auf dem Rad oder zu Fuß würde man aber viel lieber die Wohnstraße nutzen. Sprich man muss die Kosten manipulieren. Bspw. für 10m Bundesstraße zu vermeiden bist du bereit 100m Umweg über Wohnstraßen in kauf zu nehmen. Sprich die Bundesstraße ist 10mal “teuerer” als die Wohnstraße. Jetzt gibts aber nicht nur 2 Wegtypen sondern bestimmt >100 (mit all dem surface, smoothness, lanes,… und was man sonst so noch heranzieht). Im Resultat kann es dann dazu führen, dass du einen riesigen Umweg machst, nur weil du zwischen zwei Fußwegen 5m “entlang” einer Bundesstraße gehen musst. Einfach weil letztendlich die Bundesstraße 200mal teurer ist als er Fußweg. Sprich für den Router ist es besser 900m Umweg zu machen statt diese 5m Bundesstraße. Jeder normale Mensch denkt sich aber: Was sind schon 5m…
@Map_HeRo, das nicht, aber die Frage, ob Wege ausreichend detailliert getaggt sind, um eine kluge Routingentscheidung treffen zu können, ist trotzdem sowohl zulässig als auch sinnvoll und in dem Fall bin ich ebenfalls der Meinung, dass mit tracktype, surface und smoothness eigentlich schon eine ausreichende Menge an Informationen zur Verfügung gestellt werden kann, damit sich auch bei Nässe ordentliche Routingergebnisse erzeugen lassen.
Zumindest auf Android Geräten lässt OsmAnd beispielsweise in Kombination mit BRouter verwenden. Wenn man sich dann für unterschiedliche Wetterlagen unterschiedliche Routingprofile zurechtlegt, lässt sich das Problem durchaus in den Griff bekommen. Beispiele, wie man bestehende Profile entsprechend anpassen kann findest du in #41.
Da sind wir absolut derselben Meinung. Und zusätzlich gibt es auch noch den bisher relativ wenig genutzten Key “obstacle”, mit dem weitere lokal beschränkte Hindernisse eingetragen werden können. Mit einem entsprechenden Wert dafür könnte man z.B. auch so eine notorische nach jedem Regen auftretende temporäre Versumpfung eines kurzen Wegstückes kennzeichnen.
Da sind wir absolut derselben Meinung. Und zusätzlich gibt es auch noch den bisher relativ wenig genutzten Key “obstacle”, mit dem weitere lokal beschränkte Hindernisse eingetragen werden können. Mit einem entsprechenden Wert dafür könnte man z.B. auch so eine notorische nach jedem Regen auftretende temporäre Versumpfung eines kurzen Wegstückes kennzeichnen.