Ich bekenne freimütig das Thema Biosphärenreservat und seine Zonierung nicht deutschlandweit zu überblicken, bzw. habe da kein OSM-Konzept in Kopf oder Tasche. Wenn jemand ein vernünftiges Schema für ganz .de(!) hat, nur raus damit. Allerdings muss diese Zonierung nicht zwingend über die protect_class abgebildet werden, dies könnte auch innerhalb der 98 über den protection_title erfolgen - nur so als Idee.
Wenig zielführend erscheint mir aber der Ansatz in NSG-Verordnungen nach “denkbaren” protect_class=1 Schnipseln zu fahnden, um diese Teilflächen aufzupimpen.
… eben und offen gestanden werde ich das in naher Zukunft nicht zu meinem Thema machen (habe gerade keins vor der Haustür ;-). Aber wer das Thema “Biosphärenreservat und seine Zonierung in OSM” zukünftig angeht und im Rahmen seiner Forschungen eine Ergänzung/Erweiterung/Detailierung unserer gegenwärtig nur andeutungsweise vorhandenen Spezifikation wünscht oder vorschlägt, (wie Andreas mit “seinem” IMHO spezifikationswürdigen Thema) wird mein Gehör finden.
Beispiel Nr4 ist vielleicht auch ein Grenzfall, wo protect_class=1 oder 14 gehen würde (Irgendwie finde ich die Verordnung auch nicht immer eindeutig zu lesen. Zumindest für mich). Ich würde es erstmal auf protect_class=14 lassen. Wenn jemand aus der Verordnung ein klares protect_class=1 herauslesen kann, können wir es immer noch ändern. Hoffe, das ist OK für Dich?
Hi Jo,
war ein paar Tage offline unterwegs, so dass ich erst jetzt antworten kann.
So, so
Ja, das wäre möglich und Ja, für mich gelten die access-Tags an den Flächen nur für die Fläche und haben keine Vererbung an die Wege. Wege sollen, wie bisher, ihre eigenen access-Tags haben.
Nur so eine optionale Zusatzidee um kurz vor 01:00 Uhr: Wenn wir bei Schema B bei protection_title statt deutsche Ausdrücke, wie “Gebietsverbot” einen englischen Ausdruck, wie z.B. “deny_zone” verwenden würden, könnte die Idee evtl. auch in anderen Ländern Verwendung finden.
Vorschläge, die Schildbeschriftungen, wie “Ruhezone für Fische und Vögel”, “Wildruhebereich Klausgraben” usw. zu mappen:
prefix ind name:prefix=* und Eigenname in name=* (wie im Beispiel Nr8)
Bei den Zonierung wäre ich für einen eigenen Forumthread, wenn Interesse besteht, da das etwas über mein Anliegen “nur” die Betretungsbeschränkungen auf Schutz- und Schongebieten zu mappen hinausgeht und es damit hier nur noch komplexer wird
Ok, wenn Andere da kein Problem sehen, dann ist das für mich so durch.
Da wir hier “gegenwärtig noch frei festlegbare, projektinterne Termini” vor uns haben, spricht zunächst mal nichts Grundsätzliches gegen deine nächtliche Idee.
Mein einziger Skrupel: Das sollte schon im jedem Land bzw. Rechtssystem entschieden werden, ich möchte keinesfalls Mapper animieren, mit einem speziell für .de bzw. sein Naturschutzrecht entwickelten Schema möglicherweise ungefragt und ohne lokalen Überblick das Ausland zu “beglücken”.
name:prefix und x_name ohne name würde uns wahrscheinlich irgendwann auf die Füße fallen, daher denke ich schon länger, besser einfach name zu verwenden. Strenggenommen ist das kein name analog zum name der Schutzgebieten, aber bevor wir da was unnötig kompliziertes zusammenwürgen …
Auf der Suche nach “Wie machen es denn die anderen” bin ich noch auf einen interessanten Punkt gestoßen, der evtl. eine Alternative zur Verwendung der access-Tags wäre: In englischen Wiki https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area (und eigentlich bei jeder anderen Sprache, außer DE, PT) wird als Zusatztag für boundary=protected_area für “The dates or times when the protected area is open to the public” das Tag opening_hours=* verwendet.
Auf den ersten Blick sieht es zwar etwas schräg aus, aber mit “opening_hours=off” könnte man “access=no” ersetzen und ein “opening_hours=Aug-Feb”
entsprache “access:conditional=no @ (Mar - Jul)”.
Vom Tag her fände ich access logischer und universeller, aber auch mit opening_hours könnte ich leben. Ich versuche mal rauszubekommen, wie stark die Verwendung von opening_hours bei boundary=protected_area verbreitet ist und was da so getaggt wird.
SemiOT… ich hab neulich schon gestutzt über die Angabe NNE… Aber klar, wenn es wie im Beispiel eine größere klar abgegrenzte Fläche ist, ist es vernünftig…
Wer den Hintergrund nicht kennt… NNE (Nationales Naturerbe) waren/sind Flächenübertragungen aus verschiedenen Eigentumsarten des Bundes, der BVVG, ect… für Naturschutzzwecke an Naturschutzverbände und Organisationen. Letztendlich war/ist diese Übertragung aber ausschließlich flurstücksbasiert. Das heißt auch, das hier höchstens auch nur größere Gebiete dargestellt werden können. Kleinere NNE-Flächen, z.B. 2-3 Flurstücke mit zusammen 1ha als NNE wird man nicht wirklich erfassen (wollen)…
Ich habe mir die Verwendung von opening_hours bei boundary=protected_area etwas angesehen (Zahlen dazu siehe https://wiki.openstreetmap.org/wiki/DE:Betretungsverbote_für_Gebiete_im_Winter#Verbreitung)). Im englischen Wiki steht opening_hours bei protected_area schon seit 2009 drin. In OSM gibt es 725 Flächen mit boundary=“protected_area” und opening_hours und davon sind 71% mit opening_hours=“24/7” getaggt. Zum Vergleich gibts z.B. boundary=“protected_area” und access=“private” über 1000x.
Eine häufigere Anwendung von boundary=protected_area in Kombination mit opening_hours gibt es in Griechenland, Albanien, Portugal, einigen Meeresinseln und am Don. Dort aber eigentlich nur mit opening_hours=“24/7”.
Nach etwas hin- und herüberlegen, sehe ich opening_hours nicht mehr als 1:1-Alternative zu den access-Tags an, sondern als Zusatzattribut. Mit den access-Tags kann ich einfach andere Situationen taggen als mit den opening_hours (z.B. Flächenverbot für Ski, aber Erlaubnis für Fußgänger).
Vorschlag für Auswerter:
Ergibt opening_hours einen
a) geöffneten Zustand der Fläche, dann können die access-Tags wirken und sollen vom Auswerter berücksichtigt werden.
b) geschlossenen Zustand der Fläche, dann braucht der Auswerter die access-Tags nicht auswerten und dieser kann, wie bei einem access=no arbeiten.
Wenn kein opening_hours an der Fläche vorhanden ist, gelten die vorhandenen Tags (darunter dann auch die access-Tags)
@Andreas Binder:
opening_hours dürfte bei den Feld-Wald- und Wiesen-Schutzgebieten in .de wenig Sinn machen - und eine Auswertung, wie sie dir vorschwebt, sollte auch ohne funktionieren (meine Meinung, will aber keine innovativen Ideen abwürgen
Was das OSM-Wiki betrifft, möchte ich die Key-Spezifikation eher “schlank” halten, mit wenigen, aber markanten Beispielen aus deinem Fundus, etwa so: https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&oldid=1941927
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.
