hw=path impliziert horse=yes?

Würden wir jetzt per Definition bei (highway=path) reiten erlauben - ganz unabhäng von gesetzlichen Regelungen usw. - wäre das eine Katastrophe, denn dann müßte an tausende Pfade ein horse=no hingepappt werden.
… und das betrifft dann auch alle Wege mit highway=path, foot=designated und bicycle=designated.

In stark reglementieren Ländern sehe ich keine alternative zu einem implizieren horse=no bei highway=path.
Wenn mir persönlich Reiter/Pferd begegnen sind zu 99% auf Wegen vom Typ highway=track…
PS: Hier in Düsseldorf, am Stadtrand wurden hunderte spezieller Reitwege angelegt. Sieht aus wie highway=path, ist aber ausdrücklich ein Reitweg (highway=briddleway).

Wie gesagt, daß ist total bundeslandabhängig. In einigen Bundesländern darf sich auf highway=track kein Reiter erwischen lassen, weil das Reiten nur auf Straßen und ausgewiesenen Reitwegen erlaubt ist. In Bayern z.B. ist das Reiten auf jedem geeigneten Weg erlaubt, der nicht ausdrücklich verboten ist. Dafür gibt es außerhalb der Städte fast keine ausgewiesenen Reitwege. Und nach meiner Erfahrung ist auf ca. 20% der mit *=designated getaggten Wege das Reiten faktisch erlaubt, weil da eben kein blaues Schild steht.

Wie wertest Du hw=path für die Reit- und Wanderkarte aus, um festzustellen, ob das Reiten erlaubt ist?

Wegen der chaotischen Taggingsituation ziemlich kompliziert:

ohne Tags => yes
horse=no/private => no (Anzeige durchgestrichen)
access=no, foot=yes oder bicycle=yes => yes (access=no Tagging ist praktisch immer falsch/unvollständig)
foot=official/bicycle=official => no (Anzeige als blaues Schild auf der Karte)
foot=designated/bicycle=designated => yes, mit Routing-Aufschlag (Anzeige als graue Version des Schildes, weil unsicher)

Außerdem spielen noch rein
markierter Wanderweg => je nach Routingeinstellungen
sac_scale
horse_scale

Die allgemeine Gesetzeslage des jeweiligen Bundeslandes muß der Nutzer selber kennen, das versuche ich erst gar nicht zu implementieren.

traffic_sign wäre noch eine Möglichkeit.

Habe ich bisher nicht so gerne an Wege getaggt, aber inzwischen denke ich, dass es wohl sinnvoll ist. Daraus kann man dann die access-Werte ableiten.

Was denkt ihr?

Dann aber bitte das VZ (auch) als node im way, damit man es eventuell überprüfen kann.
Wenn es nur an am Anfang oder am Ende des Weges steht forward oder backward angeben.

Einfach nur eintragen, was für ein VZ es sein könnte, bringt nichts. Man sollte schon vor Ort sein, statt nur von designated auf ein blaues Schild zu schließen und auch das **:=use_sidepath an der Straße nicht vergessen.

für mich sind traffic signs Punkte, deren Gültigkeit für Wege ist z.T. unklar je weiter man sich davon entfernt, weil gerade außerorts die Beschilderung unterschiedlich sein kann, je nachdem von wo man kommt.

Davon war nie die Rede.

Dieses Argument gilt dann aber auch für die von dem VZ abgeleiteten access-tags wie foot/bicycle=yes/desgnated etc. Demnach dürfte man außer das VZ als node keine access-tags an den way taggen.

Dem Router sollte man das ableiten der accesses nicht aufbürden, dazu ist auch die Verfügbarkeit der traffic_sign-tags zu gering bisher. Es hilft nix: Wir müssen schon selbst die accesses nach vor-Ort-Wissen bestmöglich interpretieren wegen der vielen Tücken.

Sowieso. Schon zur Doku.

Das gehört m.E. stets an wegverbundene traffic_signs

Einen schönen Fall als Argument dafür, dass alles seine zwei Seiten hat, habe ich ja eben im Faden zur unechten Einbahnstr. geschildert … Da geht’s auch um einen Radweg

… oder optional_sidepath, muss ich auch vermehrt dran denken …

Eben!
… aber auch innerorts, s. mein Bsp. in “unechte Einbahnstr.”

Manchmal wird’s knifflig, ja …
Zumindest das erste Wegstück bis zum nächsten Knoten könnte man mit *:x-ward korrekt taggen, wenn dort ein 250 ff. ohne 267 steht, damit wäre die Einfahrt für alle Router korrekt reguliert. Wenn der Router von ganz woanderster einen anderen unbeschilderten Weg dorthin findet … Tja … Sellerie … Äh… C’est la vie …

Es wäre eine Katastrophe, wenn wir es per Definition verbieten. Reiten ist auf Pfaden per Definition erlaubt, wie auch international eindeutig in den Wikis zu lesen ist. ein Defaultwert hebelt ja auch nicht die geltenden Verordnungen aus. Ja heisst ja nur: “wie in der allgemeinen Verordnung niedergelegt”.

Wenn Du es jetzt plötzlich verbieten willst, musst Du so gut wie alle Pfade in ganz Skandinavien, fast ganz Afrika, ganz Russland, ganz Tibet… umtaggen.

Da wäre es wesentlich Arbeitssparender, alle cykel- und footways aus der Datenbank zu entfernen, durch ein sinnvolles Konstrukt mit path und passendem Accessway zu ersetzen - und die vorhandenen Pfade in trails und Mehrzweckwege aufzuteilen.

bei Verkehrsschildern auf Wegen geht die Richtung verloren (ausser man taggt die Kardinalrichtungen), sich an der Richtung von anderen Objekten (also z.B. des Weges) zu orientieren ist auch nicht intuitiv und darüber hinaus wenig stabil. Ich bin für Schilder an ihrer Position, also nicht in der Straßenmitte. Ggf. dazuhin noch die Ausrichtung des Schilds.

OK, ok, okay…
Meine Fresse ist das ein sch… :open_mouth:
In D jetzt überall ein horse=no hin zu pappen ist halt auch keine Lösung…

Am einfachsten für die Ursprungsfrage wäre wohl, wenn
*=designated
als “NUR für diese Verkehrsart angelegt” intepretieren würde.
Ausnahmen davon wären dann zu taggen.

Der gemeine Geh- und/oder Radweg, entweder beschildert oder fahrbahnbegleitend, bräuchte dann keine weiteren tags außer außerorts oder bei entsprechender Beschilderung ein mofa=yes.
Oder bei nur foot=designated wäre bicycle=yes für “Gehweg, Schleichradler frei”

Dann wären nur die designated-paths anzuschauen, die sowohl nicht fahrbahnbegleitend, also eigenständig, verlaufen, als auch ohne blaues Vz beschildert sind, da könnte ein horse=yes/designated/… nachzutragen sein.

paths, die keine designated-tags haben, dürften wohl nur unbeschilderte Wege sein, da kann man dann, je nach Bundesland, ein horse=yes annehmen bzw. die horse-Frage wäre mit weiteren tags klärungsbedürftig

Nein, mit forward/backward ist die Richtung hinreichend definiert *)

Also ich finde das sehr intuitiv.
Wenn oneway dranhängt, erkennt man die Richtung des Weges (bei iD jedenfalls) sofort, ohne braucht’s auch nicht viel Grips, um die Richtung zu erkennen, dann muss man weder die Windrose vorm inneren Auge bemühen oder Vielfache und Bruchteile von 90° überlegen und sich auch nicht fragen, ob es nun die Schauseite des Schildes ist oder die Wirkrichtung.

Stabil dürfte es, wenn es nicht am Wegende hängt, auch bei allen wesentlichen Editoren.

Gibt es überhaupt noch Editoren, die bei Umdrehen des Weges *ward- und left/right-Angaben etc. nicht korrigieren? Welchen Anteil haben diese und wie oft werden mit diesne Wege umgedreht?

“Ggf.”? Ohne wäre es doch völlig wertlos …

Also ich bleibe bei wegverbundenen traffic_sign-Knoten und in Ausnahmefällen an Wege gehängte, aber einzelstehende hale ich weiterhin für ziemlich sinnlos, da nicht zweifelsfrei erkennbar, worauf sich das bezieht.

Wie hieß der Herr, dessen Name mit A anfing?
Ich wollte ja noch fragen, ob es was für quer zum Weg stehende Schilder gibt, So wie hier, nur weiter drinnen direkt am Radweg stehend

forward und backward auf ways ist vollkommen in Ordnung, es sind diese tags auf nodes die stinken. Nodes haben keine Richtung, daher kann man sie auch nicht umdrehen, aber sie können Teil von 0 bis unendlich vielen ways sein. Sollen die Editoren die way-Richtung umdrehen wenn man sie mit einem node verbindet der Richtungsangaben hat? Oder ist das dann vielleicht komplett verboten? Das wird ggf. ziemlich kompliziert. Sich mit node tags von way-Richtungen abhängig zu machen, dass sollten wir verbannen.

Das sind schon immerhin 33000 nodes die solche tags haben: https://taginfo.openstreetmap.org/keys/traffic_sign%3Aforward
wenn das Schule macht, Verkehrsschilder gibt es schließlich reichlich, ist es bald ein undurchsichtiges Abhängigkeitschaos

Du selbst taggst an Knoten aber auch Richtungen:

Ohne (Aus)Richtung des Schildes ist es völlig witzlos, Verkehrszeichen zu mappen, denn nur Vz, die man von vorme sieht, sind für Verkehrsteilnehmer relevant.
Ob die (Aus)Richtung eines Schildes nun in absoluten Zahlen, Himmelsrichtungen oder relativ zum vom Vz betroffenen Weg definiert wurden, ist doch gehupft wie gesprungen, nur dass letzteres die mit Abstand am einfachsten auszuwertende Variante ist. Kein Suchen von Vz in der Umgebung, wenn sie nicht am Weg sind, kein Raten, welcher Winkel des Schildes zum Winkel des Weges passen könnte, was besonders bei Radwegverschwenkungen an Kreuzungen knifflig werden könnte, etc., einfach nur schauen, ob die Schildrichtung zum eigenen Fortbewegungsrichtung passt.

Es fehlt noch die Antwort auf

Vz auf Wegenden könnten ein Problem sein, müssen es aber nicht.
Bei Radwegschildern, um die geht’s hier, sollte es eher nicht vorkommen, da das Schild idR 'n Meter oder mehr nach dem physischen Radweganfang steht.
Tempolimits könnte es eher treffen, da der Weg wegen der aneren maxspeed-Angabe eigentlich genau dort geteilt werden sollte, sofern man nicht auch wie bei den Radwegen, an Kreuzungen davon ausgehen kann, dass sie 'n Meter nach Anfang des betroffenen Weges stehen und man das maxspeed daher bis zur topologischen Kreuzung durchzieht, wie in OSM idR üblich. Nur “irgendwo unterwegs” wird das Problem relevant. Da muss man sich dann immer noch die Frage stellen, wieso man einen Weg umdrehen sollte, den nachfolgenden aber nicht, also vermutlich wenig Praxisrelevanz.

Davon abgesehen könnte man in die Editoren Warnungen einbauen.
iD hat da noch Nachholbedarf nach einem kleinen Test eben, es dreht den Anfangsknoten brav mit, warnt aber nicht.
Und man könnte Qualitätssicherungstools bauen, wenn es sie nicht schon gibt(?), die

  • bereits existierende Widersprüche aufdecken, also forward-, backward-, left-, right-Angaben auf Knoten an Wegenden,
    — die Teil zweier Wege sind, deren Ausrichtung entgegengesetzt sind
    — die Teil mehrerer Wege sind, womit die Angaben generell undefiniert sein könnten (aber nicht müssen)
  • generell vor solchen Knoten warnen

Kann man anders sehen: Schön, dass sich dieses an sich vernünftige System durchzusetzen scheint :wink:

ich mappe Verkehrszeichen nur für Mapper (dh eigentlich nur maxspeed, maxheight und mwidth und city_limit), nicht in der Hoffnung, dass Anwendungen sie auswerten, für Anwendungen verlasse ich mich auf die standardisierten tags. Da sich auf der Höhe von Verkehrsschildern die Eigenschaften eines Weges ändern, dürfte es eher die Regel sein, als die Ausnahme, dass mehrere ways damit verbunden sind. Bei 3 und mehr ways durch einen Knoten ist es überhaupt unklar, was forward oder both bedeuten soll (das ist aber zugegebenermaßen vermutlich eher selten).
Als mapper ist es viel bequemer, das Zeichen am Rand zu haben und auch ohne die tags anzusehen bereits die Richtung erkennen zu können.
Ob Editoren beim Umdrehen von ways auch die tags der nodes ändern weiß ich nicht, alle machen das sicherlich nicht, und ich würde auch nicht von mappern erwarten, dass sie beim invertieren eines ways alle tags auf allen Nodes auch noch abgrasen.

Hm, was soll es denn sonst sein?

Designated heißt doch gewidmet. Und was für einen Sinn macht das Tag, wenn es nicht das bedeutet, was Du schreibst?

Wenn ich das richtig verstanden habe, gibt es auch die Auffassung, dass z.B. bicycle=designated für alle Arten von Radwegen gedacht sind. Nicht nur die, die mit einem Verkehrszeichen 237, 240 oder 241 ausgeschildert sind.