Hochspannungstrasse / landuse=forest

Für mich ist das auch keine Forest. Es ist eine Schneise, wo keine forstliche Nutzung stattfindet. Wenn eine Autobahn duch den Forst gebaut wird, hört ja forest auch dort auf. Falls unter der Leitung, wie man es oft findet, Weihnachtsbaumplantagen angelegt werden, ist es IMHO auch keine forstliche Nutzung, sondern eher was landwirtschaftliches.

Nu natürlich es es eine forstwirtschaftliche Nutzung genauso wie eine Straße durch den Wald. Halt eine Sondernutzung.

Es bringt meines Ermessens garnicht, jeden Waldweg aus dem landuse=Forest auszuschneiden - auch ein Waldweg auf dem Bäume stehen ist unbenutzbar, gleichwohl Teil des Waldes.

Und wenn wir nicht flächecht Mappen (wie bei Straßen Bächen, Gräben, Stromtrassen etc) verschlimmvessert ein Ausschneiden die Situation nur. Gleiches gilt für Stromtrassen, wenn sie nicht wirklich markant (breite über 100 Meter) freigeschnitten sind (also nicht gleichzeitig eine Brandgasse sind).

Straßen und Stromtrassen werden ja bewusst dicker gezeichnet als sie in der Natur sind. Sonst würde man sie ja schlicht nicht erkennen können. Das verschiebt natürlich angrenzende Elemente und ergibt meiner Meinung nach nur Unsinn. Da wird dann plötzlich aus einem 3,5 Meter breiten Waldweg mit links und rechts 1 Meter Freiraum eine 120 Meter breite Schneise, die nicht existiert (in grôberen Masstäben).

Und solange wir die beiden Konzepte "flächengetreu" und "Funktionslinien ohne Flächenausdehnung" parallel verwenden, sollten wir es nicht übertreiben.

ich freue mich über jede Gelegenheit, einen Wald zu zerteilen, je kleiner die einzelnen Stücke um so übersichtlicher für die Mapper. Straßen und Schneisen nutze ich für das Zertrennen und verstehe auch nicht, wieso man das beim Mappen lieber ignorieren will

Im Gegensatz zu Straßen werden Stromtrassen auch nicht weiters überzeichnet beim Rendern, sofern sie überhaupt dargestellt werden

flohoff wrote:

Hi,
ich habe hier immer wieder den Fall das Hochspannungstrassen durch den Wald gehen. D.h. - Eigentlich trennen sie den Wald, denn unter den Hochspannungstrassen wird ja kein "Baumbewuchs" zugelassen, bzw entfernt. ...

Ich kenne es durchaus auch so, dass dort Nadelbäume zur späteren Nutzung als Weihnachtsbäume herangezogen werden. Nur mal so ...

Ciao

tracker51

Die Schneisen für Hochspannungsleitungen sind i.d.R. breit (wenn auch nicht zwingend 100 m) und markant (markant ist bei mir schon deutlich unter 100m Breite) und gehören m.E. gemappt. Ob nun als cutline über das forest-Polygon drüber oder flächengetreu den forest aufteilen und dazwischen ein anderes passendes landuse setzen, ist mir persönlich völlig gleich, wenn ich dies selber vornehme tendiere ich jedoch eher zu letzterem.

Skinfaxi wrote:

Und wenn wir nicht flächecht Mappen (wie bei Straßen Bächen, Gräben, Stromtrassen etc) verschlimmvessert ein Ausschneiden die Situation nur.

Wo wird denn da was verschlimmbessert? Nach meinem persönlichen, vernunftgeprägten und abwägendem Vorgehen: Waldwege, Gräben und Bäche, die man auf Luftbildern ohnehin wenig bis gar nicht durch die überragenden Baumwipfel erkennen und verfolgen (eher nur erahnen) kann, braucht man nicht ausschneiden, da darf auch Wald durchgehen. Erkennt man aber auf Luftbildern einen deutlichen Abstand zwischen den Bäumen auf der einen und anderen Seite bzw. nimmt man auch otg eine deutliche Lücke zwischen den Baumwipfeln wahr, kann man (und mit zunehmender Breite der Lücke tendiere ich eher zu "sollte man") den Wald an dieser Stellen trennen. Das muss bei weitem keine 100m breite Brandschneise sein. Und auch dass muss nicht zwingend immer sein, nur weil auf 100 m Länge die Lücke mal etwas breiter ist.

Skinfaxi wrote:

Straßen und Stromtrassen werden ja bewusst dicker gezeichnet als sie in der Natur sind. Sonst würde man sie ja schlicht nicht erkennen können. Das verschiebt natürlich angrenzende Elemente und ergibt meiner Meinung nach nur Unsinn. Da wird dann plötzlich aus einem 3,5 Meter breiten Waldweg mit links und rechts 1 Meter Freiraum eine 120 Meter breite Schneise, die nicht existiert (in grôberen Masstäben).

Das sind Scheinargumente. Wie es der Renderer darstellt hat nichts mit der Datenerfassung zu tun. Und in Maßstäben, wo aus Waldwegen breite Schneiden würden, werden diese i.d.R. ohnehin nicht mehr gerendert. Und Straßen oder Autobahnen können auch dann breiter dargestellt werden, wenn die Waldgrenze flächengetreu erfasst ist. Klar sieht man in größeren Maßstäben dann die Schneise nicht mehr, das ist aber vernachlässigbar - Kompromisse in der Darstellung muss man immer eingehen, das liegt in der Natur der Sache.

Skinfaxi wrote:

Und solange wir die beiden Konzepte "flächengetreu" und "Funktionslinien ohne Flächenausdehnung" parallel verwenden, sollten wir es nicht übertreiben.

flohoff schrieb von Schneisen mit Hochspannungsleitungen. Die sind breit und markant und dauerhaft nicht wirklich bewaldet. Das hat mit Übertreibung nichts zu tun. An jedem Forstweg eine Auftrennung vorzunehmen hat hier keiner gewollt.

flohoff wrote:

ich habe hier immer wieder den Fall das Hochspannungstrassen durch den Wald gehen. D.h. - Eigentlich trennen sie den Wald, denn unter den Hochspannungstrassen wird ja kein "Baumbewuchs" zugelassen, bzw entfernt. D.h. für mich sind das eher "scrub" Flächen.

Bei unseren großen Trassen (380kV) wird immer streng freigehalten. Das dann immer sowas wie natural=scrub oder natural=heath oder eine Mischung.

Auch bei den kleineren (10kV) wird das so gehandhabt. Wobei solche 10kV-Leitungen vermehrt unter die Erde gelegt werden.

Analog ist es mit den großen Gasleitungstrassen.

Solche breiten Schneisen trennen für mich immer.

Sven

tracker51 wrote:

Ich kenne es durchaus auch so, dass dort Nadelbäume zur späteren Nutzung als Weihnachtsbäume herangezogen werden.

Das ist dann landuse=plant_nursery

tracker51 wrote:

flohoff wrote:

Hi,
ich habe hier immer wieder den Fall das Hochspannungstrassen durch den Wald gehen. D.h. - Eigentlich trennen sie den Wald, denn unter den Hochspannungstrassen wird ja kein "Baumbewuchs" zugelassen, bzw entfernt. ...

Ich kenne es durchaus auch so, dass dort Nadelbäume zur späteren Nutzung als Weihnachtsbäume herangezogen werden. Nur mal so ...

-> landuse=plant_nursery

Das ist dann kein Forest mehr IMHO

Mammi71 wrote:

Die Schneisen für Hochspannungsleitungen sind i.d.R. breit (wenn auch nicht zwingend 100 m) und markant (markant ist bei mir schon deutlich unter 100m Breite) und gehören m.E. gemappt. Ob nun als cutline über das forest-Polygon drüber oder flächengetreu den forest aufteilen und dazwischen ein anderes passendes landuse setzen, ist mir persönlich völlig gleich, wenn ich dies selber vornehme tendiere ich jedoch eher zu letzterem.

Skinfaxi wrote:

Und wenn wir nicht flächecht Mappen (wie bei Straßen Bächen, Gräben, Stromtrassen etc) verschlimmvessert ein Ausschneiden die Situation nur.

Wo wird denn da was verschlimmbessert? Nach meinem persönlichen, vernunftgeprägten und abwägendem Vorgehen: Waldwege, Gräben und Bäche, die man auf Luftbildern ohnehin wenig bis gar nicht durch die überragenden Baumwipfel erkennen und verfolgen (eher nur erahnen) kann, braucht man nicht ausschneiden, da darf auch Wald durchgehen. Erkennt man aber auf Luftbildern einen deutlichen Abstand zwischen den Bäumen auf der einen und anderen Seite bzw. nimmt man auch otg eine deutliche Lücke zwischen den Baumwipfeln wahr, kann man (und mit zunehmender Breite der Lücke tendiere ich eher zu "sollte man") den Wald an dieser Stellen trennen. Das muss bei weitem keine 100m breite Brandschneise sein. Und auch dass muss nicht zwingend immer sein, nur weil auf 100 m Länge die Lücke mal etwas breiter ist.

Skinfaxi wrote:

Straßen und Stromtrassen werden ja bewusst dicker gezeichnet als sie in der Natur sind. Sonst würde man sie ja schlicht nicht erkennen können. Das verschiebt natürlich angrenzende Elemente und ergibt meiner Meinung nach nur Unsinn. Da wird dann plötzlich aus einem 3,5 Meter breiten Waldweg mit links und rechts 1 Meter Freiraum eine 120 Meter breite Schneise, die nicht existiert (in grôberen Masstäben).

Das sind Scheinargumente. Wie es der Renderer darstellt hat nichts mit der Datenerfassung zu tun. Und in Maßstäben, wo aus Waldwegen breite Schneiden würden, werden diese i.d.R. ohnehin nicht mehr gerendert. Und Straßen oder Autobahnen können auch dann breiter dargestellt werden, wenn die Waldgrenze flächengetreu erfasst ist. Klar sieht man in größeren Maßstäben dann die Schneise nicht mehr, das ist aber vernachlässigbar - Kompromisse in der Darstellung muss man immer eingehen, das liegt in der Natur der Sache.

Skinfaxi wrote:

Und solange wir die beiden Konzepte "flächengetreu" und "Funktionslinien ohne Flächenausdehnung" parallel verwenden, sollten wir es nicht übertreiben.

flohoff schrieb von Schneisen mit Hochspannungsleitungen. Die sind breit und markant und dauerhaft nicht wirklich bewaldet. Das hat mit Übertreibung nichts zu tun. An jedem Forstweg eine Auftrennung vorzunehmen hat hier keiner gewollt.

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.

Ich bitte Dich aber auch das Argument von "Funktionsmappen" gelten zu lassen.

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.

seichter wrote:

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:

Schneisen sind meist ein guter Anlass, großflächige Waldpolygone in kleinere Teilflächen zu trennen. Diese Teilflächen sind weniger komplex und erleichtern die Versionierung und Verarbeitung.

dieterdreist wrote:

laut Wiki auf eine Linie, d.h. anderen landuse oder landcover kann man so nicht mappen

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 🙄, 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

dieterdreist wrote:

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.

dieterdreist wrote:

Ich bitte Dich aber auch das Argument von "Funktionsmappen" gelten zu lassen.

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

flohoff wrote:

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.

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

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

dieterdreist wrote:

ich freue mich über jede Gelegenheit, einen Wald zu zerteilen, je kleiner die einzelnen Stücke um so übersichtlicher für die Mapper.

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.

jengelh wrote:

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

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.

jengelh wrote:

dieterdreist wrote:

ich freue mich über jede Gelegenheit, einen Wald zu zerteilen, je kleiner die einzelnen Stücke um so übersichtlicher für die Mapper.

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.

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.

dieterdreist wrote:

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.

jengelh wrote:

dieterdreist wrote:

ich freue mich über jede Gelegenheit, einen Wald zu zerteilen, je kleiner die einzelnen Stücke um so übersichtlicher für die Mapper.

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.

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

Flo

flohoff wrote:

Warum müssen die beiden teile in einem Multipolygon sein?

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

FraukeLeo wrote:

flohoff wrote:

Warum müssen die beiden teile in einem Multipolygon sein?

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.

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

flohoff wrote:

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)

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

flohoff wrote:

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.

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.

flohoff wrote:

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)

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

Um einen "Stadtwald" einzutragen, erscheint es mir sinniger, mit boundary=forest zu arbeiten: https://wiki.openstreetmap.org/wiki/Tag … y%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/Pro … tions_(v3)

Galbinus wrote:

Um einen "Stadtwald" einzutragen, erscheint es mir sinniger, mit boundary=forest zu arbeiten: https://wiki.openstreetmap.org/wiki/Tag … y%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/Pro … tions_(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