Wir haben im Herbst letzten Jahres die NSG’s (Shapefiles)in Bayern nach einem Schema eingepflegt.
https://wiki.openstreetmap.org/wiki/Import/Bayern_Naturschutzgebiete
Dieses NSG Relation: Trockenhänge bei Böttigheim (16381901) | OpenStreetMap ist in fünf Teile aufgeteilt mit eigenen Nummern in Bayern und deshalb wurde jeder Teil für sich eingepflegt.
Sollte man dafür eine Relation anlegen?
Fragende Grüße
surveyor54
Hier hat sich wirklich ein angesehener und vielgeschätzter Mapper Gedanken gemacht und eine unnötige Redundanz beseitigt. Ich finde, die Relation sollte beibehalten werden!
LG Olaf
Ich bin bei sowas gespaltener Meinung. Auswertetechnisch ist das nicht unbedingt nötig, da man bei hinreichender Erfassung auch ohne Relation an alle Daten rankommt: overpass turbo
Ich hab das aber auch schon gemacht: z.B. NSG Mahlheide
Ich hätte bei NSG-Relationen aber auch den Anspruch, wenn das NSG eine Totalreservatsfläche beinhaltet, diese mit in der relation zu haben: z.B. mit der Rolle subarea.
Ich habe hier mittlerweile die Situation, daß ich NSG mit Totalreservat als Teilfläche des NSG habe und für die NSG-Fläche, die kein Totalreservat ist, ein eigenes drüberliegenendes Naturentwicklungs-Gebiet als eigenständiges NSG… (eine kleine wendebedingte Spezialität) =also 2 NSG’s übereinander!
Sven
Nachtrag:
ich hab “meine” Mahlheide mal mit Trockenhänge bei Böttigheim verglichen.
Bei Schutzgebiete in Deutschland haben die Teilflächen der Trockenhänge bei Böttigheim tatsächllich unterschiedliche CDDA-Codes: z.B. 389985, 349943… Die Mahlheide hier für beide Teilflächen nur einen Code: 164543
CDDA-Code=WDPA-ID
Aber https://www.protectedplanet.net kennt bei Trockenhänge bei Böttigheim die Teilflächen einzeln und dann nochmal als Gesamt-NSG:
Das NSG ist also da doppelt drin!
Genau genommen wäres es dann: an die Einzelflächen die ID’s der Teilflächen, an die Gesamt-Relation die ID der Gesamt-Relation… Aber irgendwie scheint da was beim Datenimprt schief gelaufen zu sein…
ganz anders…
Das Gebiet mit 555521408 ist das FFH-Gebiet: also FFH-Gebiet Naturschutzgebiet 'Trockenhänge bei Böttigheim'
Die Teilflächen mit ihren unterschiedlichen Nummern das NSG (als Einzelflächen, keine Gesamt-Relation).
Umgesetzt nach OSM:
An die Einzelflächen: protect_class=4, an die Gesamt-Relation protect_class=97 Siehe: DE:Key:protect_class – OpenStreetMap Wiki
Die WDPA-ID’s beachten.
Ich bin da aber auch auf einen möglichen Fehler in der Erfassung gestoßen: ältere Gebiete mit protect_class=4 dürften keinen WDPA-ID haben, der mit 555* beginnt. Bei Namensgleichheit des Gebietes muß man das zu mindestend im Hinterkopf haben.
Sven
Bitte hier nichts durcheinanderbringen! Das FFH-Gebiet hat eine völlig andere, abweichende Geometrie als das besprochene NSG. (rosarot=NSG, braun=FFH; Grafik aus BayernAtlas - der Kartenviewer des Freistaates Bayern)
Wollen wir hier wirklich alle möglichen Schutzgebiete (FFH, LSG, Vogelschutzgebiet, Biotop, Naturdenkmal, etc…) mappen, könnte das Kartenbild etwas, nun ja, unübersichtlich werden.
LG Olaf
Ja… schau dir unter Protected Planet das Ganze an. Das angesprochene Gebiet ist als NSG in Teilflächen mit eigenen IDs erfasst. Eine Relation über alles ist hier fürs NSG falsch. Anders hingegen für das FHH-Gebiet!
Edit: Und auch der BayernAtlas hat für NSG’s Teilflächen-IDs… und oh Wunder: sogar bei den FFH-Gebieten…
Haben wir sowieso schon drin, es wird zum Glück nur nicht alles gerendert…
…und was Aktualisierungen von solchen Grenzgeometrien anbelangt, könnte ich dir einiges erzählen. Es ist Teil meiner beruflichen Tätigkeit, diese Änderungen zu beobachten und aktualisierte Daten bereitzustellen.
Sven
Die Naturschutzgebiete werden m.E. von der bayerischen Naturschutzverwaltung per Verordnung ausgewiesen, daher ist das auch die Quelle aus erster Hand. Und die weist das Naturschutzgebiet „Trockenhänge bei Böttigheim“ und nicht die sechs Naturschutzgebiete „Trockenhänge bei Böttigheim“ aus (Link).
Jo… das hat sich auch nie geändert: Die sechs Sprengel der NSG-Relation haben diese IDs immer noch (vgl. 1111778832 ff.)
Nö. Und irgendwie vermisse ich hier das schlagkräftige Argument.
Es gibt 1 NSG mit 1 Namen, durch 1 Verordnung und es hat halt sechs Teilflächen. Perfekt, um eine Relation zu basteln
LG Olaf
Für mich persönlich und ob meines langjährigem beruflichen Wissens kommen wir hier in den Bereich Geodatentechnik (*) rein…
An der Stelle hast du recht:
Warum aber gerade die Bayern so preußisch waren selbst für Teilflächen eigene ID’s zu vergeben, da mußt du diejenigen die das verzapft haben. Entschuldigung für diese kleine Spitze, die drängte sich aber auf.
Die Daten sind mit Teilflächen-ID’s bereitgestellt und verarbeitet worden. Protected Planet (also ref:WDPA = CDDA-Code) stellen bei dem angefragten Gebiet bei NSG unterschiedliche ID’s bereit.
Ich sag dann nur noch: dann ist das so. Abfragetechnisch ist das dann kein Problem. Problematisch könnte es erst werden, wenn man mehrere Datentypen (way, relation) mit dem selben Inhalt hat.
Bei meinem Beispiel hier in Brandenburg ist es hingegen genau so, wie du es schreibst: 1 NSG mit 1 Namen, durch 1 Verordnung, es hat N-Teilflächen aber nur eine nach außen repräsentierte Geometrie mit der entsprechenden Anzahl der Teilflächen. Das kannst du dir im Osiris anschauen (Ebenen bei Schutzgebiete und Maßnahmenumsetzung ein- und ausschalten und vergleichend abfragen) [Leider bieten allgemein diese Dienste nur äußerst selten einen Direktlink zu einer bestimmten Stelle an…]
(*) Geodatentechnik: 2 Stichworte:
…Jetzt kannst du Raten, wie diese Daten an Dritte bereitgestellt wurden…
Richtig: für Protected Planet die NSG als SinglePart, die FFH-Gebiete als Multipart…
Wir hier in OSM müssen aus dieser ganzen Geschichte das beste draus machen, da OSM keine OGC-konforme Datenstruktur hat. Es ist immer eine Abwägung zwischen dessem was man vorfindet und dem, was die OSM-Datenstuktur bereitstellen kann… Das ist entweder way oder relation oder Relation aus ways… Es ist eine Gratwanderung!
Eine allgemeingültige Lösung gibt es nicht.
Sven
OSM hat nicht primär die Aufgabe, ein Backup für das amtliche Schutzgebietskataster darzustellen. Ich würde auch gerade deshalb mal vorsichtig in Betracht ziehen, diesen ganzen ID-Nummernzirkus nicht ganz so hoch zu priorisieren. Aber gerade, weil ich es vorschlage, wird es vermutlich heftig Gegenwind geben 
Ich vermute mal - da ich fachlich aus einem ähnlichen Metier stamme - dass hier ein gewisses Faible für amtliche Geodaten vorliegt. Das führt dann dazu, dass einfach Shapes der Naturschutzverwaltung 1:1 hergenommen und in die OSM reingeballert werden. In BW ist es zum Beispiel so, dass NSGs von den höheren Naturschutzbehörden (Regierungspräsidien) verordnet werden, was dazu führt, dass manche NSG im Schwarzwald auf der Bezirksgrenze Karlsruhe/Freiburg als zwei verschiedene Objekte in den LUBW-Daten existieren: Aber mit ein und dem selben Namen und auch der Verordnungstext ist der selbe. Und witzigerweise sind die mal so, mal so gemappt.
In der Praxis hat das z.B. für den Wanderer aber keine Relevanz, in welchem ID-Part des NSGs er sich gerade befindet. Wozu sollte man hier also eine Redundanz aufblähen und alles doppelt taggen? Ich finde gerade auch aus einer geoinformatikbezogenen Sichtweise diese unnötigen Doppelt-Dreifach-Sechsfach-Taggings vollkommen absurd. Es ist 1 Naturschutzgebiet, also hat es auch als ein zusammengefasstes Objekt zu existieren.
Noch was: Wo kämen wir denn hin, alles, was in amtlichen Geodaten eine Nummer hat, auch mappen zu wollen? Ich will keine OSM erleben, in der angefangen wird, einzelne Flurstücke zu mappen. Da wär der Olaf raus!
LG Olaf
PS: Vielleicht können sich hier noch ein paar sachkundige Mapper aus dem weiß-blauen Dahoam einbringen? Das wäre auf jeden Fall ein sehr wertvoller Beitrag!
richtig - dann die Teilflächen aber auch bitte eigenschaftslos, will sagen nur note oder description-Tags, und nicht so
Way: 1111778837 | OpenStreetMap
Ansonsten produziert Mapper in OSM ggf. die Doppelauswertungen, die Du gerade bei den Behörden kritisierst.
…andererseits hat Bayern so wie ich das sehe, für jede Teilfläche eines NSG (und auch FFH-Gebiet) eine eigene (Teilflächen-)ID. Wenn man die Daten vollstädig und hinreichend korrekt nach OSM umsetzen will, darf keine Relation angelegt werden! Das ist im Moment mein Fazit. Ansonsten würde eine mögliche vollständige Verlinkung über ref nicht nehr möglich sein, und das ist ja der Grund, warum wir ref in seinen unterschiedlichen Ausbildungsformen erfassen.
Warum sie mit Teilflächen-ID’s arbeiten, da müsste die datenhaltende Stelle gefragt werden.
Für mich kommt man aus der Kiste nur raus, wenn Bayern hier aus Teilflächen-ID’s verzichtet, zu einer Multipart-Geometrie wechselt und einen neuen Datensatz bereitstellt.
Hätte ich die ID hier auch noch rausgeschmissen, hätten mich die Amtliche-Geodaten-Mapper, die OSM als Kopie eines Geoportals der Landesnaturschutzverwaltung verstehen, hier noch vollends gegrillt 
LG Olaf
Naja, ich sach mal (beispielhaft s.o.) sowas wie
ref:DE-BY=NSG-00742.06
richtet wohl keinen “Datenschaden” an könnte man aber imho auch unter note ablegen: “Teilfläche mit eigener behördlicher Kennung xxx des NSG y”
bei jedesmal identisches wikidata an Teilflächen - oweia, das würde ich nie so machen
und grundsätzlich
ref:WDPA ist nice to have - aber auch nicht mehr
Endlich spricht es auch mal jemand anderes aus, weil
LG Olaf
Die Datenbasis ist für mich schon schräg…
Ja, das ist auch meine Befürchtung ob des jetzigen Zustandes 
Schön ist das nicht… Das wertet keiner aus.
Die refs sind immer nice to have, Wenn man davon ausgehen kann, daß diese fix sind, kann man schöne Sachen damit veranstalten. Zum Beispiel die Wikipedia und die Wikidata-Einträge sind eigentlich auch nichts weiter als verkappte refs… Es sind Angaben, um eine Querverlinkung und Nutzung von Drittquellen zu ermöglichen.
Sven
wir versuchen ja hier, die Wirklichkeit abzubilden, und nicht, sie so anzupassen, dass wir sie einfacher mappen können, oder?
Tja, bei dem hier in Frage stehenden NSG kann man es so sehen, daß das NSG durch 6 Geometrien repräsentiert wird und nicht noch durch eine zusätzliche Relation, die bei einer Datenauswertung alles unnötig kompliziert macht…
die NSG werden ja auch textlich beschrieben, es sollte möglich sein, ein Objekt zu machen, das dieser Beschreibung entspricht. “Doppelt” sollte man die Dinge nicht mappen. Wenn es sich um Teile handelt, dann sollten diese nicht gleich gemappt werden als wenn es unabhängige für sich stehende Gebiete wären. Die Relation braucht man ggf., um Gebiete als “ein” Gebiet zu mappen, wo es sich um ein Gebiet aus mehreren unverbundenen Teilflächen handelt.
Also in Wirklichkeit handelt es sich um 1 NSG mit 6 Teilflächen:
V e r o r d n u n g:
§ 1
Schutzgegenstand
Die bei Böttigheim im Landkreis Würzburg gelegenen, überwiegend süd- und westexponierten Hangbereiche werden unter der Bezeichnung „Trockenhänge bei Böttigheim“ in den in § 2 bezeichneten Grenzen als Naturschutzgebiet geschützt. Das Naturschutzgebiet besteht aus 6 Teilflächen.
Aus: Verordnung über das Naturschutzgebiet „Trockenhänge bei Böttigheim“. Vom 26. April 2007 Nr. 55.1-8622.01-3/05, Herausgegeben von der Regierung von Unterfranken in Würzburg [1]
Ich komm immer noch nicht drauf, wie man hier jedwedes Grundlagenwissen über Datenredundanz über Bord werfen kann und literally 6 nahezu gleichgetaggte NSG-Einzelobjekte in die OSM kloppen will.
LG Olaf
So, wie es derzeit erfasst ist, also eine Relation type=boundary, die das NSG als ganzes repräsentiert, mit 6 separaten outer-Wegen, die dann die entsprechenden ref:*-Tags haben, sieht es für mich korrekt aus. Wo genau soll denn jetzt das Problem liegen? Irgendwie erschließt es sich mir nicht. Genau so würde ich es auch machen 
