Hochspannungstrasse / landuse=forest

es gibt sicherlich Fälle wo das die beste Lösung sein kann, aber wenn z.B. da auch noch eine Hochspannungstrasse entlangläuft dann würde die sich ja mit der cutline die Linie teilen, da finde ich es übersichtlicher wenn man eine Lücke im Wald lässt wo man dann die power line einzeichnet

Wenn die cutline als Fläche eingetragen ist, kann man die power line gut dazwischen ziehen. Man kann die Fläche zwischen den getrennten Waldflächen sicher auch frei lassen, das stört aber die Anhänger des lückenlosen Flächenmappings.

Ich mache das eher davon abhängig wie breit die Straße so ist.

Wenn das eine schmale Tertiary ist und die Bäume so drüber hängen das ich die Bankette nicht sehe - geschenkt. Dann geht die halt durch den Wald.

Wenn das aber breite Straßen sind mit Standstreifen, Radweg, breiter Bankette, Leitplanke etc dann trenne ich da den Wald auf.

Ich nutze aber jede gelegenheit große Landuses aufzuteilen. Es macht einfach keinen Sinn landuses mit 2000+ ha zu haben die dann noch 40 Inner im Multipolygon haben. Die sind doch irgendwie immer kaputt.

Flo

+1
Du sprichst mir aus der Seele…!

Je konsequenter man das macht, desto stabiler sind die Daten.

Sven

ich sage ja nicht, man muss es unbedingt um jeden Preis bei jeder Straße machen, aber wie du selbst auch schreibst, eigentlich ist man froh über jeden Grund den Riesenlanduse etwas handhabbarer zu machen. Früher habe ich selbst teilweise so Riesenmonster gebaut, neulich eins wiedergefunden das mittlerweile in 12 Jahren zu einem Wäldermultipolygon mit fast 1000 membern angewachsen war, da habe ich mich verantwortlich gefühlt und es ein bisschen zerlegt, was gedauert hat. Heute versuche ich immer, möglichst einzelne Landuseteile zu mappen, ohne das alles datentechnisch zusammenhängt, das ergibt sich aus der Lage. Multipolygone mit inners für landuse zu verwenden bringt fast immer unnötige Komplexität

Zum Aufspalten von Riesen-MPs finde ich die JOSM-Funktion “Split Polygon” (Strg-Umschalt-1) hilfreich.
Da muss man nur einen Trenn-Way von Rand zu Rand ziehen und anders als bei “Objekt aufteilen” (Alt-X) werden gleich zwei MPs mit richtig zugeordneten inner erzeugt, bzw. ein MP und ein geschlossener Umring, wenn eine Teilfläche keine inner enthält.

das hätte ich mal wissen sollen, danke für den Tip, da gibt es glaube noch mehr Anwendungen in der Gegend :wink:

Zusätzlich kam damals erschwerend hinzu dass Josm ctrl auf dem Mac ersatzlos deaktiviert hatte, das hat Taylor Smock dankenswerterweise dann gefixt (auf meta-key umgelegt) https://josm.openstreetmap.de/ticket/22065

Toll. Statt eines Waldpolygons hast du jetzt also ein MP mit mindestens zwei outer. Das macht es nicht übersichtlicher.

Ich hab hier so eine Schneise. Trotzdem würde niemand auf die Idee kommen, wenn er die Stelle beschreiben müsste, nicht als Teil des “Göttinger Stadtwaldes” zu betrachten, wenn er eine Positionsangabe machen müsste.

So macht man es nicht.
Beim Zerteilen erhält man zwei MPs mit jeweils geringerem Umfang und weniger inner.
Wenn man es geschickt macht (Trennlinie entlang inner), erhält man u.U. sogar nur zwei simple Polygone ohne inner.

Ein Stadtwald muss genau so wenig mit einem einzigen MP abgebildet werden wie z.B. ein Stadtteil.

Nun, ich meine, wir müssen davon wegkommen, an alles und jedem direkt an der Geometrie einen name=* vergeben zu wollen. Den Datentyp Multipolygon, wie wir ihn z.B. hier bei Waldflächen anwenden, sehe ich als rein geometrisches Mittel, um Flächen entsprechend ihrer Zugehörigkeit (also z.B. See-Inner im Wald-outer) zu sortieren, mehr nicht. Für mich ist der Datentyp Multipolygon nicht dafür da, zugleich eine Sammelrelation zu sein, die alle Elemente innerhalb eines definiert zusammenhängenen Bereiches, der einen Namen hat, zu enthalten.
Für mich in der Folge brauchen wir ein irgendwie geeignetes akzeptiertes Schema, mit dem man solche Örtlichkeiten separat benamsen kann (z.B. aufsetzend auf place=*) Eine gute Idee habe ist auf die Schnelle nicht. Jetztendlich spielt das z.B. in die Disskussion zu Gemarkungen und Gewanne un vergleichbaren Disskussionen hinein.

Sven

genau, schließe mich meinen Vorrednern an, die Namensfrage sollte man losgelöst von den landuse und landcover details sehen. place ist für mich auch ein Kandidat hier. Es gibt oft auch nicht nur einen Namen, vielmehr haben die kleinen Teile Namen, ein paar davon zusammen haben wieder einen anderen Namen und das kann sich mehrere Male verschachteln, je nach Größe. Je größer diese Gebiete werden um so weniger scharf sind sie oft auch abgrenzbar.
Die ganzen Ortschaften und Städte “im Schwarzwald” sind irgendwie im Schwarzwald, aber geometrisch nicht innerhalb eines landuse forest.

Im Südschwarzwald gab es zu Landsat-Zeiten mal ein Riesenwaldgebiet über zig Kilometer. Manche der heutigen Monster-MPs sind Erben dieser Urgebilde.

Warum müssen die beiden teile in einem Multipolygon sein? Das verstehe ich nicht?!?

Flo

War mir auch erst unklar. Aber es geht wohl darum, dass das MP hier gleichzeitig auch noch den Namen des gesamten Waldes repräsentiert bzw in die Karte bringt. Dann kollidieren tatsächlich zwei Prinzipien (kleinräumige Erfassung von Flächen nach Nutzung/Bewuchs vs. ganzheitliche Abbildung von Flächenobjekten), und man müsste nach strenger Lehre eigentlich ein weiteres Polygon um den gesamten Wald ziehen und den Namen von den einzelnen MPs auf das Gesamtpolygon übertragen. Denn es ist ja nicht die einzelne Teilfläche, die „Stadtwald“ heißt, sondern die gesamte Fläche inkl. der Leitungsschneise.

genau, man müsste den Namen auf ein eigenes Objekt legen, und da kommen dann die weiter oben diskutierten tags für Namen ins Spiel. place=* war genannt, weil nur einen Namen ohne sonst was würde offen lassen, was dort getaggt ist

Nach der reinen Lehre ist das aber kein Multipolygon.

Relationen sind explizit KEINE Sammlungen.

Relationen beschreiben das Verhältnis unterschiedlicher Objekte zueinander.

Wenn es um Sammlungen geht dann sollen diese über gemeinsame Tags z.b. gematched werden. Alle Netto Filialen z.b. über den Operator, alle Teilstücke der A2 über den ref etc.

Das da stand heute viel Unsinn mit Sammlungen getrieben wird in dem man relationen für jede Bundesstraße macht ist mir bewusst, aber dafür sind und waren relationen eigentlich nicht gedacht.

Und was ist das Problem mit den Einzelteilen des Waldes das die alle Stadtwald heissen ausser mal davon abgesehen das man dann 30 mal in der Karte “Stadtwald” stehen hat? (Was zugegebenermassen unschön ist)

Flo

Steht etwas überkreuz mit dem OSM-Grundsatz, ein reales Objekt durch ein OSM-Element abzubilden. https://wiki.openstreetmap.org/wiki/DE:Ein_Objekt,_ein_OSM-Element

ja, wobei es hier ja nicht um eine Sammlung geht, sondern die Intention ist, ein Objekt, “den Stadtwald” zu haben. Eine Sammlung ist ein bisschen was anderes, außer die Sammlung “ist” auch ein Objekt. Diese ganze ein reales Objekt und ein OSM-Element-Regel ist eher plump gemeint (nicht 2 nodes für dasselbe), und taugt nicht zur Beantwortung von tagging-Fragen, das ist keine Regel an der man sich orientieren kann, weil man ja dadurch dass man bestimmt was das tag bedeutet sehr oft beides machen könnte, Einzelteile mappen, oder eine Einheit mappen. Schon so was einfaches wie ein Hotel mit Gaststätte, das könnte man als Einheit sehen, oder als ein Hotel und eine Gaststätte.

Zum “Stadtpark”, ich denke man kann schon so argumentieren dass man die Situation in so einem Fall mit einem Multipolygon lösen kann, nur ist das auf Dauer nicht nachhaltig, je ausgedehnter (und damit potentiell umfangreicher und unübersichtlicher) um so weniger. Wenn wir auch größere Regionen abbilden wollen (und das sind sicherlich auch viele überlappende Konstrukte) dann ist ein System das auf zig- und hundertausenden Nodes einer komplett geschlossenenen way-umrandung aufbaut eher nicht die Zukunft. Außer bei politischen Grenzen macht es auch keinen Sinn, eine genaue Lage der Grenze festzumachen, im Gegenteil ist es eher schädlich weil unnötig.

Dass dort dann 30 mal Stadtwald steht ist schon ein gutes Anzeichen für das Problem :slight_smile:

Um einen “Stadtwald” einzutragen, erscheint es mir sinniger, mit boundary=forest zu arbeiten: https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dforest und diese mit Name zu versehen.

Ich hatte selber einen vergleichbaren Fall. Ich hatte den “Stadtwald Horn” der Stadt Horn-Bad Meinberg vor Jahren zunächst als landuse=forest eingetragen, dies aber inzwischen geändert und die aus mehrer Flächen bestehende Multipoligon-Relation aufgelöst und dafür die Außengrenze des Stadtwaldes mit einer Linie boundary=forest versehen. Diese wird in der Standard-Karte zwar nicht angezeigt, die Suche “OpenStreetMap Nominatim” findet das Objekt aber, wenn man nach dem Namen sucht.

vgl. auch https://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dforest(_compartment)relations(v3)

Das halte ich für eine gute Lösung. Ich hab auch so einen fall wo jemand einen Wald namen (Von mir absichtlich nicht eingetragen) aus dem ALKIS übernommen und eingetragen hat.

Der Name stammt aus der Zeit vor dem Bau der Autobahn A2 und dem Autobahnkreuz Rheda-Wiedenbrück. Mittlerweile ist von dem Wald nicht mehr viel über ausser ein paar kleine Flecken hier und dort neben der Autobahn, im Kleeblatt und Co.

Das heute als “Zusammenhängenden Wald” einzutragen ist halt absoluter Mumpitz.

Wenn ein Wald so zersplitter und zergliedert ist könnte man eher mit sowas wie “place=locality” arbeiten weil es nunmal keinen zusammenhängenden Wald mehr gibt.

Man betrachte das hier:

https://www.openstreetmap.org/relation/12541239

Ich halte sowas für Unsinn. Vor allem weil als “Schiffheide” in Rheda Heutzutage nur noch die Straße “In der Schiffheide” bekannt ist.

Flo