Falsches Tagging von Feldwegen mit access=no stört offroad routing

Hi!

In letzter Zeit sind mir auf meinen Touren vermehrt Feldwege aufgefallen, die mit access=no getaggt sind. Typischerweise in Kombination mit foot=yes, bicycle=yes oder noch krasser nur mit bicycle=yes oder ganz ohne Zugang.

Wenn ich an solche Stellen hinkomme handelt es sich immer um einen völlig normalen Feldweg. Weiter entfernte Stellen sehen auf dem Luftbild ebenfalls durchgängig nach unverdächtigen Feldwegen aus.

Das access=no spricht ein pauschales Verbot für alle nicht genannten Verkehrsteilnehmer aus (inline_skates=no, ski=no, horse=no, carriage=no etc.), das in Wirklichkeit nicht existiert, und macht ein vernünftiges Routing bzw. eine korrekte Kartierung an diesen Stellen unmöglich.

Es gibt in der Straßenverkehrsordnung keine solchen Kombinationen auf Feldwegen. Im Wiki sind die Werte unter access und bei den Verkehrszeichen eigentlich korrekt dargestellt, die Verwendung von access=no wird bei den Verkehrszeichen schon seit 2009 als veraltet bezeichnet.

Trotzdem stolpere ich nach meinem Gefühl immer häufiger über solche Stellen, die meist in den letzten 1-2 Jahren bearbeitet wurden. Eine schnelle Suche mit Overpass brachte 1820 falsche Kominationen aus track, access=no, bicycle=yes.

Daher die Fragen:

  1. Handelt es sich nach Eurer Erfahrung um ein aktuelles Fehltagging oder um Altlasten aus der Zeit vor 2009, die nur jetzt mehr auffallen weil es mehr Offroad-Routing gibt?

  2. gibt es irgendwo noch eine Anleitung, Wikiseite oder einen Editor, der diesen Fehler als korrektes Tagging vorschlägt? Ich habe z.B. die Einführung zu den access-Tags im Verdacht. Die Verwendung von access=no dort für path ist zwar korrekt, könnte aber evtl. leicht mißverstanden und fälschlicherweise auf track angewandt werden.

bye
Nop

Wieso macht es einen Unterschied (im Sinne von richtig oder falsch), ob access=no auf track statt path angewendet wird?

Ich habe (im Zuge der Offroad) auch schon einmal access=no an track/path verwendet (foot und bicyle yes - richtig wäre noch ski und horse yes), wenn diese durch ein Naturschutzgebiet gehen. Es gibt leider (immer mehr) Offroad- Motor-Bikes , -Quads, -… die durch Naturschutzgebiete (und auch über Felder und Wiesen) fahren. Das “nur Land- / Forstwirtschaft” ignoriert wird ist ja schon fast normal.

access=no sperrt Kraftfahrzeuge aus, die bei path defaultmäßig eh nicht erlaubt sind.

Am besten ist es die Beschilderung bestmöglich in OSM abzubilden, zB. Zeichen 250:
Weg ist für Fahrzeuge nicht erlaubt → vehicle=no.

Ist ski=yes überhaupt ein separater Verkehrsteilnehmer in der deutschen StVO? Ja, ich kenne die bayerischen Schilder, wo vor kreuzenden Skifahrern gewarnt wird, aber die fahren ja auf einer Skipiste und nicht auf der Straße (und vor allem nicht auf einer Straße, wo nur Skifahrer, aber keine Fußgänger rauf dürfen).

Es gibt zwar zum Thema access sehr viel Info im Wiki, für Anfänger fehlt aber trotzdem eine umfangreiche Best-Praktice Sammlung - oder habe ich sie nur noch nicht gefunden.
Würde es sich nicht als Wochen-Thema lohnen, mal all die missverständlichen oder sogar falschen access Tags zu kontrollieren und aufzuarbeiten?
Davor wäre es aber wichtig, all die falschen Kombinationen zusammenzustellen und auf einer Karte darzustellen.

Wenn OSM irgendwann einmal für Routing sinnvoll eingesetzt werden soll, dann wären korrekte access-Tags nicht unwichtig.
Ich bin sicher, dass immer noch mehr als 50% der tracks bezüglich access falsch (oder auch gar nicht) gekennzeichnet sind.

Walter

Stimmt, eigentlich ist es noch ein Stück mißverständlicher. :slight_smile:

Nach meinem Verständnis geht es dort um die Behandlung von path als Gemeinsamer Rad/Fußweg mit blauen Schildern - und dafür ist es korrekt.

Wenn man aber die andere Verwendung von path im Sinne von highway=trail (was sich nie durchgesetzt hat) meint, dann ist access=no genauso falsch wie bei track. Allerdings gibt es an einem trail/path kein Schild vergleichbar zu z250 an Feldwegen, das man fälschlicherweise mit access=no taggen könnte.

bye, Nop

Ich denke rechtlich ist ein Skifahrer einem Fußgänger gleichgestellt. Aber OSM macht beim Tagging grundsätzlich einen Unterschied, daher gilt ein access=no Tag im OSM Datenbestand für Skifahrer, wenn nichts anderes da steht.

Ich denke es ist auch in der Praxis relevant:

  • kann mir gut vorstellen, daß in Skigebieten zur Unfallvermeidung versucht wird, Fußgänger und Skier voneinander zu trennen. Denke ich habe sowas auch schon mal in der Nähe einer Liftstation gesehen.
  • Langlaufloipen werden hier in der Gegend häufig auf zugeschneiten Feldwegen gespurt - ein falsches access=no Tagging würde ein Skiverbot auf dem Feldweg signalisieren

bye, Nop

Wie gesagt, die Verkehrszeichenseite erscheint mir als ziemlich gut Best-Practice Zusammenstellung. Wenn sie gefunden und berücksichtigt wird.

Falls es tatsächlich Altlasten sind, würde ich auch an eine Aufräumaktion denken. 2000-3000 Stellen sollten machbar sein.

Falls aber immer noch frisch falsch getaggt wird müßte man erst mal rausfinden warum.

bye, Nop

Das ist aber egal solange es keine separaten Routingprogramme nur für Skifahrer gibt - und die gibt es nicht, weil ein Skifahrer genau das gleiche ist wie ein Fußgänger.

Es ist auch für Karten relevant. Wenn es getrennte Wege und Transferrouten für Fußgänger und Skifahrer rund um eine Liftstation gibt, würdest Du sie auch auf einer Karte des Skigebiets nicht/falsch darstellen.

Außerdem ist es für mich kein Argument, Fehler in der Datenbank nicht zu beheben, weil man keinen Router kennt, der bereits über den Fehler stolpert. Ich bin eher dafür, offensichtliche Fehler aus der Welt zu schaffen *bevor *sie zum Problem werden.

bye, Nop

IMHO liegt ein Grund für das falsche Tagging (das gleiche gilt noch viel mehr für access=destination) daran, dass im Standardstil nur access= gerendert wird und die eigentlich häufig vorkommenden effektiv beschilderten Varianten nicht (motor_vehicle=no/destination, motorcar=no/destination etc…).

Meiner Meinung nach wäre die Lösung Zugangsbeschränkungen gar nicht zu rendern am besten (da es im Augenblick ohne grossen Umbau so oder so nicht geht und rein kartographisch eh gräusilich wird).

Simon

Ich denke, der Fehler wird auch heute so gemacht und ich glaube nicht, dass irgendwas im Wiki daran schuld ist. Wer das Wiki liest, ist schonmal sensibilisiert für die Tatsache, dass es ungefähr 20 verschiedene Arten von Verkehrsteilnehmern gibt. Nur lesen das viele nicht und setzen “Durchfahrt verboten” mit “access=no” gleich. Zum Glück denken viele noch an die Fußgänger und die Radfahrer, leider ganz wenige an die Reiter.

Wir mappen ja nicht die StVO, sondern alles, was so als Verbotsschild in der Gegend rumsteht oder in Grünanlagensatzungen verboten ist. Deshalb gibt es auch Wege mit dog=no, obwohl der Hund in der Verkehrsordnung nur am Rande erwähnt wird (den darf ich mit Fahrrad Gassi führen (§28), meinen Hamster dagegen nicht).

Grüße, Max

+1

und wenn man sagt: “weil man keine Software kennt, …” +2

walter

Sämtliche Vorlagen – egal ob P2, iD oder JOSM – verleiten imo zu fehlerhaftem Access-Tagging. Deshalb habe ich das anfangs auch falsch gemacht.

OT: Danke für die gelegentliche Erwähnung des Reitverkehrs. Dadurch denke ich auch real häufiger dran :wink:

Ich hab mich mal in den Editoren umgesehen und meditiert wie Du das wohl meinst.

Bei P2 und ID wird jeweils als Erstes “Genereller Zugang” angeboten. Das suggeriert natürlich, daß man den verwenden sollte und wenn man sich dann nicht so genau auskennt mit den Tags klickt man bei einem Verbotsschild vermutlich leicht mal “keiner” an ohne zu ahnen wen man dabei alles aussperrt. Richtig?

Eigentlich wäre es sinnvoll, in den Vorlagen das allgemeine “access” ganz nach unten zu nehmen. Bei öffentlichen Verkehrswegen ist es immer sinnvoller, eines der Untertags zu verwenden wie motor_vehicle, also sollte man die auch zuerst finden. Die Pauschalregelung braucht es eigentlich nur bei Sperr- und Schutzgebieten oder Privatgrund.

Bei meiner eigenen P2 Instanz für Wanderer/Reiter gibt es das globale “access” in den Presets überhaupt nicht. :slight_smile:

bye, Nop

Richtig. Hinzu kommt, dass man für einige Situationen eh nicht mit den Vorlagen auskommt, es dann aber trotzdem versucht.

Das Problem fängt schon damit an, dass viele die Bedeutung der Zeichen nicht so genau kennen, weil es ihnen selbst egal ist…
Ein deutlicher Hinweis, dass man sich exakt an die Bedeutung der Zeichen halten und ggf nachschauen soll und sehr wahrscheinlich nicht alles ausfüllen braucht, wäre vielleicht auch hilfreich. Ansonsten verlagert man das Fehltagging nur zu anderem Fehltagging. Momentan ist’s wenigstens eingermassen detektierbar.

Für Deutschland würde ich sagen: Die Vorlage entfernen, auf das Verkehrszeichen-Tool verweisen und dieses z.B. um Conditional-Restrictions (z.B. Z262+Z1026-36) erweitern. (Btw: Wer ist dessen Maintainer? Das Ergebnis von Z242+Z1020-30 schliesst auch Fussgänger aus…)

Es gibt bei dem JOSM Access Preset (die auch von vespucci verwendet werden, allerdings in der Zwischenzeit geforkt https://github.com/simonpoole/beautified-JOSM-preset)) 2 Probleme: einerseits die Reihenfolge (das globale access steht zu oberst), aber wichtiger, dass suggeriert wird, dass man alles Zutreffende auswählen soll, was leider meistens Unsinn ergibt. Ich bin gerade am schauen ob das sinnvoll umgebaut werden kann um die tatsächlichen Verhältnisse wiederzugeben.

Fertig geschaut :-). IMHO ist die sinnvolle Art das für JOSM zu beheben, den Preset auf die häufig signaliserten Beschränkungen aufzuteilen. Ich komm vermutlich vor SOTM nicht dazu werde das aber für vespucci mal so machen.

Simon