Was ist mit https://wiki.openstreetmap.org/wiki/DE:Key:hazard ?
Ich würde hier auch eher Naturschutz- als Sicherheitsgründe sehen. Wenn ein Baum so liegt, dass man neben dem Weg bequemer (oder überhaupt) vorbei kommt, wird sich da ein einer Weg drum herum durchs Unterholz bilden. In einem städtischen Buchenwald stört und beeinträchtigt das den Wald nicht, bei einem Mittelgebirgsnationalpark könnte das anders sein.
Danke für den Tip, das ist bereits auf Leiterbene geschehen. Darauf habe ich allerdings keinen Einfluss.
Das ist genau das Problem! Es ist kein Buchenwald, sondern fast ausschließlich Fichtenwald. Nach 3 Jahren Dürre und immensem Borkenkäferbefall liegen die Bäume jetzt in dem ganzen Gebiet kreuz und quer, egal ob da ein Weg ist oder nicht. Jederzeit kann neues Totholz umfallen.
Klar wird es immer Leute geben, denen die Gefahr egal ist und die dort trotzdem langgehen wollen.
Mir geht beim Tagging darum zu kennzeichnen, dass der Wanderweg z.Z. nicht den üblichen “Standards” für den normalen Touristen, eine Familie, Nichtsortskundige etc. entspricht. Es wäre aus meiner Sicht unverantwortlich, es nicht zu kennzeichnen und Gäste, die nicht aus der Region stammen, “ins offene Messer” laufen zu lassen.
Aber ich denke, wir schweifen etwas vom ursprünglichen Thema ab.
Hallo,
bei Wegen die durch umgestürzte Bäume blockiert sind, sind meiner Meinung nach sowohl access=no als auch highway=construction + construction=path/track/… richtig, sofern die Sperrung mehr als nur ein paar Wochen anhält. Wenn die Wiederherstellung der Wege beabsichtigt ist, ist highway=construction besser, weil es die Information enthält, dass die Sperrung temporär ist und irgendwann wieder aufgehoben werden kann.
Allgemein kann man zum Mappen temporärer Veränderungen sagen, dass diese mindestens sechs Wochen bis sechs Monate Bestand haben sollten (das ist so in etwa das Spektrum, wo verschiedene Mapper ihre Grenze gesetzt haben). Wenn ein Gebiet gut gepflegt wird, kann man guten Gewissens eine sechswöchige Sperre eintragen. Da der Nationalpark danach schaut, dass seine Sperrungen in OSM erfasst sind, kann man von einem gut gepflegten Gebiet sprechen. Wenn Komoot nur alle zwei Monate seine Kartendaten aktualisiert, muss man sich halt fragen, ob die Firma seriös genug ist. Man kann auch öfter aktualisieren, wenn man gescheite Technik verwendet (das sage ich als einer, der die gescheite Technik kennt).
Die Darstellung in Karten ist irrelevant, solange das Tagging richtig ist. Wenn eine Karte highway=construction auch mit construction=path prominenter als highway=path darstellt, ist das ein Bug im Kartenstil. Deshalb nicht highway=construction zu verwenden, ist Tagging für den Renderer (also kein valides Argument).
Wenn sich die Dauer einer Sperrung nicht abschätzen lässt (z.B. technische Schwierigkeiten, Personal-/Geldmangel), der Nationalpark den Weg aber nicht dauerhaft sperren möchte, ist der Punkt erreicht, wo access=no genauso richtig ist wie highway=construction. Ein krasses Beispiel hierfür ist die L 154 im Kreis Waldshut, die aufgrund hoher Steinschlaggefahr seit 2015 gesperrt ist, aber reaktiviert werden soll. Seit 2018 gibt es dort die Zusage des Landes, die Wiedereröffnung zu finanzieren. Ich würde bei Wegen im Nationalpark sagen, dass access=no besser ist, wenn die Wiedereröffnung wiederholt nach hinten verschoben worden ist und man nicht mal mehr grobe Aussagen über die Wiedereröffnung treffen kann.
Ob Nationalparkbesucher Sperrungen missachten und sich in Gefahr begeben, ist das kein Grund weder access=no noch highway=construction zu taggen. Der Weg ist gesperrt, gegen Dummheit ist kein Kraut gewachsen. 
Bei allen Sperrungen ist es sinnvoll, in note=* oder description=* die Hintergründe zur Sperrung (z.B. Totholz, Brutgebiet, Kernzone, …) anzugeben, damit andere die Sperrung beurteilen können.
Viele Grüße
Michael
PS Für einzelne umgestürzte Bäume, die nicht mehr weggeräumt werden, gibt es barrier=log.
Hallo zusammen, zur Info, komoot updated sein Kartenmaterial wöchentlich. Normalerweise sind also alle Änderungen die man vornimmt binnen 10 Tagen auch auf der komoot Karte sichtbar. Dementsprechend kann man kurzzeitige Sperrungen auch darstellen. LG Betty
Ich möchte aus gegebenen Anlass diese Diskussion noch einmal aufgreifen.
Die Userin Nationalpark Sächsische Schweiz sucht nach einer Lösung, wie Wege gekennzeichnet werden können, die 1.) derzeit einer erhöhten Gefahrenlage ausgesetzt sind und/oder 2.) durch hunderte umgestürzte Bäume nahezu unpassierbar geworden sind.
Die aktuelle Situation auf der Karte (OSM deutscher Stil) stellt sich nun über 6 Wochen nach Diskussionsbeginn so dar, dass sehr viele Wege auf der Karte nicht mehr dargestellt werden. Das ist jedoch nicht das Ziel von OSM, denn diese Wege sind nicht gesperrt und vor Ort auf jeden Fall vorhanden.
Gutes Beispiel ist hierfür die Fahrstraße “Hohweg”, 3m breit in eigener Verantwortung problemlos begehbar, Schilder weisen auf Gefahren hin: nun wurde der Hohweg (von einem anderen Nutzer) als “unpassierbar” mit einer Straßensperre access=no highway=construction belegt: https://www.openstreetmap.org/way/23249855#map=17/50.91399/14.36933))
Sollte in dieser Weise weiter verfahren werden, sehe ich die Gefahr, dass wir in naher Zukunft keinen der markierten Wanderwege mehr in der Hinteren Sächsischen Schweiz auf den Karten sehen. Alle anderen Nebenwege, die in gleicher Weise betroffen sind, werden nämlich von den Mitarbeitern des Nationalparks nicht bearbeitet, verbleiben also in der Karte sichtbar und können so gerade die ortsunkundigen Besucher in die Irre führen. Sehr problematisch! Ich finde, dass dies auch unter dem Aspekt der Sicherheit vor Verirren oder bei einer nötigen Ortsangabe an die Rettungsleitstelle bei Unfällen relevant ist.
Besonders kritisch, da vor Ort auch Wanderwegschilder durch die Nationalparkverwaltung entfernt werden (sollen).
Karten sollen ja den Zustand vor Ort darstellen. Und wo ein Weg sichtbar vorhanden ist, sollte dieser eben auch auf seinem kartografischen Abbild vorhanden sein.
Ich bin der Meinung, es ist nicht Aufgabe von OSM, Wege für Kartennutzer unsichtbar zu machen, die körperlich vorhanden sind.
Insofern sehe ich im Tipp von OSM_RogerWilco >> https://wiki.openstreetmap.org/wiki/DE:Key:hazard eine sinnvolle Lösung, da der Zustand voraussichtlich einige Jahre anhalten wird.
Da offenbar auch weitere User in gleicher Weise wie die Userin “Nationalpark S.Schweiz” agieren, wäre hier vielleicht doch noch einmal ein zusammenfassender Hinweis von Seiten erfahrener Mitglieder nützlich, welche Tags die richtigen sind.
Und mal ganz nebenbei gefragt: Was passiert eigentlich mit den ganzen geänderten Daten, wenn Sachsenforst als Arbeitgeber die Stelle der Digitalbeauftragten wieder streicht bzw. diese endet? Wird das für den möglichen Stellennachfolger genau dokumentiert?
Hatte nicht Nakaner unter https://forum.openstreetmap.org/viewtopic.php?pid=819432#p819432 einmal alles schön zusammen gefasst und dabei auch treffend bemerkt
Die Wege sind also nicht gesperrt, sondern einfach nur temporär schwer zu gehen.
Ich würde dafür die sac_scale verwenden. Mit dem zusätzlichen Hinweis, dass die Schwierigkeit temporär und insbesondere in umgestürzten Bäumen besteht. Ich denke T3 und in Extremfällen T4 sollten passend sein.
Bei Einzelbäumen auf ansonsten guten Wegen kann ein wheelchair=no sicher auch nicht schaden.
Baustellen sind es nur wenn sie offiziell gesperrt sind um wiederhergerichtet zu werden.
… und das sind sie, so wie es die Nationalparkverwaltung verfügt!
… meint Uwe
Nun, dann sollte man die Renderrregeln des Kartenstils anpassen oder einfach eine Karte benutzen, die auch "construction’ auswertet.
Und je öfter nach dem hier vorgeschlagenen, logischen Verfahren getaggt wird, desto höher wird der Anreiz für die Kartenersteller, eine befriedigende Darstellung zu finden…
Userin Nationalpark agiert allerdings genau mit diesem Hintergrund: vorhandene Wege sollen nicht dargestellt werden, um Besucher nicht dorthin zu locken. Das ist nicht Ziel der OSM-Datenbank.
Ich denke access=no ist hier falsch eingesetzt, weil die betreffenden Wege per Nationalpark-Verordnung erlaubt sind. Vor Ort sind Gefahrenhinweise durch die Verwaltung angebracht. Wer den ** vor Ort sichtbaren** (auf den gängigen Navikarten jetzt nicht mehr sichtbaren) Weg hineinläuft, ist belehrt worauf er sich einlässt.
Echte Sperrungen (wegen Verkehrssicherungsmaßnahmen) gibt es derzeit lt. Nationalpark-Webseite nur an 5 Wegstücken, meist nur für einige Wochen.
Der constructions-tag kann doch auch ohne access=no gesetzt werden (obwohl die durch Totholzbruch verlegten Wege eigentlich auch nur im weitesten Sinne Baustellen sind, und zumeist nicht mal die gesamte Wegstrecke!)
Wäre das eine sinnige Lösung dieses Problems?
Es geht also nur um Hinweisschilder nach dem Prinzip “Viel stehendes Totholz: vorsichtig sein, vielleicht öfter mal nach oben gucken und bei Sturm unbedingt meiden”. (gibt es z.B. auch in Harz und Eifel)
Die Schilder haben ja keinerlei Verbindlichkeit und es gibt natürlich Waldwege in Deutschland die genauso gefährlich sind aber kein Schild.
Ich würde einfach description benutzen.
Und es gibt ja hazard=falling_rocks, warum dann nicht auch ein hazard=falling_trees an den Weg?
Das wäre doch auch eine gute Lösung für diese Wege…
wenn man sowas absichtlich macht (access=no anbringen obwohl man weiß, dass man dort rechtlich betreten darf), dann ist das im Prinzip Vandalismus, auch wenn man es aus gefühlt “guten Absichten” macht. Solche Art Nutzer kann man ggf. mit Verweis auf §303a, §303b StGB beeindrucken 
Bei dem Gummiparagraphen würde ich mir dann doch vorher mal den Kommentar und einschlägige Urteile anschauen, bevor ich so etwas zur Anzeige bringe. Ich sehe jetzt schon die NP-Verwaltung bibbern 
Hallo zusammen,
ich dachte mir schon, dass die Diskussion wieder aufkommt…nun gibt es schon mehrere Varianten und ich habe mich bewusst etwas zurückgehalten.
Danke für die vielen Eindrücke. Ich hoffe, ein paar Fragen klären zu können:
- Ja, die Wege sind nicht gesperrt, es wird “nur” eindringlich davon abgeraten, diese zu begehen, da man sich dadurch in (akute, konkrete…) Lebensgefahr begibt! Im Sinne von 0=erlaubt und 1=gesperrt wäre das für mich sowas wie 0,75.
Damit wäre “no” näher an der Realität als “yes”. Eine Karte bleibt eine Annäherung an die Realität…
Zum Schutz der Wanderer, die sich ausschließlich mit digitalen Karten navigieren, die quasi alle auf OSM basieren, habe ich das auf 1 aufgerundet. Sonst routen alle Portale weiter fleißig drüber und wenn es zu einem Unfall kommt, ist natürlich die Nationalparkverwaltung Schuld. Weder wollen wir, dass jemand zu Schaden kommt, noch dass sich ein Revierleiter wegen fahrlässiger Körperverletzung (oder -tötung) vor Gericht verantworten muss.
-“Userin Nationalpark agiert allerdings genau mit diesem Hintergrund: vorhandene Wege sollen nicht dargestellt werden,…”
→ dieser Unterstellung möchte ich widersprechen! Ich habe so getaggt, weil es mir so von anderen OSM-Usern empfohlen wurde (auch in diesem Blog). Mir war auch nicht klar, dass die Wege dann bei vielen Kartendiensten nicht mehr dargestellt werden.
- “Und mal ganz nebenbei gefragt: Was passiert eigentlich mit den ganzen geänderten Daten, wenn Sachsenforst als Arbeitgeber die Stelle der Digitalbeauftragten wieder streicht bzw. diese endet? Wird das für den möglichen Stellennachfolger genau dokumentiert?”
→ es wird versucht, die Stelle zu verlängern und/oder zu entfristen. Sollte das nicht klappen, kann ich ja hier Bescheid sagen
Mir liegt sehr viel daran, sich gemeinsam zu einigen, wie die unpassierbaren Wege getaggt sein sollten.
Ich finde das hazard=falling_tree gut, aber es ist nicht in der Attributliste enthalten. Manche Mapper haben auch bei name= “… unpassierbar” ergänzt - auch ok. Access=yes finde ich fahrlässig. Access=highly not recommended gibt es leider noch nicht.
Danke für das Verständnis und wenn mich doch jemand anzeigen möchte - schade.
Da bringst du mich auf eine Idee… foot=discouraged gibt es sehr wohl. Ist nicht dokumentiert und wird weltweit knapp 1.000 Mal gebraucht: https://taginfo.openstreetmap.org/tags/foot=discouraged
Dürfte aber eine Analogiebildung zum dokumentierten und (geringfügig) häufigeren hgv=discouraged darstellen: https://wiki.openstreetmap.org/wiki/Tag:hgv%3Ddiscouraged
foot=discouraged wäre also angezeigt, wenn eine Stelle, die auch ein Verbot aussprechen könnte, stattdessen ein Warnschild aufstellt. Das ist hier der Fall, oder?
Dazu geeignete hazard-Tags, und die Situation ist adäquat in der Datenbank abgebildet. Inwiefern Renderer und Router das auswerten, ist die nächste Frage, aber kein Problem, das wir hier lösen können oder sollten.
(Ich beschränke mich auf foot, weil ich davon ausgehe, dass die in Frage kommenden Wege für Reiter und Fahrzeuge inklusive Fahrrädern sowieso gesperrt sind. Ansonsten analog horse=discouraged, bicycle=discouraged oder gar access=discouraged, falls sogar Tanklastzüge rein dürfen aber nicht sollen)
PS, wichtig: *=discouraged ist natürlich nicht dafür da, um als Mapper auszudrücken, dass man einen Weg subjektiv gefährlich findet. Das wäre nicht verifizierbar. Wenn da ein Warnschild steht, das ist verifizierbar.
Ah, das klingt gut!
Die Stelle, die die Sperrung ausspricht, ist jeweils die Kommune. Die NLPV als Behörde beantragt diese. Bei den Wegen hier stellen wir als NLPV “nur” Warnschilder an den jeweiligen Wegen auf (werden aber öfter auch mal geklaut…).
Also existiert hazard=falling_tree bereits? ich habe danach gesucht, aber nicht gefunden.
“PS, wichtig: *=discouraged ist natürlich nicht dafür da, um als Mapper auszudrücken, dass man einen Weg subjektiv gefährlich findet. Das wäre nicht verifizierbar. Wenn da ein Warnschild steht, das ist verifizierbar.”
→ ok. Hier haben wir ja die Warnschilder, dann sollte das m.M. nach passen.
access regelt, was man darf, nicht was man sollte. Es gibt weder die Beschaffenheit noch die Eignung an. Wie bereits erwähnt gibt es dafür andere Tags.
Wie kommt ihr denn darauf? Soweit der Sicherungspflicht und Gefahrenabwehr vor Ort nachgekommen wurde, spielt es doch keine Rolle, was in irgendwelchen Karten steht, die nicht von euch herausgegeben wurden. Wenn der Weg so gefährlich ist, muss er deutlich gesperrt werden. Also Sperre und Schild davor. Und DANN ist es in OSM auch access=no.