Es gibt meines Wissens kein deutsches Verkehrsschild, das ein access=forestry/agricultural allein zur Folge hat.
Selbst ein DE:250 mit DE:1026-36/37/38 verbietet nur Fahrzeugverkehr, aber nicht Fußgänger.
Denkbar sind nur Schilder mit “Benutzung verboten außer für …”. Die habe ich aber bisher nur mit “Anlieger” gesehen.
Nun könnte man sich auf den Standpunkt stellen, dann ist foot=yes bei agricultural/forestry eben Voreinstellung und muss nicht angegeben werden.
Zur Klarstellung und weil die rechtliche Lage außerhalb DE anders sein kann, würde ich aber trotzdem ein foot=yes setzen.
Da ist die Wahrscheinlichkeit hoch, dass da ein unerfahrener Mapper das falsche Wort gewählt hat, vielleicht auch, weil es in der Nachbarschaft schon mal vorkam. Das spricht dafür, hier hiking durch foot zu ersetzen.
Es kann aber auch sein, dass sich der Mapper etwas dabei gedacht hat (was auch immer). Um das nicht rückstandlos in der Historie versinken zu lassen, würde ich das in ein note verschieben. Da ist es für einen Mapper immer noch sichtbar, stört aber keinen Anwender.
Ein Fußgängerrouter könnte zwar hiking als alias für foot interpretieren, aber solche vermeidbare Redundanzen sollte man unterlassen. Sie blähen nur die Tagging-Schemata unnötig auf, so man sie dokumentiert, undokumentierte Tags sollte man sowieso nicht verwenden.
Das würde aber die Logik (über die doch hoffentlich Konsens besteht) durchbrechen, dass mit acces=* generell die Benutzung für ein bestimmte Nutzergruppe zugelassen wird und damit alle nicht extra angegebenen Gruppen mit allen Fortbewegungsart/Verkehrsmitteln ausgeschlossen sind. Wenn es hier unterschiedliche Interpretationsmöchlckeit gäbe, sollte man alle acces=*- tags in die Tonne stopfen.
Router bzw. Hersteller routingfähiger Karten sollten sich darauf beschränken können, dokumentierte Tags nach einheitlichen Regeln auszuwerten, ohne Ratespiele zu veranstalten zu müssen, was ein Mapper mit einem frei erfunden tag gemeint haben könnte. Es ist Aufgabe der Mapper, sich auf einheitliche und widerspruchsfreie Regeln zu einigen und nach bestem Wissen und Gewissen anzuwenden.
Was kann denn hiking=yes aussagen? Dass ich hier zwar wandern darf, aber nicht spazieren gehen, bummeln, nordic walken oder joggen? Ich kenne das nur so, ich darf einen Weg zu Fuß benutzen oder nicht, egal in welcher Gangart.
Ich bin der Auffassung, es ist einem Mapper, der frei erfunden tags verwendet, diesen ohne Konsultation in eine Wert zu ändern, die den mutmaßlich beabsichtigten Zweck einschließt, die venünftigerweise anzunehmenden anderen erlaubten Zwecke aber nicht ausschließt.
z.B. das der Weg Teil eines Wanderweges /-netzes ist… Diese Art und Weise des taggings scheint im Wesentlichen ein “alpines” Problem zu sein… Außerhalb der Alpen ist nach der Overpass-Abfrage nichts… Ich hätte fast gefragt, ob das durch eine fehlerhaftes Tool entstanden ist, aber es gibt Einträge mind. ab 2010 bis 2015…
?! Wäre das dann wohl genau der umgekehrte Fall zum dem aktuellen Thema bzgl. Sammelrelation? Weil ich es also nicht schaffe eine Wanderrelation mit ihren Membern abzufragen klatsche ich an alle Wege ein hiking=yes … das wäre dann echt der Abschuß … geomehr wo bist du
Ich habe dazu jetzt einfach mal einen User angeschrieben, der für mich stichprobenartig sehr häufig dieses Tagging genutzt hat. Ma gucken ob er sich meldet.
Immerhin sind über 2000 Wege betroffen, aber immerhin begrenzt. Das und das Vorhandensein von hiking=yes ein Grund, dass isch mich vorerst auf diese Konstellation beschränkt habe.
Wenns jemande interessiert, meine Theorie zur Entstehung: Der Ersterfasser dieser Weg war sich der Problematik der ausschließenden Wirkung von access=* wonöglich bewusst und wollte das aus seinem vorrangigen Interesse fürs Wandern heraus mit dem naheliegenden key hiking heilen, ohne zu recherchieren, ob dieser key dokumentiert ist, oder weitergehende Auswirkungen zu bedenken. Nachfolgende Mapper habe das einfach unbedacht aus der Vorgängerversion übernommen oder aus der Umgebung abgeschrieben.
Aber ganz gleich aus welchem Grund falsches oder mißverständliches Tagging entsteht: Wenn man soche Fehler einfach stehen läßt, besteht die Gefahr, dass die sich vermehren indem andere es sich zum Beispiel nehmen. Wenn dann noch neue Tagging-Schemata hinzukommen, die bestehenden widersprechen, wird die Datenbasis von OSM immer ungeeigneter für sinnvolle Anwendugen. Also der umgekehrte Prozeß einer Evolution, die eigentlich in Richtung eines optimalen Zustands streben sollte.
es gibt noch so was seltsames bei relationen. die sind manchmal als type=hiking, sport oder foot gemappt. hiking kann ich eigentlich nur mit “foot” also weg mit dem schmarrn = hiking.
foot isz ausreiched für hiking, walking ode nordic walking. ich kenn keinen der sowas mit anderen körperteilen macht.
was es mit “sport” auf sich hate verstehe ich sowieso nicht. kugelstossen, swimming im wald oder was?
Ein User, der in 856 von 2110 abgefragten Wegen als Autor erscheint, ist anscheinden schon mal durch eigenwilliges Mapping aufgefallen und seit ca. 4 Jahren nicht mehr aktiv. Stichprobenartige Überprüfung benachbarter Wege anderer Autoren zeigt den gleichen User als ursprünglichen Autor.
ich will keinen vertreiben. nur mir als läufer ist es eigentlich egal ob ich da “spaziere”, “walker”, “stöckchenzieh” oder mit einem 4er schnitt auf wanderwegen unterwegs bin. alles mache ich mit “foot”.
ausser langlauf mit ski, aber das mache ich eh nicht. im ernst als route=foot würde ich die unterteilung in ein anderes tag packen.
Bei BRouter wäre ich garnicht auf die Idee gekommen, bei access=agricultural die Radfahrer auszuschliessen, obwohl es in der dokumentierten Logik der access-rules natürlich so ist, aber das merkt man ja ganz schnell, dass das nicht geht und lässt es dann bleiben. access=no|private sperren aus, alles andere nicht, auch kein destination oder delivery. Es ist also durchaus so, dass sich Router an die Praxis anpassen, weil sie sonst nicht funktionieren würden.
Ein anderer Aspekt sind die redundanten access-tags. Ja, bicycle=yes ist in aller Regel überflüssig aus Sicht der access-rules, aber um Himmels willen nicht grossflächig entfernen diese Dinger. Da steckt Information drin, nämlich ein positiver Hinweis, dass man da Fahrrad fahren kann, nicht im formalen, sondern im praktischen Sinne. Diese Information ist wertvoll und wird von Routern ausgewertet. Kann man stundenlang drüber streiten, ob das ein gutes Konzept ist, ist es natürlich nicht, aber es ist grossflächig implementiert und nicht so leicht durch ein anderes Konzept zu ersetzen.
Das ist eine subjektive Bewertung, die nicht belegbar ist. Die Passagen im WIKI dazu:
Verstehe ich das richtig:
Um vernünftige Ergebnisse zu erzielen, muss man die Taggingregeln ignoriern? In meinen Augen könnte man der Mappingpraxis in OSM kaum ein größeres Armutszeugnis ausstellen.
Schönes Beispiel sind z.B. die default-access-Tags bei Barrieren. Standardmäßig gilt access=no.
“Vergisst” der Mapper nun foot=yes und bicycle=yes an barrier=cattle_grid, kommt ein regelkonformer
Router hier schon ins Schleudern und lässt keine Fußgänger und Radler durch.
Naja, hier ist es grober Unsinn, für jegliche Art von Barriere denselben Defaultwert annehmen zu wollen. Wenn das tatsächlich irgendwo im Wiki steht, ist das extrem zu kurz gedacht und bedürfte einer Verbesserung.
Sinnvollerweise wird zuerst der Typ der Barriere ausgewertet (in diesem Fall wäre das dann access=yes, horse=no) und dann die explizit gesetzten Tags.
