Schutz- oder Schongebiete mit Betretungseinschränkungen

Hi Streckenkundler,

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?

Grüße
Andreas

Edit: Schreibfehler korrigiert

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.

Ein solches NSG im NSG ist z.B. Naturentwicklungsgebiet “Wasserburger Spreewald”
Umschließendes NSG ist Naturschutzgebiet “Innerer Unterspreewald”

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)

Hier mal meine Abfrage für Brandenburghttp://overpass-turbo.eu/s/Pb2

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.

So ist z.B. die Route https://routino.grade.de/index.html?transport=foot;lon1=13.88605000000035;lat1=52.02868000000022;lon2=13.86473;lat2=52.03901;lon3=13.85140;lat3=52.06194;lat=52.04985;lon=13.90265;zoom=13 möglich, auch wenn diese durch durch zwei protect_class=1 - Gebiete führt.

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.

Sven

Edit: H gegen G getauscht

Ach ja:

+1

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.

Sven

Hi Sven,

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

Hi Sven,

d.h. du fändest bei

  • Nr2 protect_class=14;

  • Nr3 protect_class=7; access:conditional=no @ (Dec - May)

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)

Edit: Schreibfehler korrigiert

Ja, würde ich so sehen.

Sven

Ach ich hab auch noch was:

Bodenbewegungs- und Bodensenkungsgebiete: Gesperrte Gebiete mit protect_class=16.

Das haben wir in der Lausitz oft… Beispiel: https://www.openstreetmap.org/way/584875543

boundary=protected_area
description=Sperrbereich ehem. Tagebau Seese Ost
hazard=caved_area
protect_class=16

Solche Gebiete sehe ich generell als access=no|private an, weshalb ich erst mal auf ein Taggen am Objekt verzichtet hatte.

Ausschilderung:

Bild kann, wenn gewollt, ins Wiki.

Sven

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

Hi Jo,

danke für die Taggingvorschläge!

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?

Grüße
Andreas

Hätte ich auch kein Problem. Das ist das, was ich mit:

meine… In gewisser Weise können protect_class=7 und 14 in meinen Augen ähnlich sein… In letzter Konsequenz bin mir aber noch nicht noch unsicher.

Sven

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?

Grüße
Andreas

@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.

und erstmal Gute Nacht
Jo

Hi Jo,

Du meist dann für Nr4:


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"

oder?

Grüße
Andreas

Edit: Schreibfehler korrigiert

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…

Sven

@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.

Grüße
Andreas

und im zugehörigen Flyer (s.u.) steht “Kerngebiet” :wink:
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.

Hi Jo,

Kein Problem, dann lasse ich name=* beim Nr4 weg (der Name von der Kernzone wurden nicht von mir getaggt :slight_smile: )

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:

  1. protection_title=Ruhezone (wäre damit allgemeiner und universeller einsetzbar)
  2. sie Vorschlag c)

Grüße
Andreas

Edit: Schreibfehler protection_tilte → protection_title korrigiert.

Den protection_title möchte ich keinesfalls weglassen
Zur Zeit (Beispiel 2-5 durchgearbeitet) ist mein Gedanke:

offizielle Verordnung (3-5) → “Betretungsverbot” ODER ein wasserfester, geeigneter Oberbegriff wie “Verbotsfläche” oder “Gebietsverbot”

“Projektschutzgebiet” (2) → “Wald-Wild-Schongebiet” ODER ein anderer (wasserfest) geeigneter Oberbegriff