Import (?) NSG's Sachsen-Anhalt

Also nach https://wiki.openstreetmap.org/wiki/Con … rs#Germany und https://wiki.openstreetmap.org/wiki/Imp … utzgebiete ist es auf jedenfall erlaubt.....
Die Doppelungen sind natürlich nicht so super....

SafetyIng wrote:

Also nach https://wiki.openstreetmap.org/wiki/Con … rs#Germany und https://wiki.openstreetmap.org/wiki/Imp … utzgebiete ist es auf jedenfall erlaubt.....
Die Doppelungen sind natürlich nicht so super....

Aha... Gut... Danke... Ich hätte mir da ein bisschen mehr Sorgfalt gewünscht... (eben wegen dieser Doppelungen)

Sven

streckenkundler wrote:

Aha... Gut... Danke... Ich hätte mir da ein bisschen mehr Sorgfalt gewünscht... (eben wegen dieser Doppelungen)

ganz genau. Nur weil Daten lizenzrechtlich kompatibel sind muss man beim Import natürlich trotzdem aufpassen, dass keine Doppelungen entstehen...

Tags mit Tippfehlern gibt es auch reichlich, z.B. protect_cl, protection, short_prot

Die Genauigkeit der Grenzen scheint auch nicht gerade gut zu sein, quer durch Felder und über die Landesgrenzen hinweg:
https://www.openstreetmap.org/way/92793 … 1&layers=N

mueschel wrote:

Die Genauigkeit der Grenzen scheint auch nicht gerade gut zu sein, quer durch Felder und über die Landesgrenzen hinweg:
https://www.openstreetmap.org/way/92793 … 1&layers=N

leider machen manche Mapper solche Topologiefehler absichtlich, weil man die Dinge so besser einzeln anfassen kann im Editor (vermute ich). Das sollte man vielleicht mal grundsätzlich thematisieren und sich abstimmen.

mueschel wrote:

Tags mit Tippfehlern gibt es auch reichlich, z.B. protect_cl, protection, short_prot

Die Genauigkeit der Grenzen scheint auch nicht gerade gut zu sein, quer durch Felder und über die Landesgrenzen hinweg:
https://www.openstreetmap.org/way/92793 … 1&layers=N

In Abschnitt https://wiki.openstreetmap.org/wiki/Imp … mport_Data gibt es in der Tabelle eine Spalte "erfassungs" Das listet den Erfassungsmaßstab und -quelle...

TK10AS bedeutet, 1:10000, Kartengrundlage war TK10 (Ausgabe Staat). Das bedeutet, daß hier dann eine Karte aus der Vorwendezeit zur Erfassung der NSG-Grenze verwendet wurde; aus heutiger Sicht entsprechend ungenau und reichlich veraltet. Ich weiß jetzt nicht, wie es in Sachsen-Anhalt mit den Grenzen und der Anpassung an aktuellen Karten/ Luftbildern gehandhabt wird...

Hier in Brandenburg werden mehr oder weniger regelmäßig die Grenzen an aktueller TK /aktuelles Luftbild angepasst... Diese Änderungen sind hier in den Daten dokumentiert...

Aber selbst wenn es sowas dort auch gibt... solche Grenzen sind gut und gerne mal in Teilen durch Admingrenzen definiert. Da darf es dann wie richtig festgestellt, solche Überschneidungen nicht geben.

Sven

Zur Dopplung: Meine Strategie in Hessen (aus Disk 2021-02-11):
"... in den letzten Wochen die Grenzen der (rund 760) hessischen Naturschutzgebiete (NSG) komplett erfasst.
Landesweit waren geschätzt 70% Ersterfassungen, bei ca. 30% gab es ein Flächen-(und Tag-)update.
Geschätzt 80-90% der (rund 250) vorgefundenen NSG waren handwerklich soweit sauber angelegt, dass dort ein update der Fläche unter Beibehaltung der OSM-id und Versionsgeschichte problemlos möglich war."

Das geht natürlich nur, wenn Mapper sich *jeden einzelnen* Standort vorher anschaut, ob und was denn dort schon vorhanden ist, denn eine Ersterfassung oder (nur) ein Flächenupdate laufen völlig unterschiedlich.
Einfach nur was Neues Abwerfen, und die Vorhandene Arbeit von Anderen samt Versionsgeschichte und OSM-id löschen kam für mich nicht in Frage.

Überhaupt habe ich den Eindruck, dass bei diesem Import so Einiges schief gelaufen ist, Beispiel:
https://www.openstreetmap.org/way/92793 … 2&layers=N
Dort gibt es wohl mehrere Dutzend "Mittelelbe zwischen Mulde und Saale"
allesamt mit verstümmelten Keys

Wenn mir sowas passiert wäre, hätte ich das längst selbst revertiert ...

Klingt für mich auch nach einem Kandidaten für Komplett-Revert mit "kannst es gern nochmal probieren aber bitte dann ordentlich". Wir können dem Mapper ja noch etwas Zeit für eine Stellungnahme geben.

woodpeck wrote:

Wir können dem Mapper ja noch etwas Zeit für eine Stellungnahme geben.

Ich habe ihm vorhin geschrieben, daß er bitte unbedingt hier vorbeischauen soll... Link hatte ich vorher schon geschrieben.

Sven

Hallo,

der Import ist mangelhaft und verstößt trotz vorheriger Ermahnung gegen die Import-Richtlinie:

1. Es werden Keys mit maximal 10 Zeichen Länge verwendet, die in OSM eigentlich länger sind. Das ist ein typisches Phänomen bei Shapefile-Importen mit JOSM, die sich nicht an die Policy halten.
2. Es gibt mehrere Änderungssätze mit 10.000 Objekten, d.h. die hochzuladenden Daten waren mehr als 10.000 Objekte.
3. Der Mapper wurde von mir 23. März auf die Import-Richtlinie hingewiesen und auch daran erinnert, dass ein "local community buy-in" (also Diskusison mit der örtlichen – hier deutsche – Community erforderlich ist).
4. Frederik Ramm hat in der Diskussion auf der Mailingliste Imports, die SR12323 (so heißt der/die Importeur:in) gestartet hat, darum gebeten, den Import auf Talk-de oder hier im Forum zu diskutieren.

Da zwei Ermahnungen nicht ausreichen, habe ich auf dem kurzen Dienstweg bei der DWG um eine 0-Stunden-Sperre gebeten und werde die Importe revertieren, sobald ich dazu Zeit habe. Daher bitte ich darum, die Objekte nicht weiter zu bearbeiten, außer jemand hat vor mir Zeit zum Revertieren. Das Ignorieren der Regeln darf nicht dabei helfen, trotzdem zum Ziel zu kommen.

Viele Grüße

Michael

Nakaner wrote:

3. Der Mapper wurde von mir 23. März auf die Import-Richtlinie hingewiesen und auch daran erinnert, dass ein "local community buy-in" (also Diskusison mit der örtlichen – hier deutsche – Community erforderlich ist).

Danke fürs Revertieren! Die örtliche Community schließt zwar die gesamte deutsche Community ein, ich denke aber schon, dass die Leute vor Ort nochmal ein höheres Gewicht haben sollten.

heey hey,

sorry für die Stille. ich bin gerade am Arbeiten.
Generell habe ich versucht bestehende polygone abzugleichen und nur Anpassungen vorzunehmen wo sich etwas geändert hat. Wahrscheinlich wäre das aber mit mehr Fingerspitzengefühl gegangen und es besser dann per Hand die Bestehenden anzupassen.
Ich habe zwischenzeitlich die beanstandeten Duplikate gelöscht und die leider beim Umwandeln entstandenen verstümmelten keys korrigiert.

Der Import wurde auf der import und DE mailingliste angekündigt und allgemein begrüßt.

Ich wollte am Wocheende noch ein paar multipolygone vereinfachen. Sagt gerne Bescheid, bin neu hier.

Viele Grüße,
Sebastian

Hallo Sebastian,

SR12323 wrote:

Der Import wurde auf der import und DE mailingliste angekündigt und allgemein begrüßt.

Könntest bitte zu deinem Posting im Archiv der Mailingliste Talk-de verlinken? Ich finde es dort nicht. Oder habe ich Tomaten auf den Augen?

Bitte lass deine Arbeiten – auch die Reparaturarbeiten – erst einmal ruhen. Ich möchte in Ruhe über die Sache mit den anderen Mappern diskutieren können und nicht über eine Sache, die schon entschieden ist, pro forma diskutieren.

Viele Grüße

Michael

Hi Michael,

die Mail ging am 23.03 16:18 raus. Ich sehe aber gerade vermutlich an die falsche Adresse (talk-de-request@openstreetmap.org)... 😬

Viele Grüße,
Sebastian

Mann könnte einem Neuling auch einfach bei seinem Import helfen, statt zu lamentieren, diskutieren und revertieren.
Das würde einem Community-Projekt besser zu Gesichte stehen...

Grüße von Lutz

lutz wrote:

Mann könnte einem Neuling auch einfach bei seinem Import helfen

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.

lutz wrote:

Mann könnte einem Neuling auch einfach bei seinem Import helfen, statt zu lamentieren, diskutieren und revertieren.
Das würde einem Community-Projekt besser zu Gesichte stehen...

Grüße von Lutz

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:
- Relationen bei Schutzgebieten sind type=boundary, nicht type=multipolygon, s.o. https://www.openstreetmap.org/relation/12555513
- Es gibt keinen Grund, an jede einfache Schutzgebietsfläche ein sinnfreies type=multipolygon dranzuhängen, beispielsweise https://www.openstreetmap.org/way/927936217
- Die Kennung der Gebiete in Sachsen-Anhalt sollte als ref:DE-ST=* nicht nur ref=* getaggt sein.

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?

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/ … 3/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

SR12323 wrote:

Ich verstehe aber den Punkt des type=boundary für NSGs mit nur einer Fläche und setzte das gerne um.

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

SR12323 wrote:

[...]
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?
[...]

Ja, und wie dies zu lösen ist, ist hier dokumentiert:
https://wiki.openstreetmap.org/wiki/DE: … 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 … _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.

surveyor54 wrote:

[...]
Hatte bereits folgende bearbeitet:

https://www.openstreetmap.org/relation/5166633
[...]

Mmh
https://www.openstreetmap.org/relation/5166633/history
vgl.
https://wiki.openstreetmap.org/wiki/DE: … tzgebieten
"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;-)

Jo Cassel wrote:

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

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

Wäre es dann so richtig?

ref:DE-ST=173

Jo Cassel wrote:

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.

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)

surveyor54 wrote:

[...]

Wäre es dann so richtig?

ref:DE-ST=173

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 … bei-halle/
https://lvwa.themenbrowser.de/UMN_LVWA/ … SG,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...

Jo Cassel wrote:

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.

+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

streckenkundler wrote:

[...]
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" [...]

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 … en-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/ … SG,CO,0387

Jo Cassel wrote:

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

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/#?service … 72D2A2DA0B (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

streckenkundler wrote:

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

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

Jo Cassel wrote:

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

§ 3 (4) Nr. 3 wrote:

der ungestörten natürlichen Eigendynamik der Lebensgemeinschaften der Wälder in der
Kernzone unter Verzicht auf jegliche menschliche Nutzung natürlicher Ressourcen sowie
auf Pflegeeingriffe, um die natürliche Dynamik ökologischer Prozesse durch
eigenständige Sukzession (Prozessschutz) zu ermöglichen und wissenschaftlich zu
dokumentieren (Schutzzone I),

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

streckenkundler wrote:

[...] erfüllt für mich protect_class=1[...]

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

Jo Cassel wrote:

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

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

Prima, ich hatte vor einigen Monaten zusammen mit Kollege seichter eine Tagging-Variante für Kernzonen bei Biosphärenreservaten entwickelt:
https://wiki.openstreetmap.org/wiki/DE: … eutschland

Meine Idee wäre dies analog für NSGs zu übernehmen:
boundary=protected_area
protect_class=1
protection_title=Naturschutzgebiet-Kernzone
short_protection_title=Kernzone

zu den name-Tags in den westlichen Kernzonen habe ich dies gefunden:
https://de.wikipedia.org/wiki/Datei:Dr% … _Karte.jpg
aber besser ohne "NSG"

Gruß Jo

Jo Cassel wrote:

Prima, ich hatte vor einigen Monaten zusammen mit Kollege seichter eine Tagging-Variante für Kernzonen bei Biosphärenreservaten entwickelt:
https://wiki.openstreetmap.org/wiki/DE: … eutschland

Meine Idee wäre dies analog für NSGs zu übernehmen:
boundary=protected_area
protect_class=1
protection_title=Naturschutzgebiet-Kernzone
short_protection_title=Kernzone

zu den name-Tags in den westlichen Kernzonen habe ich dies gefunden:
https://de.wikipedia.org/wiki/Datei:Dr% … _Karte.jpg
aber besser ohne "NSG"

Gruß Jo

Oh, oh, oh, oh... Coole Ecke 🙁

8 (!!) NSG's die aneinandergrenzen...

https://overpass-turbo.eu/s/162a

Sven

streckenkundler wrote:

Oh, oh, oh, oh... Coole Ecke sad

8 (!!) NSG's die aneinandergrenzen...

https://overpass-turbo.eu/s/162a

Sven

...und Bundeslandgrenze... gibt es halberwegs valide Datenquellen die sich vielleicht einer Alkis-Genauigkeit annähern, die für Niedersachsen und/oder Sachsen-Anhalt verwendbar wären?

grübelt Sven...

ersten Teil erst mal lokal gespeichert...

Da noch gedanklich im Thema drin, habe ich mir vorgenommen zumindest in einem Landkreis, dem Altmarkkreis Salzwedel:
https://de.wikipedia.org/wiki/Liste_der … _Salzwedel
die Sache halbwegs in Ordnung zu bringen

Mein kleiner Anfang ist erstmal das Jävenitzer Moor:
https://www.openstreetmap.org/way/927936217/history

Abfrage Stand der Dinge im Landkreis:
http://overpass-turbo.eu/s/16cu

Mit https://www.lvermgeo.sachsen-anhalt.de/ … rmgeo.html komme ich an ALKIS-genaue Gemarkungsgrenzen ran... Das ist schon mal nicht schlecht. Das nützt mir aber herzlich wenig, wenn für einen Gegencheck Niedersachsen seine INSPIRE- klassifizierten Dienste passwortgeschützt haben... 😠 z.B.

https://geoportal.geodaten.niedersachse … 12a0b0e94c

https://www.geobasisdaten.niedersachsen.de/doorman/auth/alkis-vs-au?service=WMS&request=GetCapabilities&Version=1.3.0

das ../auth/.. in der Adresse sagt mir schon, daß Authentifizierung (=Benutzername + Passwort) nötig ist... Och nöö... So nicht.. Irgendwas haben die da nicht verstanden...

Ich will ja nicht danach mappen, ich will mir aber mal ein Urteil erlauben, wie genau die vorhandenen Grenzen sind... Ich vermute aber, auf auf beiden Seiten sind die grottig...

Sven

Inzwischen im Altmarkkreis Salzwedel:

Kalbescher Werder bei Vienau - die NSG-Fläche umfasst als Area jetzt auch die dortige Kernzone:
https://www.openstreetmap.org/way/927936222/history
Die Kernzone (keinen Namen auf die schnelle gefunden):
https://www.openstreetmap.org/way/927936221/history

Ferchauer Forst - Neue Relation type=boundary aus 3 Teilflächen, keine Kernzone vorhanden:
https://www.openstreetmap.org/relation/12588129
Eine der 3 Teiflächen, nur mit dscription-Tag OHNE Schutzgebiets-Tags, da sonst Doppelauswertung:
https://www.openstreetmap.org/way/927936223

Ohreaue - Neue Relation type=boundary aus 2 Teilflächen, keine Kernzone vorhanden:
systematisch wie Ferchauer Forst - liegt wohl auch an der Grenze zu Niedersachsen, habe an den Geometrien nix geändert

Klüdener Pax-Wanneweh - Einfache Area ohne Kernzone - Nur Tag-Korrekturen und Ergänzungen:
https://www.openstreetmap.org/way/927936213/history

Abfrage Stand der Dinge im Landkreis
http://overpass-turbo.eu/s/16dz

Ich habe mal im Salzlandkreis angefangen:

Zickeritzer Busch -- Normale Area, Tagging ergänzt u. berichtigt.
https://www.openstreetmap.org/way/927936088

Sprohne -- Normale Area, Tagging ergänzt u. berichtigt. Grenzt zwar im Norden an die Gemarkungsgrenze von Wedlitz, habe aber an der Geometrie nichts geändert.
https://www.openstreetmap.org/way/927936170

Salzstelle bei Hecklingen -- Normale Area, Tagging ergänzt u. berichtigt.
https://www.openstreetmap.org/way/927936168

Abfrage Salzlandkreis:
https://overpass-turbo.eu/s/16dU
Habe die Farben geändert, da ich Farbenblind bin. 🙁

Vielleicht kann Jo noch mal drüberschauen.

... wenns dich beruhigt: habe mir 4 Areas von dir (kurz) angeschaut, sehen alle prima aus :-)

Sehe 4 Import-Fehler-Typen:
1) einfache Area OHNE Kernzone (Beispiel: Klüdener Pax-Wanneweh) -> nur Tag-Korrektur
2) Mehrflächer OHNE Kernzone (Beispiel: Ferchauer Forst) -> Umbau zur Relation type=boundary mit Tag-Korrektur
3) Area MIT Kernzone(n) (Beispiel: Kalbescher Werder bei Vienau) -> NSG-Geometrie-Änderung mit Tag-Korrektur und Kernzonen-Tagging
4) Mehrflächer MIT Kernzone(n) (Beispiel: Ohre-Drömling) -> Arbeiten aus 2) und 3) notwendig

Immer darauf achten, source:shape=LAU 2019 *nur* an die Import-Flächen zu taggen, auch wenn der Altbestand tagging-Verbessserungen erhält.

Nebenbei schade, dass der Importeur verschwunden ist, und die Dopplungen wohl dabei noch mitgenommen hat,
denn es gibt in JOSM die extrem praktische Funktion "Geometrien ersetzen" - damit wäre ein Flächen-update unter Beibehaltung der Versionsgeschichte und OSM-id möglich gewesen.

Wenn andere am Ball bleiben, mache ich vielleicht auch noch ein wenig weiter ...

Ohre-Drömling...

Ich hab das mal so gemacht, wie ich es eigentlich ideal finden würde (meine subarea-Idee, da Inner hier falsch ist...
CS: https://www.openstreetmap.org/changeset/103073718
Relation: https://www.openstreetmap.org/relation/12555513

Ich hab die Grenze mit der vorhandenen Gemarkungsgrenze = Landesgrenze zu Niedersachsen erst mal nur verklebt. Nach Vergleichen, halte ich da die vorhandenen Admingrenzen für recht gut. an anderen Stellen habe ich die Grenze erst mal gelassen.

Das NSG Kaiserwinkel (https://www.openstreetmap.org/relation/12354457) ragte nach Sachsen-Anhalt hinein. Das hab ichg auch an der Landesgrenze enden lassen...

Ich hab in dem CS nur das bearbeitet.

Sven

streckenkundler wrote:

Ohre-Drömling...

Ich hab das mal so gemacht, wie ich es eigentlich ideal finden würde (meine subarea-Idee, da Inner hier falsch ist...
CS: https://www.openstreetmap.org/changeset/103073718
Relation: https://www.openstreetmap.org/relation/12555513

[...]

... Der ein Mehrflächer ist, wg. der 2. kleinen Fläche im Norden [scheint mir bisher in der Relation zu fehlen].

So wirklich verstehe ich deinen Relations-Bauplan nicht, vermutlich möchtest Du die 3 Kernzonen [gegenwärtig 2 eingebunden]
irgendwie mit an die NSG-Relation hängen.

Den Wunsch kann ich schon verstehen, bin aber skeptisch, ob das so wirklich sinnvoll funktioniert, daher hatte ich es beim "Kalbescher Werder bei Vienau" nicht gemacht, denn es gibt ja ohnehin einen Zusammenhang
- schlicht über die NSG-Außengrenze
- über die gemeinsame, auswertbare Kennung:
http://overpass-turbo.eu/s/16gI

Lasse mich ja gern von gelungenen Lösungen überzeugen, z.Zt ist das aber ehrlich gesagt nicht so ...

Jo Cassel wrote:

... Der ein Mehrflächer ist, wg. der 2. kleinen Fläche im Norden [scheint mir bisher in der Relation zu fehlen].

Ja da fehlt was... so ist das, wenn man außerhalb seines Beritts in unbekanntem Terrain editiert... zwar mit Verordnung aber ohne Karte dazu... Das Online-Portal ist da auch nicht gerade der Bringer(*)...
Diese subarea-Geschichte ist eigentlich eine nette Sache, ich bestehe da aber nicht darauf... Ich hatte das auch mal für die Lieberoser Heide gemacht... Ich schmeiße diese Dinger wieder raus. Das lässt sich auch übers Tagging und die geometrischen Zusammenhänge lösen.

Das Problem, was ich habe... Es ist ja immer nett, eine Verordnung zu haben, ich finde es aber Schei.. wenn man nicht wenigestens die zur Verordnung gehörende Übersichtskarte mitveröffentlicht. Richtig frech findes ich es dann zu sagen: 'Gehen sie doch da und da hin, da können Sie sich die Karten anschauen.'

Ich überarbeite dann mal... 🙂

Sven

(*) Hier OT für OSM aber nicht: fällt dir was beim Copyright bei https://lvwa.themenbrowser.de/UMN_LVWA/ … SG,CO,0387 auf?
Richtig... OSM als Hintergrund genutzt, fehlt aber im Copyright-Laufband in der Fußzeile...

streckenkundler wrote:

Ich überarbeite dann mal...

Ich hab mich dessen mal angenähert... Wikipedia und Wikidata betrachte ich ja al optionale Leistung, nicht Pflicht...
Wikidata nennt einen Ohre-Drömling Nature Park: Hä?? Da haut doch was bei Wikidata nicht hin? Ich habs aber erst mal gesetzt...

Na das wird schon... mit dieser Grenzsituation ist aber nicht einfach... Ich hab erst man nur verklebt, da einfacher und vie Gefahr, Grenzen kaputt zu machen geringer...

Sven

streckenkundler wrote:

Ja da fehlt was... so ist das, wenn man außerhalb seines Beritts in unbekanntem Terrain editiert... zwar mit Verordnung aber ohne Karte dazu... Das Online-Portal ist da auch nicht gerade der Bringer(*)...

Mapper muss halt alle "verdächtigen" Flächen in der Umgebung per click abklappern um die Zusammenhänge zu eruieren - ist in Hessen auch nicht besser gelöst, daher kenne ich das Elend und finde das in Sachsen-Anhalt so schlimm nicht;-)

Rechts in der Legende, und in den Info-Boxen steht dann auch was von OSM - insofern rege ich mich da nicht auf.

Jo Cassel wrote:

Mapper muss halt alle "verdächtigen" Flächen in der Umgebung per click abklappern um die Zusammenhänge zu eruieren - ist in Hessen auch nicht besser gelöst, daher kenne ich das Elend und finde das in Sachsen-Anhalt so schlimm nicht;-)

Ja, aber deswegen auch mein Kommentar zu den fehlenden Übersichtskarten...

Geoportal... das schön klickibunti... aber von der Bedienung wenig intuitiv. Da sind andere wesentlich besser...
NSG's sind hier das beste Beispiel. In der Datenliste erwarte ich hier immer, die Information der Außengrenze und die der Teilflächen separat auswählen zu können... Aber villeicht bin ich GIS- Verwöhnt...

Sven

streckenkundler wrote:

[...]
Wikidata nennt einen Ohre-Drömling Nature Park: Hä?? Da haut doch was bei Wikidata nicht hin? Ich habs aber erst mal gesetzt...
[...]

Guckst Du hier - wikidata ist nicht Gotteswerk, sondern user-driven-content da kann halt auch jeder Mist (ein)bauen
https://www.wikidata.org/w/index.php?ti … =874851191
passt aber.

Habe eben im Salzlandkreis bei einem von surveyor54 vor 2 Tagen bearbeiteten Problem 4 - Relation aus 2 outer + Kernzonen.
noch eine von ihm wohl übersehene Geometriedopplung entfernt, die Grundstruktur war aber völlig ok.

- Das Gesamt NSG "Hakel"
https://www.openstreetmap.org/relation/12555531
- Die 2 Kernzonen
https://www.openstreetmap.org/way/927936172
https://www.openstreetmap.org/way/927936173

Nachtrag:
Da mit dem "Hakel" die Problemfälle 1-4 mit korrigierten Beispielen erfasst sind,
plane ich dies
https://wiki.openstreetmap.org/w/index. … id=2143822

dort
https://wiki.openstreetmap.org/wiki/Imp … utzgebiete
einzufügen
[warum sich ein 2021-04 erfolgter Import auf einen 2016 erfolgten Wiki-Eintrag bezieht ist mir aber allerdings OSM-schleierhaft]

Habe noch eine handvoll NSG bearbeitet,
surveyor54 macht sich dankenswerterweise großflächig an die notwendigen Nacharbeiten, und hat mich dazu wg. einem Sonderfall per PN um Rat gefragt:
https://lvwa.themenbrowser.de/UMN_LVWA/ … SG,CO,0191
ist vollflächig Kernzone bzw. Totalreservat

Würde dieses NSG wie ein übliches Area-NSG erfassen, aber ausnahmsweise mit
protect_class=1 dies aber unbedingt erläutern:
note=Dieses NSG ist vollflächig Totalreservat, daher ausnahmsweise protect_class=1 statt 4

Jo Cassel wrote:

Würde dieses NSG wie ein übliches Area-NSG erfassen, aber ausnahmsweise mit
protect_class=1 dies aber unbedingt erläutern:
note=Dieses NSG ist vollflächig Totalreservat, daher ausnahmsweise protect_class=1 statt 4

+1
Beim NSG Abramka hier im Spreewald hab ich es auch so gemacht. Das ist von vorn herein komplett als Naturentwicklungsgebiet (=Totalreservat) ausgewiesen worden. Ich hab hier in Brandenburg noch mehr solcher Spezialitäten, wo eine Fläche 2 NSG-Ausweisungen hat... hatte ich mal erläutert, warum.

Sven

Jo Cassel wrote:

Habe noch eine handvoll NSG bearbeitet,
surveyor54 macht sich dankenswerterweise großflächig an die notwendigen Nacharbeiten, und hat mich dazu wg. einem Sonderfall per PN um Rat gefragt:
https://lvwa.themenbrowser.de/UMN_LVWA/ … SG,CO,0191
ist vollflächig Kernzone bzw. Totalreservat

Würde dieses NSG wie ein übliches Area-NSG erfassen, aber ausnahmsweise mit
protect_class=1 dies aber unbedingt erläutern:
note=Dieses NSG ist vollflächig Totalreservat, daher ausnahmsweise protect_class=1 statt 4

Danke 🙂