Multiverschachtelte landuse-Flächen - ein Kooperations-Projekt?

Ich habe damit begonnen das LSG zu überprüfen und das tagging zu erweitern.
Das gesamte Landschaftsschutzgebiet ist in mehrere kleine Flächen und einige große Flächen mit einem Loch (donut-Form) oder mehreren Löchern (Brezel-Form) aufgeteilt. Bisher habe ich im südlichen Teil die Grenzen nach Bayern-Atlas überprüft, die sind sehr genau eingezeichnet. Ich musste nur bestehende Grenzstücke miteinander verbinden, damit die Flächen des LSG korrekt eingetragen sind.

Probleme macht mir:
Diese große Fläche

mit diesem Loch um eine Kleingartensiedlung

Mein Versuch (bzw. schon der meines Vorgängers) hat auch die Siedlung zum LSG gemacht … das kann nicht passen.

ich habe schon länger den iD nicht mehr benutzt, aber zumindest früher war es ziemlich unklar und automatisch, was er mit Multipolygonen gemacht hat. In diesem Fall wird man vermutlich ein Multipolygon benötigen, weil ein Loch in eine Fläche geschnitten werden soll, und die Grenzen der Flächen nicht in unserer Macht stehen (bei einem “normalen” Wald kann man einfach selbst festlegen, wo man ihn teilen will, bei einem gesetzlich vorgegeben Schutzgebiet muss man das nehmen, was “von oben” verordnet wurde). Mein Vorschlag wäre, sich das in JOSM anzusehen.

Noch ein Problemfall:
Ich wollte zwei Grenzlinien eines sehr komplexen Teils des LSG miteinander verbinden. Das ging nicht, mit der Fehlermeldung, es würden zu viele Punkte im way entstehen.
Wie ist das lösbar? Ob es ausreicht Punkte zu löschen ist fraglich (ich habe 2000 als Begrenzung in Erinnerung, die Teil-Linien haben schon 1803 und 1828 Knoten).
Hier die beiden Linien, die es bisher gibt und die eigentlich zusammenhängen müssten:

https://www.openstreetmap.org/way/357151252/history#map=13/49.3684/11.3273

https://www.openstreetmap.org/way/357151452/history

Es gibt zwar einige Engstellen, an denen die Fläche teilbar wäre, im Bayernatlas ist dieses Teil des LSG aber ein Objekt:

Damit ihr durchblickt: Die Grenzen (dieses Teilgebiets des LSG-00587.01) sind
im Norden die Nordkante der A6
im Osten bei Hagenhausen
im Süden am Nordhang des Dillberges (nördlich von Buch, der kleine Fetzen westlich von Buch ist als eigene Fläche eingezeichnet)
im Westen östlich von Schwarzenbruck (süd-westlich von Schwarzenbruck gibt es noch eine kleine Fläche, die auch separat gezeichnet ist)

Wenn die Außenlinie geschlossen ist, wartet schon die nächste Herausforderung: diese Fläche hat viele Löcher, also wieder Multipolygon-Verdacht

Was war denn an dem NSG nicht in Ordnung?
Jetzt ist das Tagging jedenfalls nicht mehr korrekt (Eigenschaften gehören nicht an die einzelnen Mitglieder einer Relation, nur an die Relation selbst)

Jetzt bin ich mit der Durchsicht aller Teile des Landschaftsschutzgebiets "Schwarzachtal und Nebentäler) fertig. Dabei habe ich jeweils das tagging erweitert (nach Vorlage im wiki) und eine Liste erstellt, welche Teile dazugehören und durch welche Elemente die Teile durchlöchert sind.
An den Relationen habe ich nichts geändert, mir ist auch kein multipolygon aufgefallen.

Kommentare und tätige Hilfe sind mir willkommen!

LSG Schwarzachtal und Nebentäler

Einfache Flächen

Schwarzachtal bei Schwarzenbruck

Luderheim, Am Bühl

Ludersheim, nördlich der Bahnlinie

A6 Altdorf/Leinburg

Ezelsdorf, westlich Westfalenstraße

südöstlich von Ezelsdorf

Burgthann/Mimberg

Fläche mit einem Loch

südlich B8

Loch Kleingartensiedlung Unterferrieden

Fläche mit mehreren Löchern

für diesen Teil des LSG kann bisher keine Fläche gebildet werde, weil zu viele Knoten in der Linie entstehen würden (siehe post weiter oben) – noch ungelöst.

westlicher Teil der Grenze von Fläche “rund um Altdorf”:

https://www.openstreetmap.org/way/357151252/history#map=11/49.3535/11.2957

östlicher Teil der Grenze von Fläche “rund um Altdorf”:

https://www.openstreetmap.org/way/357151452/history#map=12/49.4064/11.3635

In der (noch nicht erstellten Fläche) gibt es folgende Löcher:

Auf der Kappel, Schwarzachtal (1)

Auf der Kappel, Schwarzachtal (2)

Pattenhofen

Schwarzachhof

Reinholdshöhe, Burgthann

Förreshof, Schwarzenbach und Dörlbach (das ist eine ziemlich große Fläche, die aber komplett innerhalb der größeren Fläche “rund um Altdorf” liegt.

Teil von Dörlbach

Peunting

bei Sesselberg

Grub

Westhaid

dieser Sportplatz (nur der Sportplatz!) bei Westhaid ist auch vom LSG ausgenommen und scheinbar schon richtig in eine MP-Relation eingetragen?
Verwirrt mich, weil die Fläche noch gar nicht komplett ist … wer kann das erklären?

Lenzenberg

Prethalmühle

Prackenfels

westlich Hagenhausen

Durch einen Hinweis von @WoSoe in einem CS habe ich es jetzt verstanden und jetzt auch die Relation (Grenze) gefunden, in der schon alle notwendigen tags eingetragen sind. Ich bau wieder zurück, was ich überflüssigerweise eingetragen habe.

Hinweis: Bei einer Relation type=boundary sind alle Daten des Schutzgebietes der Relation zugeordnet. Die einzelnen Ways (geschlossene wie offene) sollen, sofern sie keine Tags aus anderen Relationen besitzen, nur erläuternde note=* oder description=*-Tags erhalten

Noch eine Frage dazu: Muss die Fläche des LSG gar nicht geschlossen sein?
In der Relation sind scheinbar einfach die zwei offenen Linien, reicht das so aus?

Ich habe jetzt zurückgestellt, wie es vor meiner Bearbeitung war, mit den zwei tags:
note= (von mir konkreter formuliert)
und
boundary= protected_area

laut Wiki soll nur note=* oder description=* verwendet werden. Sollte ich den boundary-Tag löschen?
Dann entsteht auch nicht der automatische Hinweis auf die nicht geschlossene Fläche.

Das große outer des LSGs verläuft auf weiten Strecken entlang einer bereits verzeichneten administrativen Grenze. Diese sollte man recyclen. Macht die Sache sehr viel übersichtlicher und senkt die Zahl an Knoten im way. boundary-tag…eigentlich gehört er da nicht hin, ist aber vielerorts so erfasst.

Ich habe das “boundary=protected_area” von allen Mitgliedern entfernt.

1 Like

Wenn du Multipolygon-Relationen vereinfachen willst (wie es beim Regenrückhaltebecken-Thema angesprochen wurde), dann bieten sich z.B. solche Objekte an:
https://www.openstreetmap.org/relation/2512379
Das muss eigentlich gar keine Relation sein (das wurde als Multipolygon-Relation angelegt, damit die landuse=residential -Fläche als “Loch” drin ist). Man könnte dort wunderbar die Fahrbahn der Lindenbachstraße als Trennung sehen und eine simple landuse=farmland -Fläche nördlich davon und eine südlich davon erstellen und die Relation auflösen.

Eine andere Variante sind solche Multipolygone:
https://www.openstreetmap.org/relation/12039271
Hier werden mit Hilfe der Relation zwei Fragmente der Außenlinie zusammengestückelt. Man könnte stattdessen auch genauso gut eine ganz normale Fläche für das landuse=landfill dort erstellen.

Genau darum geht es mir!
ich finde auch das farmland-multipolygon in meinem Beispiel unnötig komplex. Noch dazu sind in dem Tal zum Teil Flächen als Wiese getaggt, die inzwischen als Acker verwendet werden und anders herum. Wenn es einzelne Flächen wären, könnte man sie leichter der aktuellen Nutzung anpassen.
Verstanden habe ich es so:

  • zuerst lösche ich die Relationen z.B. bei dieser Fläche:
    Relation History: 16836213 | OpenStreetMap
  • lösche dann das multipolygon-tag,
  • lege danach neu definierte Flächen nebeneinander an und korrigiere an den Grenzen die Relationen (auch die der umgebenden Flächen, in meinem Beispiel Wald oder Wohngebiet).

Ist die Vorgehensweise richtig?

Bitte für Anfänger kurz erklären:
Du meinst die beiden Grenzen, Landkreisgrenze, bzw. Regierungsbezirksgrenze und Grenze des Landschaftsschutzgebiets als eine Linie führen, wo sie miteinander verlaufen?
Oder was meinst du mit recyclen?

Und: wie geht das?

Der ID Editor macht es einem bei diesem Beispiel gar nicht so einfach die Relation zu löschen. Meine Empfehlung: Die Relation auswählen und aus der Liste mit den Mitgliedern alle Mitglieder entfernen. Wenn das letzte entfernt ist, wird automatisch die Relation gelöscht. Jetzt bleiben bei diesem speziellen Fall die ganzen Außenlinien-Fragmente als weiße Linien zurück. Die können alle gelöscht werden. Ab jetzt den ganzen Bereich mit neuen Flächen füllen. Irgendwelche anderen Relationen brauchst du da eigentlich nicht anfassen.

Hallo @milet
besten Dank für die konkrete Anleitung, damit kam ich sehr gut zurecht. Ob auch das Ergebnis passt, bitte ich (dich oder andere Mitlesende) zu prüfen:

das ist die erste der veränderten Flächen und dann geht es den Bach hinauf (Richtung Südost) bis hier:

Guten Abend,

Das, was ich bisher lese, hat was von Multipolygonwahnsinn - oder: Durchblick war gestern!

Für mich muß hier als aller erstes primär differenziert werden:

  1. Landuse-Multipolygone
  2. Grenz-Relationen jeglicher Art
  3. sonstige Multipolygonartige Relationen

zu 1. Landuse-Multipolygone sind eigentlich zunächst eine elegante Sache. Man kommt nicht um sie drum herum, wenn sie maßvoll eingesetzt werden!
Landuse-Multipolygone, deren geschlossener Outer-Umring aus mehr als 1 Segment bestehen, sind fast immer vermeidbar, es sei denn die Summe der beteiligten Stützpunkte nähert sich der Zahl 2000 oder liegt drüber. Das ist eine OSM-technische Grenze. Ein für mich zu 100% vermeidbares MP ist Relation: ‪Bauschuttdeponie Horbach‬ (‪12039271‬) | OpenStreetMap

Allerdings, wie man mit Multipolygonen mit mehr als einem outer umgeht, die aber jeweils selbst in sich selbständig sind, habe ich erst mal in speziellen Fällen verdrängt: z.B. Deetzer Erdelöcher

Zu 2. Grenzrelationen: Hier findes ich es gelinde geschrieben, äußert unschön, wenn Tags von den outer-Segmenten entfernt werden. Ich betrachte Grenzen als was anderes als normale Landuse-Multipolygone. Es schadet nicht, bei Schutzgebiets-Relationen, die aus mehreren, mehrheitlich geschlossenen Outer-Segmenten bestehen, zu mindestens boundary=protected_area auch am way zu belassen.

Schutzgebietsgrenzen sind mitunter Besch***eidener als man sich es denken mag…

Auch wenn Schutzgebietsgrenzen mitunter durch eine administrative Grenze definiert sind, ist meine dringende Empfehlung, administrative Grenzen nicht direkt für Schutzgebietsgrenzen zu verwenden. Ich hatte das anfangs vor geschätzt 8-9 Jahren hier im Spreewald zunächst gemacht, selbst mir als JOSM-Profi was das zu kompliziert und ich habe die betreffenden Segmente lieber nur verklebt… Grenzen ist relativ fest. einmal gut erfasst, muß man viele Jahre kaum was machen… Aber Schutzgebietsgrenzen ist eh ein sehr spezielles Thema, bei dem man immer stets und ständig eine sehr gehörige Portion lokales Wissen braucht…

Ein Entfernen von boundary-Tags an den Segmenten, die die Schutzgebiete und somit die Relation bilden hätte auch die Folge, daß man entsprechende und vergleichbare Tags bei administrativen Grenzen in Frage stellen kann… Ob das Zielführend ist, wage ich zu bezweifeln… :frowning: Ich als 100%-JOSM-Nutzer kann auch nicht einschätzen, wie z.B.iD und vor allem deren Nutzer damit damit klar kommen…

zu 3. Hier denke ich z.B. an Relationen vom type=building… da kommen bei mir die 3D-Ansätze ins Spiel und da überlasse ich anderen das Feld.

Multipolygonitische Grüße

Sven

Einzelnen ways können beliebig viele Relationen zugeordnet werden. Willkürliches Beispiel: Relation: ‪Naturpark Rhein-Westerwald‬ (‪16734079‬) | OpenStreetMap ist eine geschlossene Fläche ohne ‘inner’, die als Relation aus 51 Mitgliedern besteht. Jedes Mitglied ist ein way, manche kurz, andere sehr lang. Das Stück von Isenburg bis zur A3 verläuft entlang administrativer Grenzen, z.B. Way: ‪Saynbach‬ (‪243588427‬) | OpenStreetMap. Um die Naturparkgrenze dort einzuzeichnen, musste kein zusätzlicher Knoten oder way gesetzt werden, es reicht den way als ‘outer’ in die Relation aufzunehmen. Sehr hilfreich bei der Neuerfassung von Schutzgebieten, die an administrativen Grenzen verlaufen.

In Praxis bedeutet dies: Den langen Weg an der Stelle auftrennen, an dem er beginnt, entlang der administrativen Grenze zu verlaufen. Diese ggf. auch zerlegen. Der Teil der Grenze, welcher auch die Grenze des LSGs definiert, als ‘outer’ in die Relation aufnehmen. So hangelt man sich bis an den Punkt, an dem sich LSG-Grenze und administrative Grenze wieder trennen. Die redundanten Teile der LSG-Grenze dann aus der Relation entfernen und löschen. Dies lässt sich im ID-Editor durchführen, in JOSM ist es allerdings etwas leichter zu handhaben, wenn man mit dem Tool vertraut ist.

Nur bitte keine solchen Grenzen mit highways oder landuse verkleben. Das wird sehr ungern gesehen.

1 Like

Wenn du eine Auswertung machst (“Zeige mir alle Schutzgebiete in xy”), führt das ggf. zu einer falschen Anzahl an Schutzgebieten. Ist das gewollt?

Bei der Menge an unterschiedlichen Schutzgebietsarten kommt man nicht umhin, mindestens protect_class mit auszuwerten. Dann kommt es nicht mehr zu Falsch-Positiven…

Die Schwierigkeit ist eher, wenn man ein NSG hat, welches per Definition auch Totalreservatsflächen hat und Außengrenze des NSG (pc=4) teilweise gleich Grenze der zugehörigen Totalreservatsfläche (pc=1) ist. Das Total-Reservat ist Teil des NSG, solche Konstellation lässt sich aber nicht fehlerfrei in einer Relation darstellen. Oder wir heben die Rolle subarea wieder aus der Taufe…
Lieberoser Endmoräne und z.B. die zum NSG gehörende Totalreservatsfläche Wüste ist so ein Beispiel.

Sven

@streckenkundler
Der Hinweis auf den MP-Wahnsinn ist gut. Wie es @Nop formuliert hat, beschreibt gut meine Perspektive:

Ich denke damit machen wir die Daten langfristig für für die meisten potentiellen Anwender unbrauchbar oder auf Grund des hohen Implementierungsaufwands nicht lohnenswert und vergraulen eine enorme Menge an potentiellen Mappern und Anwendern, denen die Lernkurve, die da aufgetürmt wird, viel zu abschreckend ist. Vielmehr sollte viel mehr auf das KISS-Prinzip [4] geachtet werden: Multipolygone sollten nur dort eingesetzt werden, wo es technisch aufgrund der Größe der Objekte nicht anders geht, damit OSM auch wirklich ein offenes Projekt für möglichst viele Leute bleibt.