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