Schutz- oder Schongebiete mit Betretungseinschränkungen

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

Hi Jo,

dann werde ich mal auf die Wikiseite für Nr3-Nr5 protection_title=Gebietsverbot setzen. Wenn uns noch was besseres einfällt, können wir es ja ändern. Ist ja erst mal nur Wiki :slight_smile:

Bei Nr2 werde ich protection_title=Projektschutzgebiet und in description das “Wald-Wild-Schongebiet” ins Wiki aufnehmen.

Grüße
Andreas

Hi,

@Sven
a) Zu protection_title=“Projektschutzgebiet”, wie wir es für Nr2 verwenden: Mit Nr8 habe ich einen ähnlichen Fall einer empfohlener Betretungsbeschränkung, bei der ich aber keinen Projektgedanken erkenne. Wäre evtl. für Nr2 und Nr8 etwas neutraleres, z.B. protection_title=“Meidungsgebiet” besser?

b) Ich habe in meinen Fallbeispielen bei Nr2 “Schutz- oder Schongebiet mit empfohlener Betretungsbeschränkung ohne rechtlicher Bindung und ohne konkreter zeitliche Angabe, aber saisonaler Absicht” die “saisonale Absicht” mit “seasonal=winter” getaggt, d.h. hier wäre noch die “empfohlener Betretungsbeschränkung ohne rechtlicher Bindung” eine Taggingherausforderung, für ich aktuell “access:advisory=no” vorschlagen würde.

c) Ich habe noch ein Fallbeispiel Nr8 “Schutz- oder Schongebiet mit empfohlener Betretungsbeschränkung ohne rechtlicher Bindung für einen bestimmten Zeitbereich” ergänzt und dieses ähnlich zu Nr2 getaggt.

Was meinst Du dazu?

@alle
d) Ein Mapper hat mich angeschrieben, dass aus meinen Wiki-Texten nicht eindeutig hervorgeht, ob ich die access-tags der Wege zusätzlich an den umgebene Schutzgebietsfläche taggen möchte und/oder nur die access-Tags der Flächen.

Ich möchte auf den Flächenpolygonen der Schutz- und Schongebiete nur taggen, ob das Betreten, Befahren usw. der Gebietsflächen verboten ist. Verbote oder Rechte auf den Wegen sollen weiterhin auf den Wegen getaggt werden. Ich hoffe, dass dies jetzt klarer rüberkommt und habe es im Wiki https://wiki.openstreetmap.org/wiki/DE:Betretungsverbote_für_Gebiete_im_Winter entsprechend ergänzt.

Grüße
Andreas

Edit: Schreibfehler korrigiert

Nun, ich würde beim Key “protection_title” auch das erwarten, was auf dem Schild steht. Welche Art es ist, wird doch schon mit protect_class ausgedrückt. Einen künstlichen Begriff hier einzuführen, finde ich nicht gut, das verwirrt den Nutzer.

Ein access an die Grenze zu setzen wäre in vielen Flächen sicher eindeutiger. Man muß dann aber beachten, daß an Wegen abweichende, weiterhin gültige access-Regeln bestehen können.

Sven

Hi Sven,

Ja, so dachte ich anfangs auch. Jo war in #29 und #39 eher dafür nicht die Bezeichnung vom Schild zu verwenden, sondern was allgemeineres. Das wäre auch OK für mich, aber vom Bauchgefühl her wäre ich eher bei dir mit protection_title vom Schild. Allerdings steht auch im Wiki zu protection_title “…Genutzt werden nur etablierte Termini…”, was wieder für Jo’s Ansicht steht.

Ich möchte hier in der Diskussion Wege noch komplett draußen lassen (noch deshalb, da sich dies nach Interessenlage auch ändern könnte). Ich sehe bei den access-Tags auf Flächen KEINE “Vererbung” auf die Wege. Ich möchte bei den Flächen mit access (oder was auch immer) taggen, ob das Betreten, Befahren, Paddeln usw. der Gebietsflächen verboten oder erlaubt ist.

Grüße
Andreas

Edit: Schreibfehler korrigiert

Naja, ich sehe das auch aus Sicht des Datenverarbeiters. Bei den Naturschutzgebieten steht im Idealfall z.B. protection_title=Naturschutzgebiet und short_protection_title=NSG

Damit ließe sich dann automatisiert die Gebietsbezeichnung mit Rechtszustand aus protection_title/short_protection_title und name generieren. recht einfach und recht schnell.

Bei der Verwendung von künstlichen Begriffen z.B. bei protect_class=14 muß man sich dann wieder Ausnahmen aushecken, ggf. dann auch für weitere protect_class-Werte, was ich aber nicht gut finden würde, weil es ein Namensrendering dann allgemein verkompliziert…

+1
eine kurze Angabe im Wiki und fertig.