Oh… konkretes Beispiel… 
Mein Weg wäre…
so lassen und Finger weg… Weil:
…jeweils in einer unterschiedlichen Ausdehnung, aber teilweise unter Nutzung der selben Grenzsegmente.
Bei Schutzgebietsgrenzen ist es häufig anzutreffen, daß es eine Mehrfachnutzung eines Liniensegmentes für unterschiedliche Schutzgebietskategorien gibt,
Sven
@Mammi71 =die selben Gedanken …
Man könnte natürlich die beiden betreffenden Segmente aus einer der beiden Relationen herausnehmen, und für die andere Relation separat neu zeichnen (deckungsgleich). Beide Relationen sollten dann jeweils auf einen outer reduzierbar sein. Dann kann man die jeweiligen tags der Relation auf den outer umhängen und die Relation selbst löschen.
PS: das bekommt man sogar mit dem iD hin … Nur ob irgendwo die Historie erhalten belibt kann ich nicht garantieren.
Das ist richtig, das eine ist das Naturschutzgebiet und das andere das Nationale Natur Monument.Einige Teile sind Mitglieder von beiden Relationen. Das Naturschutzgebiet muss auch noch überarbeitet werden, da hier die Grenzen nicht stimmen, da es das Naturschutzgebiet Hirschberg Altmühlleiten überdeckt
Vielleicht ist es ja doch besser die Finger davon zu lassen.
=verkleben…
Ja, das sind wir wieder bei der alten Grenz-Disskussion, bei der ich mir in meinen Jahren bei OSM noch immer nicht abschließend sicher bin…
Was verwendet man, wenn eine Schutzgebietsgrenze laut textlicher Grenzbeschreibung in Teilen durch eine administrative Grenze definiert ist? Das geometrische Grenzsegment selbst oder nur die Lage dieser Grenze in Form von Verkleben?
Vergleich… Bei Admin-Grenzen haben wir Liniensegmente, die wir je nach Bedarf zu unterschiedlichen admin-Relationen zusammenbauen.
Warum nicht auch bei solchen Schutzgebietsgrenzen, wenn diese entsprechend dediniert sind?
Sven
Ah…
…da steckt Erfassen von Naturwaldreservaten - #14 by whb und insbesondere Erfassen von Naturwaldreservaten - #16 by Digitize_the_Planet und die Schutzgebietsdatenfreigabe bei Euch dahinter…
Das dürfte auf längere Zeit allgemein ein Dauerthema werden, auch in anderen Bundesländern… rieche ich so…
Auch wenn es möglich wäre, würde ich überwiegend von einem direkten Datenimport abraten (*) und sich stattdessen zunächst und en Originaldaten mit den möglichen Kartenhintergründen anschauen, wie die Grenzziehung gemeint war.
Weil: die der Öffentlichkeit zur Verfügung stehenden Grenzen sind immer generalisiert, üblicherweise auf DTK10 oder so angepasst. Die veröffentlichten Grenzen sind niemals rechtsverbindlich. Rechtsverbindlich sind nur die, der Verordnung beiliegenden Karten (Genauigkeit auf Liegenschaftskarten), die im jeweiligen Schutzgebietskataster abgelegt sind.
Darum meine ich, daß wir dann diese Grenzen an unsere Daten anpassen können, in Annäherung an die veröffentlichten Daten, so gut es geht…
(*) überwiedend deshalb, weil es mitunter NSG’s gibt die nicht mit Erfassung vor Ort oder im Minimum anhand einer Verordnung erfassbar sind. Beispiel aus Brandenburg: NSG Stepenitz Das ginge nur über Import.
Sven
Ich würde mal so sagen: Es ist in der Regel nicht sinnvoll, wenn die Relation sinnvoll angelegt wurde. Ansonsten kann man sich natürlich vorstellen, dass eine Insel im Stausee verschwindet. Dann braucht man keine Multipolygon-Relation mehr und man kann diese löschen und den Stausee wieder als normalen, geschlossenen Weg pflegen.
War ich damals, in meinen Anfängen auch sehr bedacht. Es stellt sich hier aber vorallem die Frage der Praktikabilität. Klar ist man sollte die Historie nicht unnötig zerstören. Die Historie ist in OSM in den Changesets enthalten. Nur um der Historie Willen würde ich jedenfalls keine suboptimalen Konstrukte nutzen.
Verkleben von Schutzgebietsgrenzen mit Schutzgebietsgrenzen find ich noch ok, aber dass ist ein anderes Thema. Die Eingangsfrage wurde bereits mit dem ersten Posting beantwortet. Für mich zwar unbefriedigend, aber iss halt so. Ich werde das Thema auf gelöst setzen und bedanke mich für eure Antworten.
Peter
das war mein Plan, nur ohne die Relation zu löschen 
nur zur Info:
konnte die Finger doch nicht davon lassen, habe mich aber der Situation angepasst. Habe eine Linie der Relation NSG Weltenburger Enge an 2 Stellen aufgeteilt und aus der Relation genommen. Mit dieser Linie und einer extrahierten Linie aus dem Shapefile habe ich eine neue Relation für das NSG Hirschberg und Altmühlleiten erstellt. Die extrahierte Linie aus dem Shapefile habe ich dann noch zur Relation NSG Weltenburger Enge hinzugefügt. Die Grenzen vom Nationalen Naturmonument Weltenburger Enge habe ich unberührt gelassen. Hoffe ich habe keine Fehler gemacht.
So sieht es mit overpassTurbo aus: https://overpass-turbo.eu/s/1nWw Nur protect_class=3 ist im style nicht eingebaut… Sieht aus der Ferne gut aus.
Sven
coole Abfrage 
Unterm Strich kennt OSM direkt nur zwei echte Geodatentypen:
- Punkte
- Linien
Nur die Punkte haben einen direkten Ortsbezug, die ways sind genau wie die Relationen abstrakt.
Das Problem ist aber auch, dass es
a) zwei Schutzgebiete Weltenburger Enge gibt und
b) diese sich zwei Abschnitte als outer-way teilen:
Way: 1109162058 | OpenStreetMap
und
Way: 1109162060 | OpenStreetMapIst ein Teil (way) des Outers Mitglied in zwei (oder mehr) verschieden Relationen lässt sich das nicht mehr ohne weiteres auf einen outer reduzieren.
wenn die beiden Gebiete unabhängig voneinander sind ist das wirklich ein Problem, wenn es aber eine gemeinsame Grenze ist (bei Nachbarländern die ihre Grenzen anerkennen ist das z.B. der Fall, oder bei unteren Verwaltungseinheiten erst recht, weil es da kein Niemandsland gibt) , dann ist das kein Problem sondern ein feature.
Ah… Nun… Aus reiner Neugier würde mich das irgendwie doch interessieren, wie die Daten direkt und real abgelegt sind. Auch wenn wir das Thema irgendwann schon mal im alten Forum hatten… OGC-konform ist OSM an der Stelle nicht… das wird wohl noch ein paar Jahrzehnte dauern…
Sven
Naja, die Ways bestehen einfach nur aus einer (reihenfolgeabhängigen) Liste von Node ids, wie hier an diesem Haus zu sehen: https://www.openstreetmap.org/api/0.6/way/1115294533
Die Geometrie des Hauses ist damit nur indirekt festgelegt, die Koordinaten finden sich entsprechend in den Nodes: https://api.openstreetmap.org/api/0.6/nodes?nodes=10200234932,10200234933,10200234934,10200234935 - die Ausgabe entspricht allen Nodes des Gebäudes mit den jeweiligen lat/lon Werten.
OGC kennt diese Indirektion nicht, dort die Koordinaten direkt im Linestring mit drin.
Das ganze ist in OSM in 2022 das absolute Hype-Thema. Am besten mal hier etwas reinschauen: Foundation/AGM2022/Election to Board/Answers and manifestos/Q07 OSMF and Technical direction - OpenStreetMap Wiki
@mmd
Dickes Danke…
Von der realen Datenverwendung haben wir ja (indirekt) bereits weitestgehend sowas…
Unsere MP’s mit Wald=outer und See=inner sind eigentlich irgendwie indirekt echte OGC-Polygone, nur daß diese “von hinten durch die Brust ins Auge” anders verbastelt sind…
Da hier OT werdend, höre ich auf… 
Schönes Wochenende,
Sven
Weil Schutzgebiete meist keine gemeinsamen Segmente mit anderen Gebieten/Relationen haben.
Bei admin-Grenzen ist das fast immer der Fall, oft sogar mehrfach gestapelt (…, Land, Bezirk, Kreis, Gemeinde, Teilort, …), daher diese Sonderbehandlung.
Darum meine ich, daß wir dann diese Grenzen an unsere Daten anpassen können, in Annäherung an die veröffentlichten Daten, so gut es geht…
Volle Zustimmung. Es bringt nichts Koordinaten/Geometrien zu importieren, vielmehr muss idealerweise die Lage zu den übrigen Daten bestmöglich passen.
Ich will (Thema ist alt und nicht das erste mal disskutiert) darauf hinaus… Schutzgebietsgrenzen werden mitunter in Teilen:
Darauf stößt man entweder durch die Verordnung selbst oder durch visuelle Betrachtung der Schutzgebietsgrenze selbst im Vergleich zu jeglichen admin-Grenzen, auch Flure und Gemarkungen, der anderen zeitgenössischen Quellen.
Vergleiche textliche Beschreibung der Grenzen hier im BR Spreewald
Das veranlasst mich dazu, in den entsprechenden Abschnitten:
Östliches Ufer des Lehder Grabens in nördliche Richtung von der Mündung Eschenfließ bis zur Kreuzung mit dem Bürgerfließ,
südliches Ufer des Bürgerfließes in nordöstliche Richtung bis zur Mündung Burg-Lübbener Kanal,
südliches Ufer des Burg-Lübbener Kanals in östliche Richtung bis zur Mündung Tschapek-Kanal,
westliches Ufer des Tschapek-Kanals in südliche Richtung bis zur Mündung Hauptspree,
nördliches Ufer der Hauptspree in westliche Richtung bis zur Mündung Eschenfließ,
östliches bzw. nördliches Ufer des Eschenfließes bis zur Mündung Lehder Graben.
anzunehmen, daß eben jene Uferkanten Wasser <->Wald die Schutzgebietsgrenze ist. Folge: würde sich die Uferkante verändern, verändert sich die Schutzgebietsgrenze.
Für OSM: heißt das für mich: hier muß zuerst eine detailierte Erfassung der Landschaft erfolgen und bei Vorhandensein, ist folglich die Schutzgebietsgrenze entsprechend mit der landschaftlichen Grenze zu “verkleben”…
Ich gebe zu, das ist eher sehr selten anzutrefen, hier bei mit im Spreewald ist es aber nun mal so…
Ich finde keine andere Lösung, die vorgefundenen Daten in OSM umzusetzen.
Sven