Keine Ahnung, wem ich gleich auf die Füße treten werde: Der Validator in meinem Editor hat recht, die vorgeschlagene Kodierung des Wegegebotes ist nicht mit dem vereinbar, was die Dokumentation zu conditional schreibt. Offroad ist weder Fortbewegungsart (4wd?) noch Richtung (vor, zurück), sondern, Einschränkung/Restriktion. Ich probiere mal:
access:conditional=track_only @ (Nov 16-Apr 30)
Einem proposal für einen neuen Wert für Access, wenn sich wer die Mühe machen wollte, würde ich weit größere Chancen zusprechen, zumal der sich ganz gut in bestehende einordnet (destination zB), als einem proposal für einen neuen Schlüssel, der bestehende Logiken widerspricht. Zum Parsen ist es auch einfacher
Das braucht es auch gar nicht, denn verordnet ist das Wegegebot von Mitte November bis Ende April. Im Sommer gibt es keine Einschränkungen. Und ein ganzjähriges braucht kein conditional, und so eine Verdopplung wird im Wiki sehr wohl beschrieben. Derweil noch eine Überlegung mehr, weil im Grunde ist es ja gar nicht neu, dass Gebote kodiert werden:
frei nach “only_left_turn” usw. Eine Wegebitte wäre dann
Meiner Englischkenntnisse nach kann title hier nur für Rechtsgrundlage stehen, das Wegegebot gehört hier jedenfalls nicht hin, das ist ja der Inhalt der Anordnung, nicht einmal der “Titel” im alltagssprachlichen Sinn des Worts.
Ich weiß, diesen Tread von Anfang an durchzulesen ist recht mühselig, aber wenn Du Dir die Zeit nimmst, würdest du sehen, warum das bisherige Tagging so entstanden ist, so wurde z.B. im Laufe dieses Forumthreads von mehreren Mappern die Notwendigkeit (siehe #117, #120 usw.) geäußert, dass die Einschränkungen für die Fläche außerhalb der Wege UND die Einschränkungen für die Wege an der Fläche getaggt werden können. In die Richtung ging, denke ich, SpaLeos …Und zwei mal der gleiche Key geht ja nicht….
Das ist doch im Ende die gleiche Warnung, dass hier ein unbekannter Wert verwendet wird. :conditional sind nur schwieriger auszuwerten und vielleicht könnte auch der Wert in der Warnung angezeigt werden.
Der Strichpunkt macht aus dem Wert eine Werteliste; Ich würds verstehen, wenn Auswerter das nicht mögen, wenn im Vorhinein nicht klar ist, ob da eine 1:1 oder eine 1:N Beziehung auf einen zukommt. Deshalb hab ich etwas angeführt, von dem ich ausgehe, dass es von Leuten mit Sachverstand erstellt worden ist.
Und ja, JOSM könnte anstatt “Falsche Syntax im Schlüssel” auch “unbekannter Unter-Schlüssel: Soundso” melden - also das, was zwischen prefix und suffix steckt herauspicken. Und natürlich gehört dann auch die Syntax vom conditional Konstrukt neu definiert, so daneben ist die Warnung nun auch wieder nicht, weil der Doppelpunkt in der Syntax vom conditional nicht das meint, was er auf der Sondergebiete Seite meint. Die heißt wohl nicht zu unrecht so.
Wenn jeder in der den protection_title schreibt was er so denkt, statt sich an gemeinsam erarbeitete Festlegungen zu halten, ist der Tag unauswertbar und wertlos.
Mir ist offen gestanden unklar, was Du überhaupt letztendlich hier in dieser Disk erreichen möchtest, kannst Du das vielleicht mal erläutern?
Ich finde einfach nur gut, was Arminus macht, Schutz- und Schongebiete kartografisch aufbereiten. Deshalb hab ich überlegt, die deutschen Regeln auf Österreich anzuwenden. Meine Probleme damit sind oben beschrieben.
Dann würde ich dir raten, dies einfach mal entsprechend der Festlegungen zu machen statt (sorry!) rumzumosern.
Nochmal in aller Ausführlichkeit zu deinem conditional-“Problem”:
Es besteht überhaupt kein Grund, sich 1:1 an Vorgaben zu halten, die hier ohnehin nicht wirklich passen.
Bei einem klassischen OSM-Objekt mit Einschränkungen, wie Gebäude oder Weg, ist man gut beraten sich ganz genau an die Vorgaben zu halten.
Bei einer Schutzgebietsfläche mit Wegegebot sieht die Sache systematisch anders aus,
weil die Conditional restrictions ja ohnehin gar nicht für die gesamte Fläche gelten - nämlich nicht für das Entscheidende, die Wege.
Es ist ein reiner (interner) Schutzgebiets-Sortier- und Auswertungsschlüssel, der einzig und nur für diesen Kontext gemacht und gedacht ist.
Momentan steht über der Sonderflächen-Tabelle:
“Die Festlegung einer flächenbezogenen Zugangsbeschränkung erfolgt über einen zusätzlichen access=-Tag (wenn ganzjährig) bzw. über DE:Conditional restrictions (wenn saisonal), …"
würde es dir weiterhelfen, wenn ich dies ändere in:
"Die Festlegung einer flächenbezogenen Zugangsbeschränkung erfolgt über einen zusätzlichen access=-Tag (wenn ganzjährig) bzw. angelehnt an DE:Conditional restrictions (wenn saisonal), …”
?
Jetzt weiss ich als Nutzer warum ich nicht mehr über die Elddeichbrücken komme, sondern mit dem Rad , in der Planung, über China fahren muss…
Nehmt es mir Übel oder nicht aber Zugang oder nicht ist in Naturschutzgebieten ausgeschildert und auf den meisten Wegen sind jene auch frei zugänglich, solange man den Weg nicht verlässt.
Was ihr da also vorhabt erschwert die eigene Planung nicht unerheblich und dann wendet man sich anderen Projekten zu.
Wünschenswerter wären genaue Angaben zum Betreten von Truppenübungsplätzen!!! Hier gibt es Bereiche wo das betreten strafbar ist. Zumal ich in der Lüneburger Heide sogar im Wandermodus auf der Panzerstraße wandern oder Radfahren könnte… ?
PS: Wie kann man bei der Planung oder nachträglichen GPX Ergänzung solche unzugänglichkeiten umgehen?
@JamesBont: Vielleicht beschreibst Du Dein Anliegen besser in einem eigenen Beitrag, als ein Thema aus 2019 zu kapern, was mutmaßlich überhaupt nichts damit zu tun hat. Bei der Gelegenheit kannst Du auch gern die offenen Fragen beantworten, die man Dir in Deinen anderen beiden Beiträgen gestellt hat.
Ich hab immer so etwas eine Unklarheit im Kopf, wie eine datentechniche Erfassung eines NSG mit Totalreservaten aussieht, vor allem, wie man dieses erfasst, um im Nachhinein nur dieses NSG mit seinen, direkt laut Verordnung zu diesem NSG gehörenden Totalreservatsflächen abfragen zu können.
Auf dererlei Fälle stößt man ja aller Orten. Ich hatte mal in Erwägung gezogen, solche, per Verordnung definierte Totalreservate in der Relation mit der Rolle “subarea” zu versehen. Das liegt mir da am nahesten…
Ich greife diesen Thread noch einmal auf, um mich nach dem Mapping von Biosphärenreservaten zu erkundigen:
Laut Wiki sollen nur die Pufferzone mit pc=98 ausgestattet werden. Ein solches Mapping existiert in Deutschland nicht, jedenfalls konnte ich in keinem der 12 erfassten Biosphärenreservate eine gemappte Pufferzone finden.
Die 12 erfassten Biosphärenreservate haben die folgenden protect_classes: 6x 98, 4x 5, 1x 4 und 1x keine.
Könnten wir uns darauf einigen, Biosphärenreservate mit pc=98 zu erfassen und dies auch so im Wiki festhalten? Da es, wie erwähnt, keine Pufferzonen mit pc=98 gibt, führt dies auch zu keinerlei Widersprüchen.
Ich habe hier im Spreewald in der letzten Zeit alle tangierenden administrativen Grenzen nach den hier in Brandenburg verfügbaren Daten (z.B. Gemeinden, Ortsteile, Gemarkungen) lagekorrigiert (=persönliche “Monatsaufgabe”) und ich arbeite mich nun nach gut 8 Jahren erneut durch die Rechtslage meines heimatlichen Spreewaldes…
Diese “Pufferzonen” sind da nicht festgelegt… Ferstgelegt ist die Außengrenze, sind die NSG’s und deren Totalresevate. Ich kenne und habe hier zwar auch die Grenzen der Pufferzonen, sind aber Altdaten (>20 Jahre alt) und ich kenne hier keine öffentliche Quelle oder rechtliche Bindung.
Für die Allgemeinheit von Bedeutung und OTG sichtbar sind im wesentlichen die Kernzonen - da gibt es Betretungsverbote, aufgelassene und erlaubte Wege.
Die Pflegezonen drumherum interessieren nur die Förster und Landwirte, da gibt es Einschränkungen für sie.
Die Entwicklungszonen haben de facto nur Bedeutung fürs Marketing. Ihre Grenzen stehen in den bunten Plänen und OTG dort die schönen Schilder am Straßenrand.
Für OSM sind mMn die Kernzonen Pflicht, die Entwicklungszonen Kür und auf die Pflegezonen kann man verzichten.