Ich vermute, dass es nicht so einfach wäre, Attribute, die an einer Fläche (Naturschutzgebiet-Area) etaggt sind, auf Wege zu beziehen, zumal die Wege die Flächengrenzen in der Regel ohne gemeinsamen Punkt schneiden. Konsens nach ausgiebiger Diskussion war ja auch, dass Wegebeschränkungen an die Wege getaggt werden. Das muss halt nur umgesetzt werden.
Ja, würde ich auch so sehen. Flächen sind fürs Kartenbild und Router, die über Flächen routen (für den Fall, dass es so was mal gibt) und die access-Tags an den Wegen sind für die “normalen” Router. Die Flächen können außerdem für die Mapper hilfreiche Grenzen sein, wenn man die access-Tags an die Wege setzt.
Ich wüsste auch nicht, wie man z.B. einigermaßen fehlerfrei folgendes Wegegebot umsetzen wollte: “Betreten des NSG erlaubt, aber nur auf befestigten oder markierten Wegen.” Das steht hier in meiner Gegend sinngemäß auf den Schildern am Rande eines NSG. Was sollte dafür Komoot auswerten? Surface und Tracktype - welche Surface-Werte und welche Tractype-Werte gelten in welcher Kombination als befestigter Weg? und Zugehörigkeit zu einer Wandwerwegrelation? Was aber, wenn ein Weg zwar nicht zu einer Wanderwegrelation gehört, aber an dem Weg ein Richtungswegweiser für Wanderer steht wie “zum Aussichtsturm”?
Ich habe in dem NSG alle Wege entsprechend mit acces-tags versehen. Man braucht schon Ortskunde, um entscheiden zu können, ob es sich um einen erlaubten oder um einen nicht erlaubten Weg handelt.
Insofern gehören an die Fläche des Naturschutzgebiets alle Werte, die sich allgemein auf die Fläche beziehen und zusätzlich an alle Wege innerhalb des Gebiets die sich konkret auf die Wege beziehenden Werte. Das wir ja auch bei militärischen Sperrgebieten schon seit Langem so gehandhabt. Da erwartet auch niemand, dass beim Straßenrouting ausgewertet wird, ob sich der Weg innerhalb der Sperrgebietsfläche oder außerhalb befindet. Das wäre auch bei manchen militärischen Sperrgebieten schwierig. Im Sperrgebiet Senne bei mir um die Ecke gibt es Straßen, die im Sperrgebiet liegen aber ganzjährig für allgemeinen Verkehr freigegeben sind und es gibt Straßen, die an manchen Tagen freigegeben werden. Wie sollte man über die Fläche das abbilden? Werte an der Sperrgebietsfläche können nicht zwischen verschiedenen Straßen im Sperrgebiet unterscheiden.
Ja, das war immer der Ansatz bei der Erstellung des Schemas, die Flächen bzw. deren Grenzen definieren den Wirkungsbereich, daher auch
“Daraus können sich access-Tags für die Wege im Gebiet ableiten: siehe access der Wege.” in
https://wiki.openstreetmap.org/wiki/DE:Key:protection_title#Sonderflächen
Am Rande: hier eine Overpass Abfrage die die solche Weg-Kandidaten anzeigt falls das mal jemand braucht (map_to_area hab ich eben erst kennengelernt): http://overpass-turbo.eu/s/11ZG
Wäre cool, wenn die Wege, die bereits access oder access:condition-Tags haben, nicht oder andersfarbig dargestellt werden.
http://overpass-turbo.eu/s/120q
Aber irgendwas stimmt an dem query noch nicht, bei der Nicklheimer Filzn erscheinen auch Wege die in einer protected_area ohne protect_class liegen - obwohl der erste Teil-Block des Queries diese Areas nicht liefert?! Bin kein Overpass-QL Spezialist und das wird jetzt off-topic…
Du meinst wohl diese Fläche
https://www.openstreetmap.org/way/781577067
Habe mit dem map_to_area keine Erfahrung, Aber protection_title=Wegempfehlung ist für deine Fragestellung doch eh irrelevant, weil kein Einfluss auf die Wege vorliegt.
Das Schema ist doch genauer granuliert, und sofern die Flächen korrekt erfasst und getaggt sind, sind auch genauere Abfragen möglich als nur nach protect_class=14
Beispiel: deine 1. Abfrage, aber reduziert auf veordnete Gebietsverbote
Per style werden dann die Wege-Tags ausgewertet:
http://overpass-turbo.eu/s/122K
Ist klasse, dass du die einträgst. Würde mich freuen, wenn Du es auch mit den restlichen machst.
In den OpenAndroMaps-Karten werden die Schutzgebiete nun ab Jan.2021 aufgenommen (soweit in OSM enthalten). Siehe
https://www.openandromaps.org/map-basics-2/tag-mapping
Mit dem Standard-Theme “Elevate” (habe gerade mal da reingesehen) werden diese dann (zusammengefasst) in Oruxmaps und Locus angezeigt:
1, 2-4, 5+11, 24
Wer sich sein Theme selbst anpasst, kann sich das bei Interesse dann auch detaillierter darstellen lassen.
Es ist mit Mapsforge allerdings nicht möglich, den “(short_)protection_title” anzuzeigen, nur den “name”.
Beide Werte zu kombinieren und dann im “name” auszugeben, geht auch nicht.
Man kann (da es hier ja abgelehnt wird, die Schutzklasse im Namen zu nennen) die Schutzklasse insoweit nur an unterschiedlicher grafischer/farblicher Darstellung des Gebiets erkennen.
NSG sind bei mir z.B. rot, LSG grün.
Kurzer Update: Ich hatte heute Kontakt zum Gebietsbetreuer Mangfallgebirge am LRA Miesbach und u.a. die Frage gestellt:
“Wie ist die Regelung bzgl. Wege und Forst-Straßen in diesen Schutz und Schon Gebieten? Sind diese dann immer auch vom Betretungs-Ver/Gebot betroffen?”
die Antwort war ein uneingeschränktes ja.
Das mag jetzt vielleicht Gebiets-spezifisch sein, die Klarstellung im Wiki / Die access-Tags auf den boundary=protected_area-Flächen haben KEINE “Vererbung” auf die Wege! ist damit aber m.E. etwas in Frage gestellt.
Technisch gesehen könnte man basierend auf der Aussage die entsprechenden way Tags generieren, konzeptionell stellt sich die Frage nach Daten-Redundanz und aktuell bleibt der nicht unerhebliche (stupide) Zusatz-Aufwand für’s manuelle Erfassen an den Ways in 233 derartigen Gebieten am Bayerischen Alpenrand…
Was damit OSM-Datentechnisch geneint ist, steht doch im folgenden Satz: “Wege sollen, wie bisher, ihre eigenen access-Tags haben.”
Die Flächen definieren den räumlichen Wirkungsbereich einer Betretungseinschränkung - diese selbst kann aber (derzeit/praktisch) nur über die jeweils betroffenen Weg-Segmente im Gebiet umgesetzt bzw. händisch getaggt werden … ist halt (leider) so.
Dass eine Lösung nur über die Flächen eleganter und von der Erfassung her viel einfacher wäre, dies war und ist allen Beteiligten klar;-)
Schon klar. Für eine redundanz-freie, nur Flächen-bezogene Lösung müssten das ja auch Renderer und Router berücksichtigen, was kaum realistisch ist.
Aber konzeptionell “erben” mit der Aussage ways in solchen Gebieten durchaus. Dass das aus technischen/etc. Gründen manuell gelöst werden muss steht auf einem anderen Blatt.
Mich persönlich nerven unnötige/wiederholende manuelle Aufgaben, da setz ich mich lieber 1 Stunde länger hin und programmier mir was, da lerne ich vielleicht noch was nebenher (wobei ich noch nie ein JOSM plugin geschrieben habe)
Und diese Muster “area impliziert tags an enthaltenen ways” könnte möglicherweise auch in ganz anderen Bereichen auftreten und eine semi-automatisierte Lösung (mit manueller Kontrolle des Ergebnisses) hilfreich sein.
Ganz so einfach ist das mit dem “Vererben” nicht, es gibt innerhalb verbotener Gebiete ja oft doch erlaubte Wege. Und sei es die Kreisstraße, die dort durchführt. Natürlich kann man dann Rückausnahmen drantaggen, aber so was bringt nicht 100% sauber programmierte Router ins Schleudern.
Nochmal, der für die Gebiete zuständige Gebietsbetreuer sagt, dass die Wege-Ge- und Verbote für alle Wege in diesen Gebieten gelten. Das sind 233 Gebiete mit entsprechend vielen Wegen. Dass das bei anderen Gebieten anders sein kann steht außer Frage, da wäre dann eben dann eine manuelle Nachkontrolle nötig um ein paar tags zu löschen - aber egal ich werd mir für mein “Problem” eine Lösung überlegen. Mir ging es nur darum das Feedback anhand eines größeren Beispiels hier zu teilen.
… die wohl in einer Kombi aus Overpass nach JOSM laden, filtern und select all ohne nodes raus laufen wird. Man lernt nie aus 
Ich habe jetzt ab und zu ein NSG nach dem neuen Schema in meiner Gegend angepasst. Hierbei sind mir folgende Dinge aufgefallen:
1.) Die NSG haben ein TAG “status=complete”, da sie nach dem damaligen Stand wahrscheinlich fertig erfasst waren. Tag Löschen?
2.) Alle NSG hier im Kreis sind in einer Sammelrelation vom Typ network zusammengefasst. Ich hatte aufgeschnappt, dass Sammelrelationen in OSM nicht erwünscht sind und Typ network passt anscheinend gar nicht, oder? Sollte man die Relation löschen?
- keine Ahnung, was status=complete bringen oder aussagen könnte
- NSGs können durchaus kreisübergreifend sein, insofern sind derartige Zusammenfassungen auf Kreisebene sinnfrei (genauso wie der eben gesehene operator=[Landkreis]-Tag)
Sowas
https://www.openstreetmap.org/way/296339180
ist übrigens Unfug - Relationen sind bei NSGs nur angebracht, wenn diese aus mehreren Teilflächen bestehen (oder innere Enklaven ohne Schutzstatus bestehen)
Noch ne Kleinigkeit, die mir aufgefallen ist, ich nehme in Hessen (und daher auch in der Vorlage NSG “Dönche”)
source:shape
weil diese NSG-Geometrie tatsächlich einer Shape-Datei entstammt, ansonsten würde ich eher
source:geometry empfehlen, oder aber die Erfassungsart und Genauigkeit stattdessen im note-Tag erwähnen.
[Das ganze ist hier übrigens nicht so gut aufgehoben, wenn Du am Thema drannbleiben willst, mach doch was Neues auf “NSG-Überarbeitung in Niedersachsen” oder so…]
In den letzten Wochen habe ich an einer “Referenz-Karte” für die Schongebiete gebastelt. Das Resultat findet Ihr hier: https://www.xctrails.org/schongebiete/SchongebieteWMSLayer.html - diese Karte ist nicht geografisch eingeschränkt und sollte alle gemappten protect_class=14 Gebiete beinhalten.
Ein paar Worte zum technischen Hintergrund: Ausgangspunkt ist ein overpass query für boundary=protected_area + protect_class=14, auf dem Ergebnis läuft ein Python-Script in das ich die Queries aus dem Wiki praktisch 1:1 übertragen konnte. Mithilfe dieser Queries erzeuge ich ein geojson File mit expliziter Klassifizierung. D.h. die Weiterverarbeitung sollte damit erleichter sein, bzw. die Abfrage-Logik ist damit vom Styling getrennt. Zukünftige Änderungen an den Queries sollten sich dann auch einfach im zugrunde liegenden Jupyter Notebook testen lassen.
Die Exports werden nächtlich aktualisiert und liegen hier: https://www.xctrails.org/osm/
Ein Beispiel für die Verwendung des Schongebiete.geojson Files ist der geoserver den ich für die Karte verwende: Der lädt sich das geojson in eine PostGIS DB, wendet dann nur noch das Styling aus dem Wiki an und liefert das Ergebnis als WMS.
Um ein Eindruck für den “Zustand” der Wege in diesen Schutzgebieten zu bekommen, gibt es noch einen zweiten Layer der Wege mit access:conditional tags grün und ohne rot rendert.
Prinzipiell lassen sich diese WMS Layer natürlich auch auf anderen Karten verwenden, ob das mein Server packt müsste ich im Einzefall entscheiden und entsprechend CORS-technisch freischalten.
Für Feedback, Bugs etc. gibt’s ggf. auch den Issue Tracker auf dem von der Karte verlinkten github repo.
Hi Arminus,
wow, danke für die tolle Kartenumsetzung/WMS-Dienst!
a) Zu https://www.xctrails.org/schongebiete/SchongebieteWMSLayer.html:
Könnte man dort in der Legende evtl. verdeutlichen, dass die Schongebietsdarstellung (aufgrund der verwendeten Daten-Queries) für Skitourengeher gedacht sind? Für andere Fortbewegungsarten Fuß, Rad, … könnte man auch so eine Schongebietsdarstellung machen, aber dann sind die Daten-Queries natürlich etwas anzupassen.
b) Zu https://www.xctrails.org/osm/ (z.B. https://www.xctrails.org/osm/Schongebiete-Alpenrand-BY.html)):
Könnte man den angezeigten Bereich bis zum Bodensee rüber erweitern?
Grüße
Andreas
Da hat sich ja einiges getan in Südbayern,
kann das nur aus der Ferne beurteilen und habe diese Auswertung (nach unserer Sonderflächen-Spezifikation) auprobiert:
http://overpass-turbo.eu/s/13tt
Sieht für mich sauber aus,
aber bei diesen beiden Flächen kann etwas nicht stimmen:
https://www.openstreetmap.org/way/903002665 - access=no geht nicht bei protection_title=Schongebiet
https://www.openstreetmap.org/way/301937424 - “Wildschutzgebiet” ist kein protection_title