Teich im Wald, Multipolygon oder wie besser/anders

Hallo Forum,

ich habe in einem Waldstück eine Teich.

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

• Anlegen des Waldes und des Teiches
• Wald erhält die Relation “Bewirtschafteter Wald” und die Rolle “outer”
• der Teich erhält die Relation “Bewirtschafteter Wald” und die Rolle “inner”
• beide Objekte vereinigen

Jetzt wird bei der Darstellung das Gewässer aus dem Wald “ausgestanzt”.

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

Ich könnte auch wie folgt vorgehen, das ist nur so ein Gedanke, daher bitte nicht lächeln:

• Anlegen des Teiches
• Anlegen des Waldes in zwei oder mehr Teilen
• die inneren Punkte der Waldfläche exakt auf die Punkte des Teiches legen, so hat es keine Lücken/Zwischenräume
• das gesamte Waldstück aus mehren Teilen in der beschriebenen Weise drumrumbauen

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…

Ich bin offen für Hinweise wie ich besagte Sache besser als meine Lösung taggen kann!

Dank & Gruß,
Mietz

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.

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

+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.

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.)

Eher die Frage, warum sind sie es nicht mehr?

Ich glaube nicht, dass Id das kann, oder?

Gruss
walter, der auch immer gleich an JOSM denkt :wink:

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

–ks

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! :slight_smile:

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

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 :wink:

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

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.

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.

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

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

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