mapy.cz schickt dafür Fußgänger über den Umweg.
komoot greift beim zweiten Beispiel ebenfalls ins Klo.
Ersteres ist tatsächlich irritierend, die Laufstrecke fällt mMn. noch unter Geschmackssache. Etliche Läufer bevorzugen mehr Natur als Asphaltwege zw. Radfahrern, da zähle ich mich auch dazu.
hier kann auch wieder nur Brouter empfehlen… dort kann man auch an die Routing Einstellungen ran und z.B. Asphaltwege abwerten… bzw. die kosten erhöhen. Aber ist nicht so ganz einfach 
Schon nur fehlt mir der Glaube, dass das der tatsächliche Grund für den Umweg ist. Insbesondere wenn ich mir ansehe, dass auch hier ein Umweg gewählt wird: https://www.komoot.de/plan/tour/d11AvCHgwCPEGY=GMYABN7bqQA=/@49.3188332,9.3767843,16.944z, welcher definitiv grober Unsinn ist.
Noch mal, es geht mir nicht darum, dass es Router gibt, die zum Teil durch bescheißen (übervorteilen von ausgewiesenen Radrouten) zu einem richtigen Ergebnis kommen, sondern darum, die Rohdaten auf ein Qualitätsniveau zu heben, welches korrektes Routing ohne Tricks ermöglicht.
Ich verwende komoot öfter zum Planen von Routen und das Laufprofil hat die Tendenz Asphalt zu meiden. Es ist in dieser Hinsicht nicht immer sinnvoll, aber meistens erklärbar. Ich hatte allerdings auch schon manchmal völlig schwachsinnige Rennrad-Routings erhalten, ohne erkennbaren Grund (dürfte besser geworden sein) und auch das Mapping auf Wegtypen/-beschaffenheit ist manchmal ein wenig dubios und ändert sich tlw. sogar je nach gewählter Sportart für die gleichen Abschnitte.
korrekt ist in Bezug auf Freizeitaktivitäten nicht so einfach für alle User und alle Szenarien unter einen Hut zu bekommen, nicht ohne Grund bieten die meisten auch mehrere Fahrrad-Profile an, was du für “Straßenlauf” / “Trailrunning” noch nicht so vordefiniert bekommst. Mit einem brouter-Profil kannst du halt leichter nachvollziehen, warum es in einer Situation zu diesem Routing gekommen ist
Ok, dann liegt vermutlich zumindest teilweise an ungenügenden Rohdaten, denn der Feldwegabschnitt, der mit tracktype=grade2 eingetragen ist, dürfte in Wirklichkeit fast vollständig aus Asphalt bestehen (werde ich korrigieren, wenn ich am Wochenende das nächste Mal dort gewesen bin) und die Fabrikstraße ist wohl auch keine Anliegerstraße, sondern eher eine Durchgangsstraße (highway=unclassified?).
Mit “korrekt” meinte ich im Sinne des Erschaffers des jeweiligen Routenplaners.
Für mich hat die Disskussion mittlerweile einen versteckten Unterton, daß das Tagging doch bitteschön den Routing-Programmen angepasst werden solle und nicht der realen Situation vor Ort… 
Sven
@streckenkundler, dass ich genau das nicht anstrebe, habe ich bereits klargestellt:
Es geht mittlerweile eher darum, ein Bewusstsein dafür zu schaffen, welche Auswirkungen unvollständige bzw. falsche Rohdaten auf die Routenplaner haben können.
Tatsache ist aber so das der highway-Key path/footway/cycleway mehr oder weniger wertlos geworden ist… für den Router… Carto liefert auch eher was unnützes…
Und aus deinem Unterton höre ich raus dass du eine schöne Datenbank haben möchtest, viele wollen aber was brauchbares… Ich sag einmal wenn Router und Renderer nicht mehr mit dem Daten gute Routen/Karten man können dann ist was an dem System der Erfassung falsch.
Nein! Es wurden diverse Dinge aufgezeigt, wo und an welchen stellen es haken kann (nicht muß!)… Siehe: #2
Wie einzelne Router ein solches barrier ohne ergänzende access-Tags auswerten, müsste der interessierte Anwender in den Routing-Algorithmen nachsehen. Bei einem barrier=bollard ohne weiters access-Tags, könnte man Fußgänger noch durchlassen, bei Fahrrad könnte es durchaus Probleme geben, oder ein Router sperrt barrier=bollard ohne weitere acess-Tags.
Ja und wenn Access-Tags gesetzt sind…
Dann kommt es sowieso vor allem auf den jeweiligen Datenstand beim Router an… Das kann mitunter schon mal sein, daß geänderte Daten erst nach 1-2 Wochen oder gar erst nach einem Monat aktualisiert werden… BRouter aktualisiert glaube ich täglich, graphHopper meiner Meinung nach wöchentlich… CycleTravel das letzte mal 7.12.2021: https://cycle.travel/map/info. Bei den anderen weiß ich es nicht…
Eine weiteres Frage ist, ob Routing-Programme alle gängigen Highway-Tags auswerten oder nach Maßgabe des Routing-Programierers nur die aus seiner Sicht wichtigten…
…mir fallen noch mehr Fragen ein…
…Dann werden hier vielleicht Dinge als Problem dargestellt, die vielleicht keine mehr sind, der Router aber die neuen Daten noch nicht hat, somit ein anderes Ergebnis ausgibt, als das, welches mit den korrigierten Daten herauskommen würde…
Das hat hier nicht mit einer “schönen Datenbank” zu tun, das sind einfach Dinge, die man im Kopf haben muß, wenn man Routing-Fragen disskutiert.
Sven
barrier=bollard impliziert access=no, foot=yes und bicycle=yes. Wenn ein Routenplaner damit nicht zurechtkommt, dann ist er voll selbst schuld.
Auch klar und nicht Thema hier.
Ja, und umso wichtiger ist es, dass wenigstens die Haupttags stimmen.
Dann war es aber ein Problem, was durch die Korrektur der Daten behoben wurde, also genau das, worum es in diesem Thread geht.
Weißt du das, ob die von dir getesteten Router das auch beachten? Ich weiß es nicht. Ich schaue bei diesen Gitub-Geschichten wie ein Schwein ins Uhrwerk. Meine Erfahrung ist, daß es nicht schadet, access trotzdem zu setzen.
Das ist aber das wichtigste! Wenn du mir einem Router testet, der eventuell noch gar nicht die jünsten Daten hat kommt nicht unbedingt ein korrektes Ergebnis bei raus…
Im übrigen wäre bei mir https://www.openstreetmap.org/way/27095466#map=19/49.32151/9.36424 highway=footway + foot=designated + bicycle=yes, siehe https://www.mapillary.com/app/?pKey=305988157758755 und http://osmtools.de/traffic_signs/?signs=239,1022-10 wenn die Beschilderung noch aktuell ist.
…was dann die Routing-Situation wiederum ändern könnte.
Sven
Ja, das lässt sich via Black-Box-Test relativ einfach herausfinden.
Das bedeutet, dass nur barrier=yes, barrier=wall und barrier=fence dazu führen, dass die Route als für Fahrradfahrer als blockiert gilt.
Dem Routenplaner eher nicht. Dem Menschen, der mit unnötigen Informationen erschlagen wird, schon eher und spätestens bei so Sachen wie impliziten Geschwindigkeitsbeschränkungen wird es dann zum Gau, wenn sich die Gesetze mal ändern.
Die Änderungen habe ich ja erst vorgenommen, nachdem ich via Router festgestellt hatte, dass etwas im Argen liegt und ich hab es auch nicht so weit getrieben, dass der Router das anzeigt, was ich gerne hätte, sondern soweit wie es der Realität entspricht und Sinn macht.
Danke für den Hinweis! Der Abschnitt war ursprünglich als Fußweg erfasst und vor 5 Jahren wurde dann ein Fuß- und Radweg daraus gemacht. Der Wahrheit entsprach es wohl noch nie.
Der Streckenabschnitt ist nicht relevant für die beiden Beispiele, die ich gebracht habe.
Das gilt für OSRM… und die anderen?
Ich habe im weiteren Verlauf keine weiteren anderen Schilder gesehen, daher würde ich aus der Ferne annehmen, daß sich das bis zum Bahnhof Möckmühl nicht ändert, den fraglichen Abschnitt hätte ich persönlich dann auch entsprechend erfasst. Ob es dann doch relevant werden würde, weß ich nicht, ich kanns mir schon vorstellen.
Sven
Die anderen fahren an der Stelle alle keinen Umweg und ignorieren die Barrieren folglich.
Ein paar Meter weiter kommt VZ 240: https://www.mapillary.com/app/?pKey=1046640092531803&lat=49.321212212875&lng=9.3637312613746&z=17&focus=photo
Dann tritt für mich das in Kraft, unterschiedliche Datenaktualitäten der Routing-Daten (??), meiner Erinnerung nach waren die access-Werte gesetzt… Ich kann jetzt nicht nachsehen, ich schreibe vom Tablett und sitze noch im Zug, da Unfall am Bahnübergang brauche mindestens ne Stunde länger… ich hab heute deswegen keine Lust mehr.
Sven
Die Poller sind beide 5 Jahre alt und hatten noch nie irgendeinen access Tag:
- https://www.openstreetmap.org/node/4749055966/history
-
https://www.openstreetmap.org/node/4749055967/history
Ich diskutier wirklich gerne, aber die Pollergeschichte ist durch.
Da bin ich absolut bei Dir und die Rohdaten stehen und fallen natürlich mit der Qualität des Taggings. Wenn alle relevanten und im Wiki dokumentierten Tags für einen Rad/Fußweg korrekt gesetzt sind, einschließlich surface/smoothness und ggf. barrier, dann sollte ein Routingprogramm das fehlerfrei auswerten können. Dabei dürfte es dann auch keine Rolle spielen, ob ein Weg mit den Subtags
bicycle=designated + foot=designated + segregated=yes/no
dem Haupttag “footway” oder “cycleway” oder “path” beigeordnet ist
da die expliziten Subtags den Haupttag eigentlich überflüssig machen (wie Luzandro bereits zuvor korrekt festgestellt hat).
Wenn die Tags aber unvollständig oder auch schlicht verkehrt sind (und das sind sie an vielen Stellen), kann man die Routingprogramme kaum verantwortlich für auf den ersten Blick unverständliche Routenvorschläge machen.
Im Hinblick auf das Routing-Dilemma ergibt sich m.E. daher die Frage: wie muss ein Rad/Fußweg korrekt und vollständig getaggt sein, damit eine sinnvolle und fehlerfreie Auswertung durch Routingprogramme möglich ist?
Zumindest im Fall von OSRM ist das ja nachweislich nicht der Fall, was ursprünglich Stein des Anstoßes für diesen Thread war.
Nein, aber man kann sie verwenden, um die Fehler aufzuspüren.
Ein korrekt und vollständig getaggter Fuß- und Radweg allein genügt dafür nicht. Auch alle alternativen Routen müssen korrekt und möglichst vollständig getaggt sein.