Schutz- oder Schongebiete mit Betretungseinschränkungen

openandromaps.org rendert schon “gefühlt ewig” boundary=protected_area, kann nicht sagen welche classes insgesamt, aber meine neuangelegten Schutzgebiete finden sich immer “ohne Tricks und Nachhilfe” auf der nächten Karte.

Meine Gedanken zum Wiki sind sind zentrale Informationen auch zentral zugänglich zu machen.
Deine Wiki-Seite beschäftigt sich mit protect_class=14, ist also vom Carto-Bug weit entfernt bis unberührt.

Daher in
https://wiki.openstreetmap.org/wiki/DE:Schutzgebiete_des_Natur-_und_Landschaftsschutzes
der zentralen (Redirect-)Schutzgebiets-Anlaufstelle, vgl.
https://wiki.openstreetmap.org/wiki/Special:WhatLinksHere/DE:Schutzgebiete_des_Natur-_und_Landschaftsschutzes
(Habe nur “Multipolygon” durch “Relation” ersetzt, denn bei boundary=protected_area ist type=boundary, nicht multipolygon)

Das könnte auch als “Hinweis” noch einführend in (den “internationalen Teil”, ist ja kein .de-Problem)
https://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area
wenn Bedarf besteht, den Carto-Bug quasi zur OSM-Spezifikation zu adeln?

Gruß Jo

Solange und sofern eine Schutzgebietsgrenze protect_class=1|4 und in einer type=boundary-Relation steckt, müsste openstreetmap.org das rendern.
ist das NSG eine Simple Fläche und hat zusätzlich leisure=nature_reserve wird das Gebiet gerendert, ohne leisure=nature_reserve nicht.

gerendert wird als alle Fälle protect_class=98, 24 jeweils als type=boundary-Relation.
nicht gerendert wird: protect_class=16 als simple Fläche…

Ich bin mir aber nicht abschließend Sicher was alles und was nicht gerendert wird…

…auf die Schnelle,

Sven

Ja korrekt, wegen leisure, da dies in osm2pgsql bei Carto als Fläche (Flags=polygon) eingestuft wird.

Von daher wäre bei www.openstreetmap.org und www.openstreetmap.de die Darstellung von boundary=‘protected_area’ vorhanden, wenn
a) boundary=‘protected_area’ zusammen mit area=‘yes’ verwendet wird
b) boundary=‘protected_area’ als Relation getaggt wird
c) boundary=‘protected_area’ zusammen mit einem Tag verwendet wird, das bereits als Fläche eingestuft wird (z.B. leisure)
Ich glaube, das dürften die Fälle gewesen sein. Trifft a), b) und c) nicht zu, wird nichts bei openstreetmap.org und openstreetmap.de dargestellt.

Edit: Und/oder korrigiert

Ja, als Hinweis fände ich es sinnvoll und man könnte betonen, dass area=‘yes’ nur ein Workaround ist, bis Carto sein Verhalten korrigiert => Kommentar: Mir wäre eine Korrektur in Carto auch lieber, kann aber auch mit area=‘yes’ leben.

Edit: => Kommentar gegänzt

Das facepalm-Carto-Render-a-b-c von Andreas deckt sich auch mit meinen Kenntnissen/Erfahrungen,
habe einen “Hinweis” in DE:Tag:boundary=protected area gesetzt:
https://wiki.openstreetmap.org/w/index.php?title=DE%3ATag%3Aboundary%3Dprotected_area&type=revision&diff=1943270&oldid=1930967

(ist in dieser Diskussion für mich aber ein Randaspekt, bin weiterhin offen für die abschließende Bearbeitung von
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&oldid=1941927
dort ist die “Kernspezifikation” der “Sonderflächen” abgelegt, wenn die einvernehmlich fixiert ist, würde ich auch die anderen involvierten Seiten Ergänzen)

Grüße in die Runde
Jo

+1

Im Notfall kann ich auch damit Leben, man muß sich aber gewiss sein (und es wie du richtig schreibst, auch Dokumentieren), daß es in der derzeitigen Situation nur noch Tagging für den Renderer ist, genauso das Setzen von leisure=nature_reserve letztendlich nur noch Tagging für den Renderer ist.

Sven

Hi Jo,

Von mir: +1

Einzig nach dem Satz

Die Festlegung einer flächenbezogenen Zugangsbeschränkung erfolgt über einen zusätzlichen access=no-Tag (wenn ganzjährig) bzw. über DE:Conditional restrictions (wenn saisonal).

würde ich noch zusätzlich ergänzen:

Sollte die Zugangsbeschränkung nicht rechtlich bindend sein, sondern auf freiwilliger Basis beruhen (=gewünschter Betretungsverzicht), wird beim access-Tag statt einem ‘no’ ein ‘discouraged’ verwendet.

Wenn keine Einwände kommen, würde ich kommende Woche die reellen OSM-Objekte der https://wiki.openstreetmap.org/wiki/DE:Betretungsverbote_für_Gebiete_im_Winter#Beispiele entsprechend unserem besprochenen Tagging anpassen.

Grüße
Andreas

@Andreas Binder
Da wir damit doch bei der “Doppelklärung” gelandet sind, habe ich das dann lieber auch in die Tabelle übernommen:
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&oldid=1944224#Sonderfl.C3.A4chen
ansonsten ist damit für mich aber alles zentral notwendige besprochen und festgehalten. Mein Plan: Du kannst auf dieser Basis taggen und testen, wenn von dir ein “Auswertung klapp” und von Anderen in den nächsten Tagen keine Einsprüche mehr kommen, arbeite ich die Sonderflächen-Spezifikation zeitnah in das .de-Wiki ein.

@Alle
Wir planen hier eine dauerhafte Festlegung wer noch Einwände hat, kann sie noch äußern.
Die neue Festlegung betrifft nur die Sonderflächen in obigen Link und ist eine Ergänzung, keine Änderung unserer 2018 erstellten Spezifikation zu Schutzgebieten,
das bedeutet, bei den eigentlichen Schutzgebieten ändert sich nichts.

Es gibt noch eine anderer Diskussion zu einem verwandten Thema, der Wiki-Spezifikation des access=no an Wegen in Schutzgebieten. Die hatte ich nach Beginn dieser Diskussin estmal ruhen lassen, um pot. Überschneidungsprobleme auszuschließen. Konsens in der hiesigen Diskussion scheint mir aber eindeutig: Sonderflächen und Wege getrennt betrachten. Daher werde ich, wenn die Wiki-Spezifikation der Sonderflächen abgeschlossen ist, hier im Forum auch das Thema der Wege wieder aufgreifen.

Grüße Jo

Hi Jo,

Ich habe nun die letzten Tage die reellen OSM-Ojbekte aus den Beispielen im Wiki (https://wiki.openstreetmap.org/wiki/DE:Betretungsverbote_für_Gebiete_im_Winter#Beispiele) und die Flächen in meiner Gegend entsprechend unserer Diskussion getaggt (falls ich was übersehen habe, bitte Bescheid geben) und meinen kleinen Renderer angeworfen. Der Betreuer von xctrails.org hat sein Rendering bereits ein paar Tage früher als ich umgestellt. Mein Renderer http://osmlayer.bplaced.net/winterLayer/#map=15/47.6681/12.6076 ist nun fertig und wäre mit dem gemeinsam erarbeiteten Taggingkonsens sehr zufrieden :slight_smile:

Danke schon mal an alle Beteiligten in dieser Diskussion und speziell an Jo und Sven, die auch in “nerdingen” Zeiten noch fleißig dabei waren!

Grüße
Andreas

Edit: Schreibfehler korrigiert

Inzwischen findet sich die Sonderflächen-Spezifikation in
https://wiki.openstreetmap.org/wiki/DE:Key:protection_title

Weiterhin aufgenommen als kurz-Erwähnung/Hinweis mit Link, jeweils an geeigneter Stelle in
https://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area
https://wiki.openstreetmap.org/wiki/DE:Key:protect_class
https://wiki.openstreetmap.org/wiki/DE:Schutzgebiete_des_Natur-_und_Landschaftsschutzes

Wenn alles klappt werden bald auch die erklärungsbedürftigen OSM-Termini “Gebietsverbot” + “Schongebiet” von der OSM-Homepage als solche erkannt und es wird auf die Sonderflächen-Spezifikation verlinkt.

@Andreas, wenn Du zufrieden bist, bin ich es auch :slight_smile:
(denke, dass neben Mappererfahrung auch (d)ein Interesse an Auswertung wichtig ist, wenn es gilt derartige OSM-Festlegungen zu entwickeln)

Was mir beim durchclicken (nur der Beispiele in der Wiki-Spezifikation) aufgefallen ist, müsste
https://www.openstreetmap.org/way/251790261
nicht access:conditional sein?

In
https://wiki.openstreetmap.org/wiki/DE:Betretungsverbote_f%C3%BCr_Gebiete_im_Winter
und deinen Beispielen würde ich auf area=yes generell verzichten. Unter der Prämisse, dass 14er Gebiete ohnehin nicht betroffen sind, würde ich Nonsens-Tagging nicht grundlos Vorschub leisten wollen… ausdiskutieren will ich das aber auch nicht.

Grüße in die Runde
Jo

Hi Jo,

Auf der Fläche passt das access=no schon, da ganzjährig die Fläche nicht betreten werden darf. Die Wege hingegen sind erlaubt und nur vom 1.12-31.5 gesperrt, d.h. das access:conditional würde an den Wegen getaggt werden.
Edit: Habe diese Besonderheit im Fallbeispielnamen und Beschreibungstext nun noch etwas mehr hervorgehoben.

Nachdem ich für meine Auswertung area=yes nicht brauche und bei den 14er Gebieten Carto eh nix darstellt, habe ich dort in meinen Beispielen das access=yes entfernt.

Grüße
Andreas

Ach hier wollte ich ja auch noch meinen “Senf” dazu ablassen…

Das Kartenbeispiel gefällt mir. Danke… Das zeigt, was möglich ist. Es zeigt auch, daß das ganze boundary=protected_area-Konzept Ideal ist, um eine Art hierarchisch aufgebauten Schutzgebietslayer allgemein zu entwickeln, womit auch solche Details abgebildet werden können.

Es zeigt auch, daß auf der Standardkarte nur Grundinformationen zu sein brauchen, wie Außengrenzen von wichtigen Schutzgebietskategorien und höchtens vielleicht noch Bereiche mit absolutem Betretungsverbot…

Sven

Mmh, da haben wir uns möglicherweise missverstanden …
Vor einigen Tagen habe ich ein NSG erfasst, auf einer Teilfläche besteht ein Wegegebot, erfasst habe ich diese Teilfläche nicht gesondert, denn,

  1. Wir haben (bisher) keine Wegegebot-Sonderfläche definiert
  2. “Wegegebot” an einer Fläche hat nur begrenzte Aussagekraft, da dadurch nicht festgelegt ist welche Wege konkret legal bzw. illegal sind, das kann nur am Weg selbst erfolgen.

Gebietsverbot geht über Wegegebot hinaus, in einer Gebietsverbot-Sonderfläche mit access=no dürfte es nach meinem Verständnis i.d.R. gar keine legalen Wege geben, alle Wege wären ganzjährig access=no.

Wenn Du die zusätzliche Flächen-Eigenschaft Wegegebot zusätzlich zum saisonalen Gebietsverbot (mit)erfassen möchtest, dann sollten wir uns da was zusätzliches Überlegen.

Gruß und Danke für den area=yes-Verzicht
Jo

Hi Jo,

Ja, das scheint mir auch so :wink:

Ich hätte keine Notwendigkeit gesehen, für Wegegebote etwas extra zu machen und möchte auch nicht das bisher etablierte access-Tagging an Wegen ändern.

Ich hätte die Beschränkungen, die das Betreten der Fläche einschränken, an die Fläche getaggt und die Beschränkungen, die das Betreten der Wege in der Fläche regeln, wie bisher an die Wege getaggt.

Ich wollte keinerlei Vererbung der Flächebeschränkung auf die Wege.

Beispiele:
a) Wenn das Betreten der Fläche verboten ist und das Betreten der Wege darin ebenfalls => access=no an die Fläche und access=no an die Wege.
b) Wenn das Betreten der Fläche verboten ist und das Betreten der Wege darin erlaubt ist => access=no an die Fläche und die Wege ganz normal wie immer taggen (highway=*…, durchaus ohne weitere access-Tags, wenn es keine Beschränkungen auf den Wegen gibt).
usw.

Würde ich nicht so sehen. Das access=no der Fläche soll meiner Meinung nicht an die Weg darin vererbt werden und die Wege könnten durchaus erlaubt (z.B. bei Wegegebot), verboten oder zeitlich eingeschränkt sein, je nachdem, was auf den Wegen gilt.

Wir könnten auch einen extra protection_tilte Flächen mit Wegegebote machen machen, aber ich würde die Notwendigkeit aktuell dafür nicht sehen.

Ich hoffe du verstehst, was ich meine. Es ist manchmal gar nicht so leicht, das rüberzubringen, was man sich denkt…

Grüße
Andreas

Mit “vererbt” kommen wir hier wahrscheinlich nicht weiter, vielleicht hillft es Flächen und Wege als Erfassungs- wie Auswertungsmäßig getrennte Systeme zu sehen (die natürlich “irgendwie” schon synchron sein sollten)

an diesem Punkt ist meiner Einschätzung nach eine Differenzierung von Gebietsverbot vers. “Wegegebot” (bisher undefiniert) auf Flächenebene, also ohne Wege-Tags nicht möglich, dies sollte aber innerhalb des boundary=protected_area-Schemas möglich sein.

Ich habe mal DE:Key:protection_title vergenauert:
https://wiki.openstreetmap.org/w/index.php?title=DE%3AKey%3Aprotection_title&type=revision&diff=1948680&oldid=1947301

Schau mal und schreib einfach, was Du denkst …

Ich würde nicht unbedingt synchron dazu sagen, sondern das jeweilige Objekt (Fläche oder Wege) soll den für sich korrekten access-Tag getaggt bekommen, der sich aus der Verordnung/Beschilderung/usw. ergibt, z.B. “access=no” für die Fläche und “access:condition=no @ (Dec - May)” für die Wege beim Geigelsteinbeispiel, oder “access:conditional=no @ (Nov 1 - Jun 15)” für die Fläche und gar kein separates access-Tag für die Wege beim Hochgimpflingbeispiel.

D.h. du meinst, wir bräuchten für Flächen mit Wegegebot einen weiteren protection_title, z.B. “Wegegebot”?

Grüße
Andreas

Diese Fläche (und alle derartigen) überspannt auch die Wege - eine korrekte saisonale Auswertung ist damit nicht möglich.
Ein fiktiver Wanderer, der sich in einem zukünftigen Sommer eine tagesaktuelle Karte der Region erstellt hätte in einer Anwendung, die sich an unsere Spezifikation hält, dort einen großen Verbotsfleck auf der Karte, wo tätsächlich nur ein unproblematisches Wegegebot besteht.
Ein Router wäre nicht betroffen, und gegen dein Wegetagging habe ich ja auch keinerlei Einwände, aber das nutzt der Fläche nichts, die muss auch isoliert funktionieren, sprich korrekt auswertbar sein.

Wenn Du zusätzlich auch Wegegebote flächig erfassen und auswerten willst, dann müssen wir das vernünftig spezifizieren. Nur mal angedacht…
-Eine 3. Sonderfläche protection_title=Wegegebot einzuführen ist zunächst mal einfach.
-Dir geht es aber um saisonales Gebietsverbot + ganzjähriges Wegegebot an einer Fläche - was wohl eine 4. Variante nötig machen wird.
-Wenn für Teilflchen ein Wegegebot besteht, dann aber nicht für das gesamte Schutzgebiet - diese Tatsache sollte dann sinnvollerweise auch (irgendwie) erfasst werden.
-[…]

Grüße Jo

Hi Jo,

Verstehe nicht ganz, was hier problematisch wäre. Der Wanderer sieht auf der Karte eine markierte Fläche, die er nicht betreten darf und einen Weg, den der Renderer, je nach access-Tags unterschiedlich darstellt. Wenn ich den Weg das ganz Jahr betreten darf (z.B. “unproblematisches Wegegebot”), dann würde der Weg vom Rederer ganz normal, wie jeder andere Weg dargestellt werden (Nr2 im folgenden Bild). Wenn es eine zeitliche oder dauerhafte Beschränkung gibt, kann der Renderer eine andere Wegedarstellung verwenden (Nr3 und Nr1).

Vielleicht hilft hier ein Bild, um zu zeigen, was ich meine und warum ich eigentlich bei einem Wegegebot kein Problem, keine Besonderheit sehe und auf eine weitere Komplexität durch weitere protection_titles verzichten würde, wenn es nicht unbedingt notwendig ist:

Für mich sind die access-Tags der Fläche komplett unabhängig (d.h. keine Vererbung, Übertragung, Anwendung, gedankliche Kopie der Eigenschaften der Fläche auf die Wege) zu den access-Tags, der darin befindlichen Wege. Wenn eine Fläche den name=“Naturschutzgebiet XY” trägt, dann hat dieser Name doch auch nix mit den Namen, der darin befindlichen Wegen zu tun und die Namen der Wege können komplett unterschiedlich (nicht synchron) gemappt sein, zu dem Namen der umgebenden Fläche.

Was meinst Du dazu? Siehst Du immer noch (Bitte um Entschuldigung/Korrektur, wenn ich dich hier falsch verstanden habe sollte)
a) die Notwendigkeit eines eigenen Taggings, wenn ein Wegegebot exisitiert?
b) dass die access-Tags der Fläche “irgendwie schon synchron sein sollten” zu den access-Tags der Wege und nicht, wie ich denke, komplett voneinander unterschiedlich sein können?

Auf a) könnte ich mich einlassen, wenn dies wirklich notwendig ist. Bei b) hätte ich größere Bauchschmerzen (und hoffe, dass ich dich etwas falsch verstanden habe).

Grüße
Andreas

Edit: Schreibfehler korrigiert

Deine 1-2-3 Differenzierung mag für deinen Anwendungsfall funktionieren bzw. ausreichen,
Die Wege bzw. deren Rendering weggedacht, sehe ich 3 identische gelbe Flächen.
Tagging der Fläche am Mühlhörndl:
protection_title=Gebietsverbot
access=no
Die Legenden-Beschriftung für dieses Gelb wäre nach unserer Spezifikation
“ganzjähriges Betretungsverbot”.

+1, weil ein Wegegebot (sogar idR?) nicht ein Betretungsverbot außerhalb der Wege impliziert.