Ich habe mal gehört, dass Wege maximal aus 2000 Punkten bestehen können. Hat man nun Objekte mit mehr als 2000 Punkten z.B. Staatsgrenzen, dann fasst man die einzelnen Wege zu einer Relation zusammen. Jetzt ist mir aufgefallen, dass es Relationen gibt, bei denen die Summe der Punkte der Mitglieder weit unter 2000 liegt. Wenn man nun die Mitglieder zu einem Weg verbinden könnte, dann hätte man eine Relation mit einem Mitglied. Wenn man dann noch den type löscht, bleibt es aber immer noch eine Relation. Jetzt stellt sich mir die Frage, ob das überhaupt geht, oder ob das überhaupt nicht vorgersehen ist? Die Relation zu löschen und als Weg neu zu erstellen ist keine Option, da dann auch die ganze Historie gelöscht wird.
Relationen sind Sammlungen von Wegen. Beide existieren parallel. Es ist nicht möglich aus einer Relation einen Weg zu machen.
Es ist auch sinnvoll in einer Relation mehrere Wege zu haben, wenn die Wege unterschiedlicher Klasse und Güte sind. In einer Wander-Relation kann beispielsweise ein Schotterweg und ein Asphaltweg sein.
Danke für die schnelle und klare Antwort. Dein Beispiel mit den Wanderwegen leuchtet ein. Ich bin auf die Problematik gestoßen, als ich die Geometrie von Schutzgebietsgrenzen mit Daten aus einem Shapefile ersetzen wollte. Als konkretes Beispiel: Das Nationale Natur Monument Weltenburger Enge besteht aus 4 Mitgliedern mit 51, 245, 27 und 206 Punkten bzw. Knoten. Das Element aus dem Shapefile hat ca. 525 Punkte. Mit JOSM kann ich aber nur die Geometrie von einem Element und nicht von 4 Elementen ersetzen.
1 Like
Hei,
…das ist bei allen ways so. Das sind die Objekte, die im OSM-Inspektor als “Long ways” gekennzeichnet sind, wobei hier die Warnung deutlich früher erscheint… bei 1500/1600 Punkten pro Linie oder so, die Grenze kenne ich nicht.
Ja bleibt es. Es sind unterschidliche Objekttypen mit jeweils einem eigenen OSM-internen Nummernraum (bezigen auf Punkt, way und Relation). Mit löschen von type=* bleibt es eine Relation, nur ist diese dann unbestimmt.
Jein… Die Historie verschwindet nicht, sie bleibt im Changeset erhalten… (es sei denn, die DWG entfernt die Daten direkt, was aber nur bei schweren Urheberrechtsverstößen geschieht)
Nun, man kann aber auch nicht immer alles erhalten… mit ein bisschen Nachdenken, was man tut, kann man aber es reichlich minimieren. von anderen erstellte Objekte zu löschen.
Allgemein.
Unterm Strich kennt OSM direkt nur zwei echte Geodatentypen:
- Punkte
- Linien
Dann in Erweiterung:
-
geschlossene Linien, also deren Start- und Endkoordinate gleich sind, werden abhängig von der für OSM festgelegten Haupteigenschschaft als Fläche interpretiert (=einfache Fläche, ohne Löcher, z.B. landuse=*).
-
Relationen…
Richtig. Eine Relation ist im Prinzip eine Sammlung aus meinen hier genannten Nummern 1, 2, und 3, je nach Ausprägung.
Sowohl Wanderwege, als auch ein Wald mit einem innen liegenden See sind üblicherweise Relationen.
->Wanderwege als Sammlung aller, zum Wanderweg von A nach B gehörenden highway-Elemente → üblicherweise type=route
→ See im Wald: beide Elemente in einer Relation mit type=multipolygon, die äußere Waldfläche bekommt die Rolle outer, der innen liegende See, die Rolle inner. Hier kann es nun aber sein, daß z.B. die Summe Stützpunkte des outer-Segments die 2000-Punkte-Grenze knackt… dann hat man eben zwei Outer-Teillinien… Wenn man das macht, hat immernich zu mindestens eine der beiden Linien die Historie.
Praktisches Beispiel. Insel im Senftenberger See (=Innenkippe eines ehemaligen Braunkohlentagebaus): Outer besteht aus zwei Teilen, da sonst die 2000-Punkte-Grenze erreicht wird.
Allgemein aber können für mich Relationen mit >1 outer überwiegend vermieden werden.
Kurzer Weg: JOSM → Way in neue Relation → Eigenschaften des way an die Relation → Way detailieren, oder wenn nötig splitten
Folge: wenn eine neue Relation mit zwei Outer-Linien sich daraus ergibt, hat eine der beiden Outer-Linien (einen Teil der)die Historie. Der Rest ist im Changeset.
Ich bin Müde…
Sven
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 | OpenStreetMap
Ist ein Teil (way) des Outers Mitglied in zwei (oder mehr) verschieden Relationen lässt sich das nicht mehr ohne weiteres auf einen outer reduzieren.
1 Like
Oh… konkretes Beispiel… 
Mein Weg wäre…
so lassen und Finger weg… Weil:
- es gibt das Nationales Naturmonument Weltenburger Enge als protect_class=3
- es gibt das NSG Weltenburger Enge als protect_class=4
…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 …
1 Like
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.
1 Like
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.
1 Like
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
1 Like
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