Ich weiss nicht ob Polygone selbst auch Nummern haben, deshalb nenne ich hier die Nummern der Wege:
Outer member (dieses Luch) = 343237361
inner member u.a. = 24341160
In dem Senziger Luch sind weitere Flächen, nämlich
595230920 natural scrub
595230918 landuse forest.
Müssten diese Flächen nicht als inner member in das Multipolygon 343237361 eingefügt werden?
Wenn ja, mĂĽssten die von 595230920 und 595230918 verdeckten inner member aus 343237361 rausgenommen werden,
und in den neuen Multipolygonen eingefĂĽgt werden?
Die neuen Multipolygonen mĂĽssten dann als innen member in 343237361 eingefĂĽgt werden?
Ich glaube, dass ist so richtig. Bevor ich da etwas ändere, wollte ich mich aber erst befragen.
Warum aber das ganze? Das Aussehen des Kartenmaterials wird sich dadurch.
Was ändert sich, zum Beispiel für die renderer?
Das MP gibt an, für welche Fläche die Flächeneigenschaft (in dem Fall Sumpf/Marsch) gilt.
Gibt es in dem Sumpf einen kleinen Wald, dann muss er nur dann als inner-Member rein, wenn es ein Trockenwald ist, also die Bäume nicht im Sumpf stehen. Alles klar?
Wenn man alleine das Geometrische betrachtet, mĂĽsste man das sicher nach inner/outer trennen. Tags und das korrekte Rendering dĂĽrfte es hergeben.
Das in meinen Augen nicht schön umsetzbare Problem ist, das mitunter der Name dann nicht immer an die korrekte Stelle gesetzt werden kann. Man kann wie hier das Gebiet sicher recht gut nach landuse/natural unterteilen, aber letztendlich würden alle Elemente zum Senziger Luch gehören… Allen Flächen den Namen zu geben würde mehrfaches, falsches Namensrendering erzeugen. Nur eine Fläche würde suggerieren, daß zum Beispiel eine angrenzende Waldfläche nicht dazu gehören würde…
Alternativ wäre auch ein Punkt mit place=locality durchaus möglich, was aber auch nicht schön ist, denn gerade wie in diesem Beispiel kann man sowas wie das Senziger Luch in der Landschaft doch recht gut abgrenzen…
So… ich habe mir das Senziger Luch mal in JOSM geladen…
Mit dem Outer (https://www.openstreetmap.org/way/343237361) würde ich das Senziger Luch, bzw. alle dadurch eingeschlossenen Elemente zum Luch zugehörig rechnen (der eine Schuppen im Nordwesten ausgenommen).
Vorschläge wie sie in Vergangenheit immer wieder kamen, man könne wie hier an den Stellen zwischen Rand des Luches und dessen, was nicht dazugehört, einen schmalen Rand lassen, wäre auch nur Mappen für den Renderer, um ein Namensrenderung mittels eines MP’s zu erzwingen, wo geometrische kein MP ist.
Im Hinterkopf schwebt mir als fixe Idee zwar eine Art “Namensgrenze” vor, die in 4-5 Varianten für landuse/natural aufgeteilt werden könnte, detailiert habe ich das für mich aber bisher nicht dargelegt…
Fazit: ich sehe das für mich erst mal als hinreichend fuktionierende Erfassung an. Sicherlich mit einer Portion “Mappen für den Renderer” aber mangels korrekter Erfassungsmöglichkeiten in meinen Augen vertretbar.
so war das mal gedacht, im landcover proposal: natural hätte den Namen bekommen. Man könnte aber auch einen neuen Typ einführen für diese Art Objekt
Ich wĂĽrde es so betrachten:
-Es gibt eine Fläche auf die “natural=wetland” zutrifft.
-Es gibt eine Fläche auf die “name=Senziger Luch” zutrifft.
-Die beiden Flächen sind verschieden.
Man könnte ohne Probleme beide Flächen mappen, aber dann hätte man bei der zweiten Fläche nur den Namen und das geht in OSM nicht, obwohl der Name das einzige ist, was gerade diese Fläche auszeichnet. Für den Fall wird meist “place=” genommen … aber damit werden wieder Eigenschaften aus anderen Objekten erneut beschrieben. Brauchen wir wirklich die “place=*”-Differenzierung oder könnten wir mit einem einfachen “place=area” leben?
Das Problem tritt übrigens häufig auf und wird nur unauffällig umgangen. “name=Bodensee” gehört doch z.B. eigentlich an die ganze Fläche (einschließlich Inseln) und nicht an den Wasseranteil (“natural=water”).
Ja nun… letztendlich ist vieles auch ein kleinwenig Interpretation… Wenn man es erst mal auf den Haupttag reduziert, kann ich auch sagen, alles ist natural=wetland mit name=Senziger Luch. Differenziert ist es dann mit wetland=wet_meadow, mit wetland=swamp, wetland=reedbed … (mit wetland=marsh kann ich so richtig nichts anfangen)
Ich habe mir das Luch auf einer topographischen Karte von Brandenburgviewer angesehen. Demnach gehört nicht alles, was in OSM als Luch gemapt ist, wirklich zum Luch. Der Teil westlich des von Nord nach Süd verlaufenden Grabens ist kein Feuchtgebiet. Das ist auch auf unterschiedlichen Satelitenaufnahmen zu erkennen. Mal sind die Flächen umgepflügt, mal ist Wiese zu sehen. Ich beabsichtige das Feuchtgebiet entsprechend zu verkleinern.
In der topographischen Karte gehören 595230920 natural scrub 595230918 landuse forest zum Feuchtgebiet.
Deshalb denke ich, dasss die Erklärung von chris66 zutrifft, dass kein inner member des MP angelegt werden muss.
Es gibt quasi keinen Handlungsbedarf, ausser dass ich das Feuchtgebiet verkleinern und westlich davon Farmland eintragen wĂĽrde.
Trotzdem vielen Dank für die Beiträge. Ich habe wieder was dazu gelernt
scheint mir für die (historische Flur) Bezeichnung “Senziger Luch”
keine klar definierte geometrische Abgrenzung zu existieren.
in solchen Fällen würde ich den name eher an ein
place=locality hängen,
statt an (irgend)ein landuse/natural.
@Jesse Pinkman, sorry, Du hast recht, https://www.openstreetmap.org/way/112569536 (einfach als Link aus der Browserzeile hier reinkopiert)
Dies wird wg. seinem tagging gegenwärtig auf der Standardkarte nicht angezeigt, daher von mir übersehen.
Die derzeitige Karten-Beschriftung “Tiergarten” kommt dagegen aus diesem natural-wood https://www.openstreetmap.org/way/595230919
IMHO auch so ein “keine gute Idee”-Fall …
https://www.openstreetmap.org/way/112569536
Da es als NSG nur ein einfacher geschlossener Linienzug ist und nicht area=yes, bzw. leisure=nature_reseve trägt, wird es nicht gerendert. Wenn das NSG eine Relation wäre, würde es gerendert werden.
@Jo, wie hatten wir das in der NSG-Disskussion herausgearbeitet, area=yes setzen? Ich hab das schon wieder vergessen…
Ich hab aber auch in meiner Gegend leisure=nature_reserve wieder nachgetragen owohl ich es weiterhin nicht schön finde… Letztentlich besteht das Renderingproblem ja auch bei anderen protect_class-Werten.
Im ĂĽbrigen:
Wenn man das LSG “Teupitz - Köriser Seengebiet” erfassen würde, könnte und müsste NSG und LSG als Relation ge/umgebaut werden. LSG, weil es Löcher hat, NSG kann, da Grenzabschnitte im Bereich des Krebssees LSG und NSG-Grenze sind… Dann wäre es wieder “leisure=nature_reserve”-frei…
ganz so ist es nicht. Der Name bezieht sich schon auf die Gegend mit dem Feuchtgebiet bzw. einschlieĂźlich der Gegend am / um das Feuchtgebiet.
Es gibt halt mehrere Arten von “Bodensee”, einerseits der See an sich, andererseits die Gegend im und am See einschließlich der Orte in der Nähe des Sees (es ist also nichtmal notwendig, dass man direkt am Ufer ist, wer ein paar Kilometer im Hinterland wohnt würde sich vermutlich immer noch als “am Bodensee” wohnend sehen).
Geografische Gegenden, und das stellen wir nicht zum ersten Mal fest, lassen sich allgemein schlecht in OSM abbilden, weil es oft gar keine haarscharfe, millimetergenaue Grenzlinie gibt (sondern das eher ein fließender Übergang ist, der ggf. auch von unterschiedlichen Leuten unterschiedlich interpretiert wird), und wir für unscharfe Grenzen bisher immer noch keine Abbildungsmöglichkeit haben.