Teich im Wald, Multipolygon oder wie besser/anders

Hallo Mietz,

für so einen Fall ist ein Multipolygon die richtige Lösung. Deine Alternative wird auch verwendet, aber nur in Gebieten, die aus riesigen Wäldern bestehen wie z.B. in Kanada. Da würde ein einzelnes MP einfach zu komplex.

Mietz wrote:

Ich habe jedoch gelesen, das man solche MP, welche durch meine Vorgehensweise einstehen, vermeiden sollte. Warum eigentlich?

Ich schließe mich GerdP an: Da hast du entweder eine übertriebene Darstellung gelesen oder sie übertrieben aufgefasst. Tatsache ist, dass Multipolygone, da sie komplexer sind als einfache Flächen, so sparsam wie möglich einzusetzen sind. In dem beschriebenen Fall ist ein Multipolygon aber die beste Lösung. Deine zweite Lösung, separate Außenflächen, würde ich nur dann anwenden, wenn diese Außenflächen auch selbst unterschiedliche Eigenschaften haben, z.B. Bewaldungsart (Nadel-/Laubwald) oder unterschiedlich heißen. Eine willkürlich gezogene Trennlinie verwirrt nur, weil es garantiert den einen oder anderen Auswerter gibt, der die (bedeutungslose) Grenze mitrendert, auch wenn unsere sogenannte Standardkarte das nicht macht.

Zu deiner Vorgehensweise: Erstmal zwei Waldrelationen anlegen und diese dann vereinigen ist unnötig umständlich, oder du hast es umständlich formuliert. Du kannst auch beide Polygone erstmal als einfache Flächen anlegen (1 x bew. Wald, 1 x Teich), dann beide selektieren und „Vereinigen“ wählen. Das erzeugt in einem Schritt die Relation mit dem Teich als inner. Aber vielleicht hast du das gemeint.

--ks

GerdP wrote:

für so einen Fall ist ein Multipolygon die richtige Lösung.

+1

Genau dafür sind sie vorgesehen und angemessen.

Es gibt nur leider viele Beispiele wo Leute einfache Vielecke als Multipolygon anlegen oder mit extrem komplexen Konstruten über die Stränge schlagen. Deshalb hast Du vermutlich diese Warnung gelesen.

Mietz wrote:

Ich habe jedoch gelesen, das man solche MP, welche durch meine Vorgehensweise einstehen, vermeiden sollte. Warum eigentlich?

Ich hab zwar die weiter oben erklärte Vorgehensweise nicht verstanden aber ich versuche trotzdem mal zu erklären, wie es hinterher aussehen soll:

Es ist egal, ob die Renderer intelligent sind. Die Daten an sich müssen stimmen.
Die Renderer machen bei erkannten Fehlern in den Daten nur vorläufige Reparaturen, damit die produzierte Karte nicht so blöd aussieht. Der Fehler muss aber noch in den Daten repariert werden.

Jede Fläche in OSM wird über ihren Rand angegeben:

Der Rand des Teichs ist die innere geschlossene Linie. Deshalb kommen Teich-Tags an diese Linie.

Der Wald hat als Rand sowohl die innere als auch die äußere geschlossene Linie. Deshalb kommen die Wald-Tags an etwas, das beides angibt: Das Multipolygon.

Kein zu mappendes Objekt hat als Rand nur die äußere Linie. Deshalb kommen an die äußere Linie keine Tags.

(Aber wenn z.B. Wald und Teich zusammen ein Naturschutzgebiet wären, dann kämen die Naturschutzgebiet-Tags an die äußere Linie, denn das wäre dann ja der komplette Rand des Naturschutzgebietes.)

Mietz wrote:

Ich frage mich allerdings, warum die Renderer nicht so intelligent sind, und erkennen, dass, wenn ein Gewässer in einem Waldstück ist, und das einfach korrekt darstellen; also das keine Bäume im Wasser wachsen....

Eher die Frage, warum sind sie es nicht mehr?

Mietz wrote:

Das trage ich bisher immer so im Webseiten-Editor ein:

kreuzschnabel wrote:

Zu deiner Vorgehensweise: Erstmal zwei Waldrelationen anlegen und diese dann vereinigen ist unnötig umständlich, oder du hast es umständlich formuliert. Du kannst auch beide Polygone erstmal als einfache Flächen anlegen (1 x bew. Wald, 1 x Teich), dann beide selektieren und „Vereinigen“ wählen. Das erzeugt in einem Schritt die Relation mit dem Teich als inner. Aber vielleicht hast du das gemeint.

Ich glaube nicht, dass Id das kann, oder?

Gruss
walter, der auch immer gleich an JOSM denkt 😉

wambacher wrote:

Ich glaube nicht, dass Id das kann, oder?

Also bei mir konnte er’s vorhin. Ich probiere so was aus, bevor ich es empfehle 🙂

--ks

wambacher wrote:

Ich glaube nicht, dass Id das kann, oder?

Immer diese Vorurteile. Das kann iD sogar schon Recht lange. Nur mit komplexen MPs hats zuweilen Probleme gegeben. Aber auch hier gab es Verbesserungen.

Hallo,

danke für die zahlreichen Hinweise! 🙂

Dann mache ich es, es sei gedankt, bisher immer richtig, wenn solche Sachen einzutragen sind.

Relationen zu dieser Sache sind nicht nötig, stimmt. Der Webseiten-Editor erledigt das mit inner und outer beim Vereinigen brav von selbst.

Nun bin ich wieder etwas schlauer, Danke!

MfG
Mietz

miche101 wrote:

Mietz wrote:

Ich frage mich allerdings, warum die Renderer nicht so intelligent sind, und erkennen, dass, wenn ein Gewässer in einem Waldstück ist, und das einfach korrekt darstellen; also das keine Bäume im Wasser wachsen....

Eher die Frage, warum sind sie es nicht mehr?

Ein Renderer ist ein Zeichenprogramm und kann das nicht lösen.

Nehmen wir die typischen Beispiele Wald, Wiese und See. Versuch einfach mal die "richtige" Reihenfolge zu finden, in der ein Renderer das zeichnen soll, so daß sowohl ein See in einem Wald und eine Waldinsel in einem See richtig erscheinen.

Nop wrote:

Ein Renderer ist ein Zeichenprogramm und kann das nicht lösen.

Nehmen wir die typischen Beispiele Wald, Wiese und See. Versuch einfach mal die "richtige" Reihenfolge zu finden, in der ein Renderer das zeichnen soll, so daß sowohl ein See in einem Wald und eine Waldinsel in einem See richtig erscheinen.

Doch das ist ja schon mal gegangen... Es wurde um beim Beispiel zu bleiben frühers erst die Wiese gerendert, dann der Wald, dann den See...
Für die Wiese hat diese Reihenfolge nicht funktioniert... drum hat man für diese eine Relation gebraucht. Bist ja auch schon seit 2009 dabei müsstest es ja auch wissen 😉

Irgendwann wurde das geändert... drum kommt jetzt sowas raus...
https://www.openstreetmap.org/#map=18/48.26747/11.44784

miche101 wrote:

Doch das ist ja schon mal gegangen... Es wurde um beim Beispiel zu bleiben frühers erst die Wiese gerendert, dann der Wald, dann den See...
Für die Wiese hat diese Reihenfolge nicht funktioniert... drum hat man für diese eine Relation gebraucht. Bist ja auch schon seit 2009 dabei müsstest es ja auch wissen 😉

Es hat nie funktioniert, denn so wie Du es beschreibst verschwinden Inseln im See. Machst Du's anders verschwindet was anderes. Genau deshalb braucht man die Multipolygone.

Nop wrote:

verschwinden Inseln im See

Aso die Weise ist im See... Ja da aber aber auch nur da hat man das machen müssen sonst aber nicht.. aber wie meinst.

man macht jetzt absichtlich Baumsymbole über die Wasserflächen weil man so einerseits die Mappingfehler (wo es Fehler sind) erkennt, und andererseits braucht man das auch dort, wo wirklich Bäume im Wasser stehen.
Die Renderreihenfolge innerhalb des gleichen Render-Layers, von Flächen, ist AFAIK nach wie vor der Größe nach, abnehmend.

Prinzipiell könnte ein Renderer die Größe der Objekte betrachten und das kleinere Objekt über das größere legen. Aber man findet sicher Fälle, wo auch das zum falschen Ergebnis führen würde.

Mietz wrote:

Ich frage mich allerdings, warum die Renderer nicht so intelligent sind, und erkennen, dass, wenn ein Gewässer in einem Waldstück ist, und das einfach korrekt darstellen; also das keine Bäume im Wasser wachsen....

MPs sind nicht dazu da, den Renderern zu sagen, wie sie was in welcher Reihenfolge malen sollen.

Es geht schlicht darum, ob man den See zum Wald gehörend ansieht -> kein MP anlegen, oder ob der See nicht zum Waldgebiet gehört -> MP anlegen.

“Waldgebiet” suggeriert m.E. etwas anderes als landuse=forest (nämlich ein Gebiet mit vorwiegend Wald, wo es durchaus auch mal einen See oder eine Lichtung geben kann), während sich z.B. osm-carto klar auf den Standpunkt stellt dass der tag Flächen bezeichnet auf denen Bäume stehen. Wenn man es so sieht gibt es nichts zu interpretieren, der See muss auf jeden Fall per Multipolygon ausgeschlossen werden

chris66 wrote:

Es geht schlicht darum, ob man den See zum Wald gehörend ansieht -> kein MP anlegen, oder ob der See nicht zum Waldgebiet gehört -> MP anlegen.

So isses.

Ein einfaches Polygon (also geschlossener Way) mit landuse=forest sagt: „Alles hier drin ist Forst“.

Wenn nun irnkwas dadrin nicht Forst ist, müssen wir dem Forst-Polygon zusätzlich noch eine Innengrenze setzen, die inhaltlich hinzufügt: „… außer allem, was hier drin ist“. Und genau das tut ein Multipolygon, dafür ist es da.

Ob und wie und in welcher Reihenfolge ein Renderer das verarbeitet, ist vollkommen ihm selbst überlassen. In der Datenerfassung geht es uns ums korrekte Beschreiben der vorhandenen Flächen.

--ks

dieterdreist wrote:

“Waldgebiet” suggeriert m.E. etwas anderes als landuse=forest (nämlich ein Gebiet mit vorwiegend Wald, wo es durchaus auch mal einen See oder eine Lichtung geben kann), während sich z.B. osm-carto klar auf den Standpunkt stellt dass der tag Flächen bezeichnet auf denen Bäume stehen. Wenn man es so sieht gibt es nichts zu interpretieren, der See muss auf jeden Fall per Multipolygon ausgeschlossen werden

Guter Einwand. Da komme ich nämlich in letzter Zeit auch ins Grübeln. landuse=* bezeichnet eine Flächennutzung, und ein kleiner Tümpel z.B. als Wildtränke gehört ja durchaus zum Ökosystem „Wald“ dazu, und damit zur entsprechenden Flächennutzung. Dass osm-carto Baumsymbole über die Wasserfläche malt, muss einen dann nicht stören, denn diese Symbole bedeuten – bei der angesprochenen Interpretation – ja nicht „hier stehen Bäume“, sondern „diese Fläche wird forstwirtschaftlich genutzt“.

Klarer ist es bei Aufforstungsflächen (die gehören eindeutig zum landuse=forest dazu) oder Acker- oder Siedlungsflächen innerhalb des Waldgebietes (die gehören eindeutig nicht dazu).

Wie gesagt, ich finde die Entscheidung manchmal gar nicht so einfach: landuse wörtlich als „Flächennutzung“ auffassen oder pragmatischer als „Flächen-Aussehen“?

--ks

kreuzschnabel wrote:

Wie gesagt, ich finde die Entscheidung manchmal gar nicht so einfach: landuse wörtlich als „Flächennutzung“ auffassen oder pragmatischer als „Flächen-Aussehen“?

Sogar noch pragmatischer laut Wiki: "überwiegende Nutzung".
Das lässt eine Straße im residential, ein Wohnhaus im commercial, Bäume auf meadow und einen Teich im forest zu.

Ab wann man ausschneidet, ist nicht so eindeutig und verschiebt sich mit zunehmender Detaillierung, siehe die Diskussion über (größere) Straßen im residential.
Da kann auch mal eine Zerlegung einer größeren Fläche entlang von Wegen, Baumarten etc. angesagt sein.

Für echte landuses wie residential, commercial etc. sollte man es als überwiegende Flächennutzung auffassen.

Für Tags, deren aktuelle Nutzung historisch bedingt ist und die eigentlich nie ein landuse-Tag hätten sein dürfen (landuse=grass) oder die seit ihrer Erfindung eine Bedeutungsverschiebung erfahren haben (landuse=forest) mappt man halt nur die mit Gras/Bäumen bewachsene Fläche.

Wie ich sehe, eine komplexe Sache. Und vor allem, wie jeder was interpretiert.

Die Gedankensätze dazu finde ich gut, was die Nutzung/Art des Waldes darstellt.

MfG

Tordanik wrote:

Für echte landuses wie residential, commercial etc. sollte man es als überwiegende Flächennutzung auffassen.

Für Tags, deren aktuelle Nutzung historisch bedingt ist und die eigentlich nie ein landuse-Tag hätten sein dürfen (landuse=grass) oder die seit ihrer Erfindung eine Bedeutungsverschiebung erfahren haben (landuse=forest) mappt man halt nur die mit Gras/Bäumen bewachsene Fläche.

Ich denke, dass die "echten landuses" auf dem OSM-Planet ausgestorben sind und vom Detailmapping versehentlich gekillt wurden. Man konnte mal in grauer Vorzeit das "Industriegebiet Haan-Ost" mappen. Selbstverständlich waren in diesem Industriegebiet auch noch Straßen, ein paar Wohnhäuser, eine Kneipe und eine Schafweide eingeschlossen. Jetzt könnten wir das "Industriegebiet Haan-Ost" höchstens noch als place=location mappen.

@Weide (OT)
Bar jeder Ortskenntniss habe ich mal gegoogelt:
"Der Industriepark Haan-Ost liegt östlich der Innenstadt [...]. Die Gesamtfläche netto beträgt rund 455.000 qm, davon sind etwa 375.000 qm als Industriegebiet und rund 80.000 qm als Gewerbegebiet ausgewiesen."
https://www.haan.de/index.phtml?La=1&sN … 23.1&sub=0
Die Stadt Haan schreibt also selbst zum "Industriepark Haan-Ost" (nicht "Industriegebiet Haan-Ost"), dass er zwar "Industrie" heißt, aber kein vollständiges Industriegebiet ist.

Da hab ich dann wohl ein falsches Beispiel genommen. Also streiche "Haan" und setze "Rumpelstilzchenfeld" (Hoffentlich gibt es das nicht) :-)

Weide wrote:

Ich denke, dass die "echten landuses" auf dem OSM-Planet ausgestorben sind und vom Detailmapping versehentlich gekillt wurden. Man konnte mal in grauer Vorzeit das "Industriegebiet Haan-Ost" mappen.

ich denke, dafür war landuse noch nie ein guter tag, m.E. ist place für solche Siedlungsteile besser geeignet, z.B. place=neighbourhood.