Hochspannungstrasse / landuse=forest

Das ist dann landuse=plant_nursery

1 Like

→ landuse=plant_nursery

Das ist dann kein Forest mehr IMHO

1 Like

Jaklar ist es auch eine Sache des Augenmaßes. Er schreibt von Hochspannungsleitungen und da gibt’s ja viele: überlandtrassen oder kleine. Und wie immer in OSM kann das was an einer Autobahn oder Schnellstraße sinnvoll ist (waldzerteilen) nicht auf alles überzragen werden.

Nu und ich notiere das Du zur Fraktion der Flächenmapper gehörst und ich verstehe den Kontext in dem Du argumentiert.

Ich bitte Dich aber auch das Argument von “Funktionsmappen” gelten zu lassen. Das sich Objekte verschieben und mannicht mehr weiß, was überdeckt werden darf, ist kein Problem des Renderes sondern der kartografischen Prinzipien, die die Datenstruktur vorgeben

Entweder “malt man eine Karte” was ja in kleinem Maßstab durchaus funktioniert oder man zeichnet eine nach logischen Abstraktionen.

Und wir müssen da einen guten Kompromiss finden. Wie kompliziert das ist siehst Du ja immer an den Beispielen wie Straße mit Geweg oder Objekte im Wald.

beim Funktionsmappen ist es m.E. auch so, dass ein tertiary highway kein Wald ist. Für Forstwege würde ich auch nicht den Wald teilen (außer es gibt noch andere Gründe), aber es muss keine Schnellstraße oder Autobahn sein, jede Durchgangsstraße (im Wald und sonstwo) ist landuse=highway, meinetwegen auch nur implizit wenn man will, jedenfalls ist der Hinweis auf Funktion kein Grund gegen das Trennen.

Ich, als Freund des detaillierten Mappings auch in der freien Landschaft, trage bei solchen Stromtrassen das als Landnutzung ein, was ich vor Ort dem Augenschein nach vorfinde.

Das kann Grasland sein, dass kann Buschland sein, auch Weihnachstbaumplantagen kommen vor. Alles drei sind für mich von landuse=forest abweichende Nutzungen. Es sind auch markante Landschaftsmerkmale, so dass ein Einzeichnen wichtige Informationen z.B. für die Orientierung von Wanderern darstellen.

Für solche Schneisen bietet sich man_made=cutline an.

nie verwendet, kommt das auf eine Linie oder eine Fläche? Update: laut Wiki auf eine Linie, d.h. anderen landuse oder landcover kann man so nicht mappen, jedenfalls nicht mit derselben Geometrie

gut auf jeden Fall dieser Hinweis im Wiki:

Nach Wiki ist das für die Fälle vorgesehen, bei denen man das darunter liegende landuse/natural nicht trennen möchte.
Ich war aber auch schon so frei :roll_eyes:, das als schmale Fläche zu taggen, an die sich die (getrennten) Waldflächen anschließen, insbesondere wenn die Schneisen stark in der Breite variieren.

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.