Das NSG im NSG ist so gemappt, da die Flächen vor Ort als NSG ausgeschildert sind. Gelbe Schilder, siehe oben, bei den inneren Flächen mit Betretungseinschränkungen und die typischen grünweißen Schilder an der äußeren Umrandung ohne Betretungsbeschränkung. Ich bin aber nicht fixiert darauf, dass diese inneren Flächen mit boundary=protected_area, protect_class=* getaggt werden, wäre halt nur an einer auswertbaren Möglichkeit interessiert die Betretungseinschränkungen in OSM festzuhalten.
Hast Du da eine Tagging-Idee für dieses Fallbeispiel?
Ich werde Fallbeispiel Nr3 auf “Teilbereich eines Schutz- oder Schongebiets mit Betretungsbeschränkung für einen bestimmten Zeitbereich” umbenennen, da Jo mehr am reelle OSM-Objekt interessiert ist, als es als fiktives Fallbeispiel anzusehen, was ja auch ok ist und werde ein anderes, geometrisch einfacheres, reelles Fallbeispiel für “Schutz- oder Schongebiets mit Beschränkung für einen bestimmten Zeitbereich” auf der Wikiseite hinzufügen.
Was meinst Du zu der Idee die Betretungsbeschränkungen eines Schutz- oder Schongebiets in OSM zu taggen?
Also vom Prinzip her ergibt sich für Gebiete mit protect_class=1 zunächst eigentlich auch der Sache heraus ein Betretungs- und Befahrverbot. Eine extra-Erfassung des access halte ich nur unter bestimmten Bedingungen für nötig… siehe unten.
In dem älteren NSG ist für bestimmte Wege ein Verbot ausgeschildert: https://www.openstreetmap.org/way/18460341 habe ich mal erfasst mit access:conditional=no @ (Mar 01-Jun 30)
Für den Spreewald gibt es aber den Sonderfall, daß schiffbare Landesgewässer trotz der Tatsache, daß diese durch Kernzonen und/oder Naturentwicklungsgebiete führen, per Paddelboot/ Kahn z.T. befahren werden dürfen. Das macht ein access-Tag am Objekt nötig.
Je genauer man sowas z.B. benennen kann, z.B. Weg oder Wasserweg, desto mehr würde ich ein Erfassen am Objekt (access / access:conditional) als gut erachten. Ist es hingehen rein eine Fläche wäre sie zunächst als “Sperrfläche” wie man sie für Routing verwendet, zu sehen, kann dafür verwendet werden. Habe ich z.B. eine solche Fläche und ein hindurchführender Wasserweg ein boat=yes mus Routing gewärleistet werden. Also Wege innerhab der Sperrflächen brauchen also einen access und/oder access:conditonal-Wert.
protect_class=14 würde ich auch für solche Schutz-/ Schongebiete als möglicherweise passende Alternative erachten. Hier sollte man sich das Gebiet und dessen rechtlichen Festlegungen aber immer im Detail anschauen, da es immer Übergänge/ Abhängigkeiten zwischen Schutzklassen möglich sind.
Ist von einem NSG nur eine Teilfläche von einem Betretungsverbot betroffen, würde ich diese entsprechende Teilfläche mit einer separaten Geometrie erfassen: evt. dann als protect_class=7 mit access:conditional. (Fallbeispiel 3) . Basiert ein Schutz-/ Schongebiet nicht von einem NSG/ LSG oder so, würde ich protect_class=14 in Erwägung ziehen.
Ja, bei Betretungsbeschränkungen für Radfahrer, Autos usw. (die nicht von Haus aus querfeldein fahren dürfen) oder Bootsfahrten auf Flüssen/Bächen/Waterways würden die Access-Tags an den Wegen oder Waterways ausreichen. Z.B. bei Skitouren, Geocaching, Fußgängern (bei Ländern, die das Querfeldein-Gehen erlauben) oder Bootsfahrten auf Seen bewegt man sich meist aber nicht auf Wegen oder Waterways (und in der Nähe gibt es dort häufig auch gar keine Wege oder Waterways) und für solche Fälle, denke ich, wäre das Taggen der Betretungsbeschränkungen auf den Gebieten/Flächen notwendig.
Grüße
Andreas
Edit: Schreibfehler korrigiert und “(wenn die von” auf “(die nicht von” korrigiert, da das “nicht” im Satz fehlte
besser? Wenn ja, würde ich das mal in die Fallbeispiele auf der Wikiseite aufnehmen.
Ich habe noch im Wiki als “Ersatz” die ursprünglich nur beispielhafte gemeinte Nr3 eine weitere Nr5 erstellte und weitere Geometetriedetails bei Nr3 ergänzt.
Grüße
Andreas (der um jeden Taggingvorschlag froh ist)
Um (erst)mal bei Beispiel 3 zu bleiben, habe ich das Tagging des NSG “Geigelstein” aktualisiert bzw. erstmals unseren NSG-Spzifikationen angepasst.
[hat keinen Einfluss auf das Rendering der Standardkarte und diese Diskussion, will aber vermeiden, dass sich dortiges veraltetes Tagging bei (Mit)Lesern festsetzt.] https://www.openstreetmap.org/relation/3574247
Für die Binnenflächen bei Beispiel 3 - offiziell ausgewiesene Betretungsverbots-Kernzonen eines umgebenden Schutzgebietes: https://www.openstreetmap.org/way/251790261
stelle ich mal diese Taggingidee in den Raum:
boundary=protected_area
protect_class=14
protection_title=Betretungsverbot
[…]
ob so ein Betretungsverbot ganzjährig oder saisonal ist wäre dann über weiteren Tag zu klären …
analog wäre dann bei Beispiel 2:
boundary=protected_area
protect_class=14
protection_title=Wald-Wild-Schongebiet [wobei in der DE-Spezifikation deratiges mapping nur für behördlich abgesegnete Projekte bzw. Sonderfälle ermöglicht wird]
protect_class=7 halte ich für keine gute, bzw. zu hohe Idee, gerade weil es pot. saisonale Einschränkungen sind, ist hier eine “abseitige, unsichtbare” class besser. Sonst würde bei Beispiel 3 auf der Standardkarte weiterhin eine saisonale Einschränkung wie eine ganzjährige Schutzgebietsgrenze dargestellt.
Hi Sven,
ich habe dein Bild als Fallbeispiel Nr6 ins Wiki aufgenommen und deine Vorschläge in Nr2 und Nr3 aufgenommen. Bei Nr3 hätte Jo eher zu protect_class=14 tendiert, so dass ich bei Nr3 protect_class=14 gesetzt habe.
Grüße
Andreas
Wäre für mich absolut OK und mein Anliegen so was zu taggen und für Karten auswertbar zu machen, würde auch klappen. Habe den Vorschlag mal auf die Wikiseite aufgenommen.
Auch das fände ich OK und habs in Wiki aufgenommen.
Wegen der saisonaler Einschränkung (saisonal finde ich hier gut und habs auch in die Fallbeispielbeschreibung aufgenommen “Schutz- oder Schongebiet mit empfohlener Betretungsbeschränkung ohne rechtlicher Bindung und ohne konkreter zeitliche Angabe, aber saisonaler Absicht”): Was meinst Du zu
access:advisory:conditional=no @ winter?
Hi Sven,
kann man sich da als Auswerter (Kartenhersteller, Router, …) 100%tig drauf verlassen, dass protection_class=1 gleich access=no bei der Fläche bedeutet oder gibt es in der Praxis auch protect_class=1-Gebiete, die auf der Fläche betreten werden dürfen?
@Andreas Binder
Inzwischen habe ich mir mal Beispiel 4 angeschaut (hatte mich von Tirol im Namen täuschen lassen)
So wie ich das sehe gibt es nur 1 NSG namens “Mündung der Tiroler Achen” und nicht 2 wie gegenwärtig in OSM erfasst. https://www.openstreetmap.org/way/249414307 https://www.openstreetmap.org/relation/3354261
Dieses NSG hat halt eine “Kernzone” mit Betretungsverbot. Aber “Kernzone” ist weder ein eigenständiges NSG, noch Namensbestandteil.
Insofern sollte dieses NSG unbedingt umgebaut werden, bevor es als Beispiel dienen kann.
Als “Fall” sehe ich das analog zum NSG “Geigelstein”, wobei das Betretungsverbot hier halt genzjährig statt saisonal ist.
@streckenkundler
Die protect_class=7 würde ich (weiterhin) für echte, autonome Gebiete reservieren, die protect_class=4 entsprechen aber offiziell halt nicht 4 sind, wie beispielsweise NDs.
access=no
area=yes
boundary=protected_area
protect_class=14
protection_title=Betretungsverbot
description=Ganzjähriges Betretungsverbot in der Kernzone des Naturschutzgebiets "Mündung der Tiroler Achen"
Ich finde diesen ganzen Beitragsbaum Toll. Er hilft, einzelne protect_class-Werte besser zu unterscheiden. Für mich ist z.B. die Unterscheidung und Definition von p_c=7 zu p_c=14 bisher noch nicht schön…
@Andreas Binder
Ja, als Tagging dieser (Teil)Fläche: https://www.openstreetmap.org/way/249414307
Gleichzeitig muss aber die eigentliche NSG-Fläche auf diese Fläche mit ausgedehnt werden (und deren Tagging sollte dabei auch aktualisiert werden, s. NSG “Geigelstein”).
@streckenkundler
naja, sehe da ganz pragmatisch die 14 eher als “Verfügungsmasse”, zumindest eher als die (wichtigere) 7. Rein theoretisch könnten wir hier auch “4711” für DE (Neu)definieren - aber wenn die 14 auch nur grob passt, dann scheint mir die doch wohl besser. Ohnehin ist für eine genaue/lokale Auswertung (im Sinne von “nicht europa- oder weltweit”) der protection_title besser geeignet.
protection_title wie “Wald-Wild-Schongebiet” und “Betretungsverbot” - sofern sie denn gewünscht zustande kommen - würde ich in https://wiki.openstreetmap.org/wiki/DE:Key:protection_title
übrigens als “projektinterne Kreationen für Sonderflächen” sichtbar von den “Gebieten nach Termini des Naturschutzrechts” absetzen…
Ja, die Vergrößung der NSG-Fläche ohne Betretungsverbot auf die Gesamtfläche, Taggingbereinigung und die Änderung der Fläche mit Betretungsverbot auf die, auf der Wikiseite https://wiki.openstreetmap.org/wiki/DE:Betretungsverbote_für_Gebiete_im_Winter#Beispiele vorgeschlagenen Tagging-Werte für Nr4 würde ich durchführen. Ich würde aber gerne erst im Wiki zu einem für jeden akzeptablen Tagging für die Beispiele kommen, bevor ich die OSM-Objekte damit tagge.
Könnte man bei Nr4 aus deiner Sicht name=“Mündung der Tiroler Achen Kernzone” dranlassen (Steht ja so auf den Schildern vor Ort)?
Nachdem sich das Fallbeispiel Nr4 auf “Teilbereich eines Schutz- oder Schongebiets mit Betretungsbeschränkung ohne zeitliche Begrenzung” geändert hat, habe ich ein neues Beispiel: Nr7 mit dem Fallbeispiel “Schutz- oder Schongebiet mit Beschränkung ohne zeitliche Begrenzung” ergänzt.
und im zugehörigen Flyer (s.u.) steht “Kerngebiet”
Bitte, bitte nicht, nicht am Chiemsee und auch nicht woanders - diese Kernzone ist namenlos, sie ist Teilfläche des NSG mit name-Tag. Dieser Zusammenhang kann, ja sollte im/in den description-Tag(s) erläutert werden (was Du ja auch machst).
Habe zu Beispiel 5 dieses recherchiert: https://www.chiemseeagenda.de/uploads/infomaterial/download/15/RuZo-2014-4b.pdf
Offensichtlich sind diese “Ruhezonen” (außerhalb umgebender Schutzgebiete) am Chiemsee per Verordnung geschützte Gebiete, die - was das “Betretungsverbot” anbelangt - durchaus mit der Kernzone des NSG gleichgesetzt werden. Daher würde ich das analog zum Beispiel 3 und Beispiel 4 sehen. “Betretungsverbot” mag für Wasserflächen absurd sein, vielleicht ist ganz übergreifend “Verbotsfläche” besser.
Aber mit protection_title=Ruhezone für Vögel und Fische habe ich grundsätzliche Bauchschmerzen.
Wir sollten nicht für jede vor-Ort-Ausschilderungsformulierung einen eigenen protection_title anlegen (im description-Tag sind derartige Hintergründe dagegen hochgradig sinnvoll), sondern ein nutzbares System in die Sache bringen.
Kein Problem, dann lasse ich name=* beim Nr4 weg (der Name von der Kernzone wurden nicht von mir getaggt )
Vorschläge:
a) Gebietsverbot oder Verbotszone
b) Bei Nr2, Nr3, Nr4 protection_title komplett weglassen
c) Bei Nr2, Nr3, Nr4, Nr5 und Nr7 protection_title komplett weglassen
Vorschläge:
protection_title=Ruhezone (wäre damit allgemeiner und universeller einsetzbar)