Hmnja… Größe ist relativ… Natürlich kann auch ein 1ha-Gebiet sehr bedeutend sein… Wir haben Gebiete mit unter 1ha NNE und welche mit >250ha…
Letztendlich ist hier zunächst grundsätzlich die Größe entscheidend. Je größer, desto besser. Unterm Strich entscheidet aber über die Fläche selbst diejenige Institution, die Eigentümer ist…
Ich wollte eigentlich auch nur etwas Hintergrundwissen teilen. Letztendlich fand ich das aber interessant, wie weit es gehen kann, was ich nicht schlecht finde…
Danke Andreas, für deine Initiative die vielfältigen (winterlichen) Weg- und Betretungsregelungen differenzierter zu erfassen.
Prinzipiell sollte in OSM access=no für rechtsverbindliche Verbote verwendet werden.
Unter den 8 Beispielen wären dies wohl die #3, 4, 5, 6 und 7, wo Verbote durch Verordnungen definiert sind.
Die #1,2,4 sind dagegen “nur” Empfehlungen/Appelle, die Flächen nicht zu betreten.Die ist meist ein Instrument der Besucherlenkung in den Fällen, wo ein Verbot rechtlich nicht oder schwer durchsetzbar wäre.
Dieser nicht ganz unerhebliche Unterschied sollte auch in OSM sauber abgebildet werden, z.B. käme für #1,2,4 access=discouraged o.ä. in Frage.
Zu Nr1: Auch wenn auf dem Schild “Bitte die gekennzeichneten Wanderwege und Langlaufloipen nicht verlassen” steht, ist laut, der im Wiki verlinkten, Verordnung https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=LrSbg&Gesetzesnummer=20000504 zu dem Gebiet in §3(1)3 “Verboten …das Betreten und Befahren mit Fahrzeugen aller Art durch jagdfremde Personen abseits von öffentlichen Straßen und Wegen sowie abseits von gekennzeichneten Wanderwegen, Wandersteigen, Forststraßen und Langlaufloipen jeweils vom 1. November bis zum 15. Juni des Folgejahres”, d.h. 1, 3, 4, 5, 6 und 7 wären “echte” Verbote und 2 und 8 wäre mit Bitte um Nichtbetretung.
Mir wäre ein Taggen mit area=yes oder ohne area aber nicht so wichtig, da ich mit meinem Renderer boundary=protected_area auch ohne area=yes als Fläche verarbeiten kann. Ich habe area=yes aber bewusst bei den Beispielen gesetzt, damit Mapper, die diese Beispiele verwenden, sich nicht wundern, dass unser Hauptrenderer nix anzeigt und sie erst mal den seit über fünf Jahren notwendigen Workaround https://github.com/gravitystorm/openstreetmap-carto/issues/1141#issuecomment-64991863 finden müssen.
@geow hatte ab #75 dargestellt, dass der protection_title hier eine hinreichende access-Differenzierung ermöglicht
(Habe aber auch keine Einwände gegen eine “Doppelklärung”)
Gibt es denn irgendeinen Auswerter, außer Carto, der hier “Nachhilfe” braucht? Der Tag trägt “Area” schon im value und in der OSM-Spezifikation ist klar festgelegt dass er nur für Areas (und Relations) gilt. Seit einem Jahr spiele ich mit dem Gedanken, das Carto-Problem (IMHO den Carto-Bug) in geeigneter Form in unserer Wiki-Spezifikation zu verarbeiten, denke aber jedesmal, das müsste doch mal irgendwann Carto-seitig gelöst sein. Für diesbezügliche (Formulierungs-)Ideen für unsere Wiki-Seiten zu Schutzgebieten bin ich dankbar …
Die einzigen Karten, die ich kenne, die boundary=‘protected_area’ überhaupt darstellen sind (Evtl. kennen andere noch mehr Karten? https://xctrails.org und winterLayer zählen hier nicht ):
a) www.openstreetmap.com
b) www.openstreetmap.de
und beide werten boundary=‘protected_area’ ohne area=‘yes’ nicht als Fläche aus und stellen somit dann auch nichts dar. Beide verwenden, wie die meisten Renderer, osm2pgsql zum Datenimport und da muss man beim Importieren der OSM-Daten pro Tag angeben, ob das eine Linie (Flags=linear) oder eine Fläche (Flags=polygon) ist, d.h. die müssten alle boundary-Arten (nicht nur protected_area) als Fläche einstufen. Vielleicht sträuben sich deshalb die Cartoadmins dagegen. Ob sich hier nach so vielen Jahren noch was ändern wird, ist für mich fraglich.
Vorschlag:
Aufgund unterschiedlicher Objekt-Interpretationen (https://github.com/gravitystorm/openstreetmap-carto/issues/1141) der Betreuer des OpenStreetMap-Hauptrenderers Carto werden geschlossene Flächen, die mit boundary='protected_area' getaggt wurden, aktuell nur auf www.openstreetmap.org dargestellt, wenn diese Flächen zusätzlich ein area='yes'-Tag besitzen oder als Multipolygon erstellt wurden.
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.
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…
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.
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.
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.
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.
@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.
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
(denke, dass neben Mappererfahrung auch (d)ein Interesse an Auswertung wichtig ist, wenn es gilt derartige OSM-Festlegungen zu entwickeln)
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.
