Import (?) NSG's Sachsen-Anhalt

Ja. Grundsätzlich sind Importe kompliziert und Neulinge sollten vielleicht erst etwas Erfahrung mit OSM sammeln, aber im Grunde würde auch ein Neuling Hilfe bei seinem Import bekommen, wenn er sein Vorhaben vorher diskutiert. In diesem Fall gab es einen Beitrag auf der internationalen Imports-Liste, und da habe ich dann empfohlen: “You should definitely get in touch with the German community either on the talk-de list or on the German forum to hear their opinion.” Ich habe mich dann nicht weiter um die Sache gekümmert, weil ich annahm, er würde das hier diskutieren.

Hätte bereitwillig und gerne Support geliefert,
insbesondere aber gewarnt, dass das Thema (mit dem ich mich schon länger in OSM beschäftige) so untrivial nicht ist,
und ein automatisierter Schutzgebiets-Massenimport - aus mehreren Gründen - nicht so einfach ist, wie man sich das vielleicht vorstellt.

[Daher habe ich bei meiner Hessen-NSG-Kompletterfassung über einen automatisierten Import garn nicht erst weiter nachgedacht,
sondern die NSG eines nach dem anderen quasi händisch bearbeitet, dabei bin ich landkreisweise vorgegangen und habe overpass-Kontrollscripte benutzt um Fehltagging zu vermeiden - dauerte natürlich ein wenig, aber dafür passt das dann auch]

Dazu muss ich aber auch vorher was von der Sache mitkriegen.

Tja, was machen wir mit der verfahrenen Kiste… ?

Unterm Strich ist Jo’s vorgehensweise die einzig richtige: alles Gebietsweise abklappern… und den Gegebenheiten anpassen und einzelgebietsweise hochladen. Es ist zwar eine Heidenarbeit, geht hier eigentlich auch nicht anders.

Ich habe auch das Gefühl, daß die grundsätzliche Datenlage nicht so toll ist…

Letztendlich haben wir zwei Gruppen an Daten (Fehler in Keys oder Länge des Keys klammere ich mal aus):

  1. NSG ist völlig neu, war noch nicht in OSM
  2. NSG ist bereite in OSM, es gibt ein Duplikat.

Gruppe 1: Man könnte nun sagen: ‘Ok, passen wir die Grenzen da an, wo es nötig und erforderlich ist’
Bei bereits vorhandenen Grenzen (Gruppe 2) kann und muß meiner Ansicht nach die Historie gewahrt bleiben… das ältere Objekt zählt also.

Ich denke in Sachsen-Anhalt ist es ähnlich wie in Brandenburg… Es gibt Schutzgebiete die z.B. per Reichsgesetzblatt in den 1930er oder 1940er Jahren ausgewiesen worden sind. Da kann man wenig machen… Grenze übernehmen und den Gegebenheiten anpassen. Alles, was zu DDR-Zeiten ausgewiesen wurde, dürfte es ähnlich seien, hier sollte bereits nach Admin-Grenzen geschaut werden, evt. auch anhand älterer Karten. Bei solchen Ausweisungen ist selbst bei Landesbehörden mitunter mal die Datenlage mau…

Noch zur Ergänzung…

Da auch Schutzgebietsflächen des Nationalparkprogramms der DDR betroffen sind (Biosphärenreservat Mittlere Elbe) ist es ohnehin interessant, was dort die rechtsgültige Grenze ist. Diese Ausweisungen des o.g. Nationalparkprogramms wurden bei der letzten Volkskammersitzung der DDR beschlossen und haben Kraft Einigungsvertrag Landesgesetzcharakter. Jede Gebietsänderung bedarf also ein Landesgesetzgebungsverfahren. Das mal am Rande…

unschlüssige Grüße,

Sven

Möchte noch auf ein Grundproblem (neben der Dopplung) bei derartigen Importen hinweisen, welches jemanden der nicht so in der Materie drin ist nicht klar sein dürfte.
Schutzgebiete sind häufig mehrflächig - es extieren mehrere, voneinander getrennte Flächen, die aber ein Schutzgebiet bilden. Mal bei “A”, dem Altmarkkreis Salzwedel rausgesucht:

Diese 3 Flächen sind ein NSG
https://www.openstreetmap.org/way/927936223
https://www.openstreetmap.org/way/927936224
https://www.openstreetmap.org/way/927936225
Ebenso diese 2
https://www.openstreetmap.org/way/927936218
https://www.openstreetmap.org/way/927935928

Und hier wurden wohl bereits exkludierte inner-Flächen angelegt
https://www.openstreetmap.org/relation/12555513
diese potentielle outer-Fläche aber wohl vergessen
https://www.openstreetmap.org/way/927935934

Was ich damit sagen will: wenn ohnehin jedes NSG einzeln (nach)kontrolliert und meist händisch nachbearbeitet werden muss, dann bietet automatisierter Massenimport halt keinen Vorteil.
Auch wünschenswete wikimedia-Tags lassen sich nicht automatisch aus den behördlichen Daten generieren.

Auch in den Daten aufgefallen:

All dies ist schon lange auch so dokumentiert.
Nicht dokumentiert ist:
Bei der Übernahme freigegebener behördlicher Geometriedaten (die ich begrüße!) würde ich empfehlen an jedes betroffene OSM-Objekt Quelle und deren Datenstand zu taggen (nicht nur im CS erwähnen), habe dies in Hessen so gelöst:
source:shape=NATUREG Stand 2020-12-15

Die Frage ist halt, ob der User bereit ist derartige Nacharbeiten zu leisten?

Im Post 13 lese ich das jedenfalls so heraus, weiss nur nicht ob das Ausmass bekannt ist.

Grüße von Lutz

Hi ihr,

mittlerweile müssten hoffentlich alle Dopplungen und verstümmelte keys aufgeräumt sein. Ich würde als nächste all zu komplizierte multipolygone vereinfachen, z.B. sowas:https://www.openstreetmap.org/relation/12555509#map=12/51.8843/12.0673
In den Daten gibt es Kernzonen, und Pufferzonen (rechtlich alles Naturschutzgebiet) dazu kommen aber auch noch Ausschlussflächen, daraus resultieren dann leider komplizierte (und dem Gedanken des Artenschutzes auch nicht zuträgliche) Geometrien.
Findet ihr so etwas abzubilden erstrebenswert oder soll ich das vereinfachen?

Hier noch mein Antwort auf Jos Punkte:

Die von dir angesprochenen falschen Tags (ref, type) hatte ich mir bei bestehenden NSGs abgeschaut. Ich hatte auch drei NSGs testweise importiert und da kam der Kommentar die source und licence nur in das changset zu packen, dann dachte ich der Rest passt. Ich verstehe aber den Punkt des type=boundary für NSGs mit nur einer Fläche und setzte das gerne um.

Diese 3 Flächen sind ein NSG
Das liegt an nicht zugeordneter membership von polygonen schätze ich, versuche das anzupassen.

Und hier wurden wohl bereits exkludierte inner-Flächen angelegt
Das verstehe ich nicht ganz. Das ist die Pufferzone https://www.openstreetmap.org/way/927935931, das die Kernzone https://www.openstreetmap.org/way/927935932 und das die Ausschlussfläche https://www.openstreetmap.org/way/927935930

https://www.openstreetmap.org/way/927935934 ist nur ein weitere Teil des NSG welches nicht in der obrigen Pufferzone liegt, vielleicht ist das die selbe Problematik der nicht richtigen memberships?

Was mir noch Bauschmerzen bereitet ist, z.B. sowas folgt ja relativ genau bereits bestehenden Daten https://www.openstreetmap.org/relation/12555513#map=17/52.44603/11.11426. Ist es gewünscht/zwingend, dass das NSG sich dann auf diese bezieht. Falls ja müsste mir jemand ein Anleitung schicken wie das geht.

Umsetzung: 1. type= boundary für NSGs mit nur einer Fläche
2. ref:DE-ST=* für alle NSGs
3. fehlende memberships korrigieren

Viele Grüße und sorry für den Aufruhr, finde OSM auf jedenfall eine tolle Sache und habe Lust mit zu machen,
Sebastian

type=boundary anstatt von type=multipölygon gilt generell für jede Schutzgebietsrelation, egal ob eine oder mehrere Teilflächen.

Ja, und wie dies zu lösen ist, ist hier dokumentiert:
https://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area#Relation_type.3Dboundary

Wenn Du bereit bist, deine Daten zu überarbeiten, bin ich gern bereit zu helfen, würde vorschlagen nicht hektisch zu ändern, sondern Schritt für Schritt vorzugehen und hier anzufangen:
https://de.wikipedia.org/wiki/Liste_der_Naturschutzgebiete_im_Altmarkkreis_Salzwedel
Dort finden sich auch Links auf die wünschenswerten Wikipedia-Artikel, und über die auch zu den wikidata-Tags

Dies ist eine Abfrage zur Kontrolle
http://overpass-turbo.eu/s/15Yb
(fängt u.U. auch einige NSG aus Nachbargebieten, davon nicht irritieren lassen)

Mein Vorschlag: nimm Dir doch bitte mal den “Ferchauer Forst” und nur den vor und verwandele den mal in eine graue Relation type=boundary
Dann vermekst Du dies hier und wir sehen+reden weiter…

Gruß Jo

Sorry, dass ich dazwischen gefunkt habe.
Mir sind halt die Doppeleinträge aufgefallen.
Hatte bereits folgende bearbeitet:

https://www.openstreetmap.org/relation/5166633
https://www.openstreetmap.org/way/41911105
https://www.openstreetmap.org/way/927936220

Bin auch gerne bereit mitzuhelfen, wenn es meine Zeit erlaubt.

Mmh
https://www.openstreetmap.org/relation/5166633/history
vgl.
https://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area#weitere_sinnvolle_Tags_bei_Schutzgebieten
“ref:(Bundesland-Kataster)=* - Kennung im offiziellen Schutzgebiets-Verzeichnis, dies sind in Deutschland normalerweise Kataster des jeweiligen Bundeslandes.[…]Das jeweilige Bundesland-Kataster wird mit der Länderkennung nach ISO 3166-2:DE abgelegt. […] Hinweis: In früheren Dokumentationen wurde die Verwendung des Key SGD-ID:ref für diesen Zweck empfohlen, der jedoch keine sinnvolle Differenzierung erlaubt und daher - nach Kontrolle - ersetzt werden sollte.”

Wäre wirklich schön, wenn meine Prosa auch gelesen würde;-)

Werde ich machen, habe es halt aus der OSM-Datei übernommen. :frowning:

Wäre es dann so richtig?

ref:DE-ST=173

ich würde noch weiter gehen: nur weil eine bestimmte Stelle einen Satz opendata veröffentlicht, aus dem man in bestimmten Fällen verbesserte Daten entnehmen kann, heißt das nicht, dass man alle Daten aus dem Datensatz importieren sollte. In jedem einzelnen Fall muss geprüft werden welcher Teil der Daten Sinn macht zu übernehmen und welcher nicht.
Die absolute Lage der Stützpunkte interessiert dabei eher weniger, für uns ist es weitgehend egal ob ein Punkt 5m links oder rechts liegt, aber die Topologie sollte stimmen. Wenn die Grenze auf der admin-Grenze verläuft sollte das bei uns auch so sein, und wenn eine Straße gerade nicht mehr im Gebiet ist, dann sollte sie auch bei uns nicht drinnen sein (als Beispiel)

Der Key: Ja

Zum Value habe ich nur diese Infos in Text und interaktiver Karte (dort den i-Button aktivieren und in das Gebiet klicken):
https://lvwa.sachsen-anhalt.de/das-lvwa/landwirtschaft-umwelt/naturschutz-landschaftspflege-bildung-fuer-nachhaltige-entwicklung/naturschutzgebiete-in-sachsen-anhalt/saale-elster-aue-bei-halle/
https://lvwa.themenbrowser.de/UMN_LVWA/php/geoclient.php?name=naturschutz&ZOOMTOTABLE=NSG,CO,0173

würde zu “0173” tendieren
SR12323 hat immer noch das “NSG” davor gesetzt, das sich dort auch nachweisen lässt
im Wikipedia-Artikel “Das Naturschutzgebiet mit dem Kennzeichen NSG 0173 […]”
in der Wikipedia-Liste “173”
jedenafalls sollte die Notation idealerweise landesweit einheitlich sein.

Was sonst noch bei relation 5166633 auffällt:
type=boundary statt multipolygon
wikipedia=de:Saale-Elster-Aue bei Halle
und
source:shape=LAU 2019 [Value ist Vorschlag von mir]

Generell würde ich raten einen Prototypen als Vorlage zu taggen…

+1

Das mit diesen Kernzonen (Totalreservaten, Naturentwicklungsgebieten ect.) in NSG’s als “inner”-Rolle ist meiner Ansicht nach auch nicht so 100%ig richtig… als inner wäre es “ausgestanzt”. Es ist aber nur eine Teilfläche, ein subarea der Umgrenzungslinie.

Bei https://www.openstreetmap.org/relation/12555513 dürfte das inner um Buchhorst korrekt sein, die Fläche https://www.openstreetmap.org/way/927935932 ist für mich aber kein inner im geometrischen Sinne, sondern ein “subarea” Es wäre nachzurecherchieren, ob hier protect_class=4 korrekt wäre. Im Moment ist es ein NSG in einem NSG.

Sven

Edit: ich hab mal meine Overpass-Abfrage zu NSG’s auf Sachsen-Anhalt losgelassen:
https://overpass-turbo.eu/s/15ZJ

…und hier die csv-Liste: https://overpass-turbo.eu/s/15ZK

Mmh, Ja, das ist ein Problem …
Die Dinger hier im Westen sind 2 weitere Ohre-Drömling NSG-“Kernzonen”
https://www.openstreetmap.org/way/927935933
https://www.openstreetmap.org/relation/12339680

Der behördliche Viewer (der ja wohl auch mit den Daten aus diesem Import arbeitet) liefert 4 einzelne Flächen:
1x die “Ausdehnung” (hellgrün) allerdings OHNE Kernzonen
3x die “Kernzone” (dunkelgrün)

So wirklich vorbildlich finde ich dies nicht - in OSM hätte ich (primär) gern ein (verlinkbares) Gesamt-NSG - die Kernzonen eher als untergeordnete Sub-Geschichte.

Jedenfalls gibts diese Kernzonen in Sachsen-Anhalt öfters - würde raten einen Prototypen als Vorlage auszudiskutieren/zu entwickeln …


Die Zugänglichkeit zu den NSG-Infos ist in Sachsen-Anhalt ganz ordentlich gelöst, über diese Liste kommt man zu den Einzeldarstellungen der NSG:
https://lvwa.sachsen-anhalt.de/das-lvwa/landwirtschaft-umwelt/naturschutz-landschaftspflege-bildung-fuer-nachhaltige-entwicklung/naturschutzgebiete-in-sachsen-anhalt/
ganz unten im Text der jeweiligen Einzeldarstellung gibt es dann einen auf dieses NSG zentrierten Link zur interaktiven Karte, in diesem Fall:
https://lvwa.themenbrowser.de/UMN_LVWA/php/geoclient.php?name=naturschutz&ZOOMTOTABLE=NSG,CO,0387

Meine Interpretation, was da gemacht wird…

Hier in Brandenburg gibt es im Vergleich dazu zwei grundsätzliche Datengruppen bei downloadbaren Shapes (unabhängig der Datennutzung für OSM)

  1. nsg_sfl_std.shp
  2. nsg_mz_std.shp

Direktlink zu den Daten im Vergleich: https://metaver.de/search/dls/#?serviceId=1C68E21C-05EB-4195-BFA4-FD1156AF00ED&datasetId=AB2F53A4-A68E-413F-84C4-A972D2A2DA0B (mitgelieferte pdf’s sind unbedingt zu lesen!)

Das erstere liefert nur die Umgrenzungsgeometrie des Schutzgebietes. Das zweite liefert die (mögliche) Unterteilung z.B. nach Zone 1, 2, 3 (unterschiedliche Behandlung von Teilbereichen des jeweiligen NSG) oder z.B. Abgrenzung von Totalreservaten, ect…

Ich würde jetzt ganz stark vermuten, daß im Online-Dienst diese zweite Zonierungsvariante so (oder in einer abgespeckten Version) verwendet wird.

Ich jetzt von Außen, meine Frage: was ist hier mit “Kernzone” gemeint? Totalreservat, Naturentwicklungsgebiet? Dann wären diese Teilflächen für mich protect_class=1…

So, wie ich die Verordnung aber lese, ist es eine Teilfläche des NSG, für die lediglich andere Behandlungsgundsätze gilt, kein Totalreservat… es ist also eine Art Subzonierung des NSG (protect_class=4), für das wir bisher keine Lösung haben…

Wenn man solche Teilflächen, Kernzonen oder Totalreservate solches mit der Außengrenze selbst ansprechen will, geht es nur über Relations-Rollen wie subarea oder so… Warum subarea (oder so): es gibt Schutzgebietsgrenzen, wo die Totalreservatsgrenze gleich der NSG-Außengrenze ist: https://overpass-turbo.eu/s/160i Das ist das, wo ich sage, daß inner falsch ist.

Sven

Schau mal in § 4 (3) - so wie ich das sehe besteht zumindest in diesem NSG in den Kernzonen ein Betretungsverbot.
Wir könnten diese 3 Flächen insofern recht elegant mit unserer Sonderflächen-Spezifikation als protect_class=14 erfassen.

  • die 1 inner müßte aus der Relation gelöst und umgetaggt werden
  • die 2 am Westrand müssten umgetaggt UND die NSG-Außengrenze müsste dort neu um diese Sonderflächen geführt werden

Das wäre das was mir dazu spontan einfällt …

Es ist doch gut, immerwieder sich die Verordnungen selbst vorzunehmen:

Schau mal § 3 (4) Nr. 3…

Die Erwähnung von Prozessschutz und natürlicher Sukzession für Zone 1 (dann in Verbindung mit dem von dir genannten Betretungsverbot) erfüllt für mich protect_class=1

Sven

Meinethalber auch protect_class=1 (mit carto-Rendering),
wichtig ist mir vorallem, dass die NSG-Gesamtgeometrie diese Kernzonen immer mit-umfasst.

Baust Du den Ohre-Drömling (exemplarisch) um?

SR12323 lässt ja nichts von sich hören,
aber surveyor54 hat nach #29 wohl ein NSG (einfache Relation mit inner, ohne Kernzonen) umgetaggt:
https://www.openstreetmap.org/relation/5166633
Würde dort den Tagging-Standard sehen, darauf aufbauend diese Abfrage (für Saalekreis) mit Farb-Differenzierung, Tagging-Ziel für die Import-Geometrien ist grün:
http://overpass-turbo.eu/s/161b

Das kann ich machen… Ich schau mit das nachher mal an. Ich werde mich erst mal an der Lieberoser Heide orientieren und dann mal schauen…

Hier sieht man, warum die Verwendung von Inner-Rollen nicht funktioniert. In Teilabschnitten ist TR-Grenze und Außengrenze auf der Linie.
Das sieht mit in S-A bei einigen NSG’s auch so aus.

Sven