Witterungsbedingtes Hindernis

Hallo,

Offenbar bewertet die Routing-Prüfung des OsmInspectors Furten als Hindernis für Fahrräder. Anders kann ich mir diese Meldung des OSMI nicht erklären. Ein Weg der an einem Ende nicht weiterführt, wird ab einer Furt bis zu dem toten Ende als Routinginsel für Fahrräder betrachtet. Das ist bei einer Furt sinnvoll, die zu tief ist oder zu viel Strömung hat, um mit dem Fahrrad durchzufahren, für einen Pkw aber kein Hindernis darstellt. Ich verstehe auch, dass ein Router das als Default für eine Furt ohne weitere Attribute nimmt.

Bei dieser Furt ist es aber wie bei den meisten Furten in der Gegend so, dass dort nur Wasser fließt, wenn es über längere Zeit sehr stark regnet. Das ist nur an wenigen Tagen im Jahr der Fall. Ich frage mich, wie ich diesen Zustand taggen kann, habe aber nichts gefunden. Wenn es nicht besseres gibt, dann hänge ich ein access=yes dran. So habe ich es bisher bei Schranken gemacht, die nur bei Hochwasser geschlossen werden.

Gruß
Rainer

https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=42.71172%2C2.77954%3B42.71492%2C2.78540#map=17/42.71331/2.78247
auch OSRM routet so.
Normalerweise müsste auch ein Pkw/Servicefahrzeug dort hin kommen - also access an den track.

OSMI zeigt etwas an, was man kontrollieren sollte.

Sorry, ich habe mich vielleicht nicht präzise ausgedrückt. OSMRI meldet das Wegstück hinter der Furt als Routing-Insel für Radfahrer. Eine Routing-Insel ist ein Weg, der für die betreffende Fahrzeugkategorie befahrbar, aber nicht erreichbar ist. Wenn ich an den Weg ein access=yes setze, dann ändert das nichts. Das Wegstück hinter der Furt bleibt eine Insel für Radfahrer, weil die dort zwar fahren dürfen, aber nicht hinkommen, weil die Furt davor ist. Anders ist es, wenn ich an die Furt ein access=yes setze.

Das ist aber nicht meine Frage. Es geht mir darum, wie ich access=“ja, außer wenn die Furt wegen Starkregen geflutet ist” oder access=“witterungsabhängig” taggen kann. Es gibt ja auch Straßen und Wege, an denen ein Schild steht “Bei Hochwasser gesperrt”.

Das mache ich ja gerade. Und dabei stellt sich mir eben diese Frage.

Das ist kein Taggingproblem, sonder eine Frage der interpretativ einer Furt.
Generell sollten Router eine Einstellungsmöglichkeit bieten, ob sie durch Furten Routen oder nicht.

Ich würde bei einem Standard Fahrradrouter, wenn nichts weiter angegeben ist, durch eine Furt an einem Track Routen (und wenn möglich mit einem Warnhinweis versehen).

Es ist ein Tagging-Problem. Es gibt Furten, die permanent unter Wasser stehen, solche bei denen das saisonal der Fall ist, und solche, bei denen das nur bei besonderen Witterungsbedingungen der Fall ist. Für den Nutzer und die Anwendungen, die er benutzt, macht das durchaus einen Unterschied.

https://wiki.openstreetmap.org/wiki/Key:flood_prone

Fehler oder Warnung oder Information

Es funktioniert doch:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=42.71172%2C2.77954%3B42.71492%2C2.78540#map=17/42.71332/2.78247

https://wiki.openstreetmap.org/wiki/DE:Key:seasonal
https://wiki.openstreetmap.org/wiki/DE:Key:intermittent
https://wiki.openstreetmap.org/wiki/Key:water

Das wäre wohl der richtige Ansatz, allerdings dann als Attribut am gekreuzten Wasserweg. Es geht ja nicht um eine verordnete Zugangsbeschränkung (access) sondern um den Zustand des Wasserlaufs (intermittent/seasonal). In dem von mir zitierten Beispiel wäre dann nichts zu tun, weil da schon intermittent=yes am Wasserlauf steht. Ich glaube allerdings kaum, dass das von einem Router unterstützt wird. Es würde dem Anwender auch nur etwas nützen, wenn es eine Option “Benutze Wasserwege mit intermittent/seasonal? ja/nein” gäbe.

Bleibt noch der Fall einer Schranke, die bei Hochwasser geschlossen wird. Das ist ähnlich dem Schutzgebiet, wo im Herbst Schilder “Betreten verboten” aufgestellt werden.

Hallo,

man kann bei GraphHopper einstellen, ob man Furten als Hindernisse betrachtet oder nicht. Ich kann die Einstellung ändern. Vielleicht sollte ich es sogar, weil es zu viele unnötige Meldungen gibt? Wenn ihr das meint, kann ich das nach dem Urlaub machen.

Viele Grüße

Michael

Moin,

Und was spricht dagegen, das auch an die Furt zu setzen, wenn es doch wesentlich für die Furt und deren Nutzer ist?
Klar kann man die Umsetzung dem Auswerter überlassen - aber man kann es ihm auch etwas vereinfachen (siehe auch Adressen).

Ja, das ist irgendwie so ein Natur-Gesetz fürs Tagging und Routing … und in Deiner Formulierung eher was für Wasserwanderer als die Furt-Nutzer. :wink:

Dann kann man es auch ähnlich taggen - die Schranke.
Edit: Was übrigens zur nächsten Router-Option führt - “Route mich bei Hochwasser”. :wink:

Grüße
Georg

Hallo Michael,

Das war nicht meine Intention. Toll wäre, wenn das intermittent- und seasonal-Tag des Wasserlaufs mit einfließen würde, d.h. Furten an Wasserläufen mit intermittent=yes und seasonal=yes nicht als Hindernis gewertet würden.

Grüße
Rainer

Beispiel dazu

Hallo Michael,

ein Nachtrag zu meinem vorherigen Beitrag:

Unnötig sind solche Hinweise nicht, aber für meine Begriffe ist die Sektion “Islands” des OSM Inspectors zu wenig differenziert. Ein Hinweis auf 200m Schotterpiste am Ende eines Stichwegs (mein Beispiel im UP) wird auf die gleiche Weise angezeigt wie ein asphaltierter Radschnellweg. Ähnlich ist es mit Parkplatzwegen, die nur über eine Schranke mit access=private erreicht werden können, selbst aber kein access-Tag tragen. Das deutet möglicherweise auf ein ernsthaftes Problem hin, aber in den allermeisten Fällen ist es kein Beinbruch, wenn das so stehen bleibt. Bei den Unconnected Roads ist das aus meiner Sicht mit den unterschiedlichen Prioritätsstufen sehr gut gelöst. Vielleicht kann man ja bei den Islands langfristig auch eine Einteilung in zwei oder drei Prioritätsstufen machen.

Danke für die Weihnachtskarten und frohes Fest wünscht
Rainer

Ich denke was Du eigentlich meinst ist, man müßte

  • die Verwendung von intermittent und seasonal Tags in so einem Fall diskutieren, sowas wie einen Konsens über eine sinnvolle Anwendung finden und dokumentieren
  • dann die einschlägigen Routingengines kontaktieren und ins Boot holen, daß es von ihnen auch in diesem Sinne ähnlich ausgewertet wird anstatt gar nicht oder von jeder anders interpretiert.

Dann würde da ein Schuh draus.