Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Das widerspricht Punkt 6 der Empfehlung, damit ist der Verweis hinfällig.

Den Einwand finde ich berechtigt. Als neuen Diskussionspunkt möchte ich hervorbringen, dass das Proposal von drei Benutzern im Endeffekt verfasst wurde: Benutzer Nakaner hat das angestoßen (es ging um eine Vorschrift (?)), Benutzer Pfad-Finder hat das überarbeitet und an die Diskussion angepasst und ich habe es schließlich im Wiki zusammengetragen (mit dem alleinigen Ziel der Dokumentation und mit beschränkter Sachkenntnis).
Sofern keine exakten Texte vorgeschlagen wurden, habe ich mich gehütet, etwas Größeres an der Formulierung zu ändern. Es wäre u.U. besser gewesen, den Prozess von Anfang an auf der Wikiseite zu vollziehen. Um ein Beispiel zu nennen: In dieser Änderung https://wiki.openstreetmap.org/w/index.php?title=DE%3AProposed_features%2FEmpfehlung_zur_Verwendung_von_Multipolygonen&type=revision&diff=1700323&oldid=1699870 hat Pfad-Finder aus meinem Empfehlungen befolgen wieder Leitlinien beherzigen gemacht, was schon zuvor dort stand, ich aber für stilistisch ungünstig hielt (ich weiß natürlich nichts über die Intentionen).

Da ich die inhaltliche Diskussion bereits für sehr länglich und weitschweifig hielt, wollte ich jetzt nicht noch den formalen Aspekt einbringen. @woodpeck Um es offen zu sagen: Mir war das Inhaltliche und ein zeitiger (aber nicht überhasteter!) Abschluss der Diskussion wichtiger als ein stilistisch hochwertiges Dokument, was alle Begriffe exakt definiert. Ich habe das bewusst in Kauf genommen.

Das kann man pauschal so nicht sagen. In Sachsen wurden in manchen Gegenden alles digital versiegelt und dann von den Verursachern nie wieder angefasst (und leider auch von niemand anderem). Und das auch ohne das jemand die Multipolygone aufgelöst hat.

Es war und ist in der Disskussion vor der Abstimmung nicht immer eindeutig von den Disskutanten dargelegt worden, was sie in ihren Beiträgen genau meinten…

  1. entweder ein Linienobjekt welches sich lediglich die Stützpunkte mit einer angrenzenden Fläche teilt, sonst aber ein sparates Daten-Objekt ist, welches mit dem Cursor auch separat ausgewählt werden kann
  2. ein Linienobjekt, welches stets als Liniensegment Teil einer MP-Relation ist und somit in der Folge dieses Liniensegment mit mehreren weiteren Liniensegmenten eine Umgrenzungslinie (aka Outer) eines Multipolygons bilden.
  3. ein als Fläche definiertes Objekt trägt in Gänze zusätzlich die Eigenschaft eines Linienobjektes (z.B. ein Fläche mit power=substation, die zugleich barrier=fence trägt)
  4. ein vollständig separates Linienobjekt, welches sich nicht oder nur einzelne Punkten einer Fläche teilt, diese Punkte, die geteilt werden, sind nicht aufeinanderfolgend!

Bei 2. und 3. kann man keine separaten Linienobjekte wählen, da das gewählte Linienobjekt als einziges entweder Teil einer oder mehrer Relation (2.) ist oder Teil eines geschlossenen Linenzuges (Geschlossener Way, eschossener Ring, Fläche ect…) bei 1. und 4. hingegen schon!

Ich für mich definiere lediglich die erstgenannte und wenn zutreffend, die zu letzt genannte Variante als “verkleben”!

Gewisse Objektklassen sind per se als Linienobjekte definiert, was auch gut so ist: Straßen, Mauern, Zäune, Grenzen.

Wenn z.B. ein Mauer oder ein Zaun mit einer Residental-Fläche “verklebt” ist, sehe ich das als unkritisch an. Bei Straßen sollte man Verkleben tunlichst vermeiden, im Sinne der besseren Datenerfassung an Straßen, weil viele Flächenobjekte auch aus anderen Gründen MP’s sein können und ein blindes Verkleben zu mit unter aufwendig zu beseitigenden MP-Fehlern führt. Es ist für mich logisch auch ein Problem… Die Straßen in OSM sind lediglich ein Vektor, sie stellen nur eine Richtung als Netzwerk mit verbundenden weiteren Vektoren dar. Mit Hinblick aufs Detail-Mapping bringt erst area:highway die Fläche dazu, mit der logischen Folge, daß Flächen zerteilt werden müssen.

“Verklebt” man Landuse/ MP’s mit Straßen, bliebe immer die unlösbaren Fragen:
-gehört nun die Straße zum residential? oder zum industrial?
-geht der Acker wirklich bis Mitte der Bundesstraße? Was ist mit dem Grünstreifen zwischen Straße und Acker, der ist doch 3m breit und den Bäumen?
-ect. p.p.

Noch ein Wort zu Grenzen… Gelegentlich kommt es gerade bei Schutzgebietsgrenzen vor, daß es heißt:

in solchen Fällen ist für mich die Definition eineindeutig. Dann ist Gewässerufer, bzw. Gewässerachse= Grenze. Verschiebt sich durch natürliche Gegebenheiten das Ufer oder die Gewässerachse, verschiebt sich die Grenze.

Sven

eines der prägendsten Beitragsfäden für mich war https://forum.openstreetmap.org/viewtopic.php?id=16911 Der war auch einer der Gründe, warum ich begann, MP-Fehler zu beseitigen, MP’s zu verkleinern, ect…

Darum vom mir noch mal Danke für die Abstimmung…

Sven

Ich finde es sehr schade, daß viele Leute zwar gegen den Vorschlag Stellung bezogen haben, aber sich vorher weder an der Diskussion beteiligt noch an einer Verbesserung der Formulierung in ihrem Sinne mitgearbeitet haben, sondern erst in der Abstimmung die Diskussion begonnen haben.

Naja, vielleicht wird dann die zweite Version gut genug…

Diese Aussage muss ich mir erst mal nicht annehmen. Sowohl auf der Diskussionsseite, des Proposals als auch in der Mailingliste und hier habe ich Änderungsvorschläge gemacht.

Ich kann mich nur der Analyse von Frederic anschließen. :slight_smile: Für so eine genaue Textanalyse hätte ich ehrlich gesagt im Moment nicht die Geduld Und auch dem, was Kreuzschnabel zu geschriebener Sprache dargelegt hat, kann ich nur zustimmen.

Auch wenn es nur oder gerade weil es eine Empfehlung ist, sollte es textlich Händchen und Füßchen haben. Ich habe in meinem Berufsleben schon einiges an Arbeitsanweisungen verfasst. Und standardmäßig war dort auch immer der Zweck beschrieben. Und da fängt es schon an. Wenn Ihr Anfängern Euer Anliegen begreiflich machen wollt, müsst Ihr weiter ausholen und dann sprachlich klarer und eindeutiger formulieren, was das Ziel ist.

Ich habe viele Arbeitsanweisungen gesehen, die ohne weiteres bei jeder Zertifizierung durchgegangen sind. Die hingen auch aus. Die wurden aber nie richtig angewendet, weil sie für den"Normalsterblichen" viel zu kompliziert geschrieben waren.

Was will ich damit sagen?

Die Absicht ist inhaltlich in diesem Proposal sicherlich rübergebracht worden. Aber sie ist einfach nicht praxistauglich und verständlich beschrieben.

Deshalb noch einmal meine Empfehlung: Proposal vom Netz nehmen, überarbeiten, dabei Kiss-Prinzip beachten, ausführlich diskutieren und dann nochmal abstimmen.

Es gibt noch mehr Sachen, die mich mittlerweile in OSM stören. Eines davon hängt eng mit dem hier diskutierten Proposal zusammen. Das ist die um sich greifende Relationitis. Es wird viel zu viel in Relationen gezwängt, was gar nicht muss, was auch später nur schwer bis gar nicht bearbeitbar ist.

Aber das führt hier jetzt zu weit.

Ja, den Hut setze ich mir auf. Mich hat diese Abstimmung auf dem falschen Fuss erwischt, ich hatte gesehen, dass eine Diskussion stattfindet, und ich habe sie nicht gründlich verfolgt (und bei den paar Posts, die ich gelesen habe, nichts gesehen, dem ich unbedingt widersprechen wollte). Irgendwie hatte ich immer gedacht, wenn das aus dem Ruder läuft, kriege ich es schon mit, und ansonsten sind die Leute auch selbst vernünftig genug. Bei so einer großen Gruppe von Leuten im Forum kann man ja wohl davon ausgehen, dass offensichtliche Probleme ausgebügelt sind, bevor etwas zur Abstimmung kommt. Dass das, was zur Abstimmung kommt, sich “gesetzt” hat, und dass wenigstens alle darin einig sind, dass dies eine gute Vorlage für die Abstimmung ist (selbst wenn einige für und einige gegen die Annahme der Vorlage sind).

Ich war dann aber echt enttäuscht, weil klar wurde, das das, was hier zur Abstimmung kommt, eben nicht ausgegoren ist. Und dabei geht es nicht um Inhaltliches - dass ich meine Meinung dazu nicht eingebracht habe, ist mir egal - sondern um den Prozess an sich und das Formelle. Dass eine regionale Community über Regeln oder Empfehlungen abstimmt, ist ein Novum in OSM, und ich finde das nicht unbedingt schlecht, aber der Prozess dahin muss ordentlich sein, die Arbeit sauber, der Vorschlag sauber überlegt und dreimal gegengelesen. Damit das nachher auch auf soliden Füßen steht und man mit Fug und Recht sagen kann: So machen wir das in Deutschland, das haben wir in dieser Abstimmung entschieden. Und es tut mir leid, wenn ich Tigerfell und streckenkundler, die das hier offenbar hauptsächlich vorangetrieben habe, damit in die Suppe spucke, aber so ein Vorschlag muss von mehr Augen angesehen und von mehr Händen mitgestaltet werden - ein “hat noch jemand was dazu zu sagen, sonst stell ich das morgen ins Wiki zur Abstimmung” reicht nicht. Das muss auf die Mailingliste, ins Forum, in die Wochennotiz, und lang genug, damit es solide wird. Und ich sag es nochmal - die Dinge, die mir aufgefallen sind, die wären auch vielen anderen aufgefallen, die sich damit beschäftigt hätten. Die wären auch aufgefallen, wenn man sich mal einen Neuling geschnappt und ihm das vor die Nase gehalten hätte. Es geht mir nicht darum, dass ich nicht mitgeredet habe, sondern dass offensichtlich zu wenige Leute mitgeredet (und mitgedacht) haben.

Aber weil ich nun mal im Schreiben bin, sag ich meine Meinung doch mal etwas ausführlicher:

  1. Die zwei Hauptprobleme mit Multipolygonen sind m.E. (a) die Landuse-Teppiche, bei denen jede kleine Grenze zwischen verschiedenen Landuses als Mini-Way ausgeführt wird, damit man ein Multipolygon für jeden Landuse machen kann und (b) Multipolygone mit mehreren äußeren Ringen, deren Gemeinsamkeit einzig und allein das landuse-Tag ist (also eine dreiteilige Wiese statt drei kleinerer Wiesen). Ich denke, das könnte man erschlagen mit einer Regel wie “Multipolygone sollten im Normalfall nur in Betracht gezogen werden, wenn die Grenze zwischen zwei benachbarten Flächen mehr als X (20?) Nodes umfasst UND die Flächen größer als X (10?) qkm sind”. Natürlich müssen die Ausnahmen “mit Loch” oder “disjunkte Teile der gleichen Sache” behandelt werden.

  2. Jeder Emfpfehlung sollte eine Erklärung vorangehen, die klar macht, worum es geht, was der Unterschied zwischen den verschiedenen Ansätzen ist und vielleicht sogar, wie sich das im Editor darstellt.

  3. Das Verklebe-Thema ist auch wichtig, aber ich denke, es sollte mit der Multipolygon-Empfehlung nicht verquickt werden. Lieber zwei eigenständige Empfehlungen. Wenn wir dann erstmal im Trott sind, können wir regelmässig weitere Empfehlungen dazubauen. Vielleicht finden wir eine schöne Präambel für den ganzen Topf. Wir wollen keine festen Regeln, aber Standards - nach dem Motto: Wenn Du nicht nachdenken willst, folge diesem Schema; wenn Du dem Schema nicht folgen willst, dann ist das ok, aber Du musst dafür einen Grund angeben können. Die Amerikaner würden das vermutlich “Best Practices” nennen.

Bye
Frederik

+1. Mir ging es ganz ähnlich, und mich hat die Abstimmung auch etwas überrumpelt.

Und wenn ein Vorschlag zur Abstimmung gestellt wird, darf jeder dazu „Nein“ sagen, auch wenn er sich vorher nicht eingebracht hat. Nops Schade-Findung kann man insofern als kleinen Tiefschlag auffassen. Einen ausgereiften Vorschlag zu unterbreiten liegt in der Pflicht derjenigen, die sich aktiv daran beteiligen.

Ich persönlich möchte 70–80 Prozent meiner mit OSM verbrachten Zeit in produktives Mapping investieren, der Rest ist für Meta-Projekte wie Forum oder Wiki da. (Zugegeben, für die WN bleibt gerade nichts mehr übrig.)

–ks

An die Ablehner des “Proposed feature”,

macht es besser… schreibt einen zweiten Entwurf der zur Abstimmung gehen kann… der euren hohen Anforderungen genügt. Aber ich sehe schon das hier nichts bei rauskommen wird… aus ach so vielfältigen Gründen… keine Zeit/Lust usw. Dann sehen wir mal ob dieser mehr Zustimmung findet. :wink: Die ganze Zeit hier meckern… und eure Ausführungen nachzuvollziehen bzw. sie irgendwie zu verstehen… dieses hin und her bringt auch nicht weiter.

Für mich gilt dieser Vorschlag bis zu dem Zeitpunkt wo ein besserer kommt… :stuck_out_tongue: Im Wiki schreibt eh gefühlt jeder was er will… das wenigste wird diskutiert… und auch sehr oft weichen die deutschen Seite der Englischen Seiten ab… oder werden gleich mal auch mitgeändert…

Das ganze könnte auch in einer Blog eines Users stehen als Meinung/Empfehlung…

Gruß Miche

wobei ich den Eindruck habe, dass es mittlerweile mehr Kontrolle darüber gibt, was gemacht wird. Früher hat man manchmal nach 2-3 Jahren erst gemerkt, dass da jemand unausgegorene Änderungen gemacht hat, heute sind zweifelhafte Edits oft schon nach wenigen Stunden wieder revertiert (m.E. ist der Hauptgrund, dass man im Wiki automatisch die Seite beobachtet, wenn man eine Änderung macht).

Dass die deutschen Seiten geändert werden, wenn die englische Seite geändert wird, halte ich für richtig (bei Tag-Definitionsseiten). Die deutsche Version sollte eine Übersetzung der englischen Version sein, es wäre der Alptraum, wenn die tags in jeder Sprache anders bzw. unabhängig definiert wären.

Falls die Formulierung tatsächlich nur als Empfehlung zum Abwägen gedacht ist, ist sie zu einseitig. So wie er da steht, stellt der Satz das Mappen von Zäunen neben der Flächengrenze implizit als die Standardlösung dar, mit der man eigentlich nie falsch liegt, und von der man wenn überhaupt nur nach reiflicher Überlegung abweichen sollte. Zur Verdeutlichung des Unterschieds – eine neutrale Aufforderung zum Abwägen sähe für mich eher so aus:

Überlege reiflich, ob es die jeweilige Situation vor Ort besser wiedergibt, Linienelemente wie Mauern und Zäune auf oder neben Flächengrenzen zu setzen.

(Unabhängig davon hat das Verklebethema natürlich nur indirekt mit Multipolygonen zu tun und verdient wohl eine separate Diskussion.)

Ich wiederhole meinen Punkt aus #368: Bei einem Proposal ist jeder stimmberechtigt, nicht nur die, die am Vorschlag mitgearbeitet haben. Und jetzt die beleidigte Leberwurst zu geben macht den Vorschlag auch nicht besser. Was sollte ich sonst machen? „Ich find den Text zwar nicht gut, aber ich hab ja nicht dran mitgeschrieben, also bin ich dafür“? Das kann es doch auch nicht sein, oder?

Wenn der Anspruch, dass ein Text stringent, verständlich und in sich logisch sein sollte, für dich schon „hohe Anforderungen“ darstellt, dann solltest du nicht in meinem Beruf tätig werden :slight_smile: Den zur Abstimmung stehenden Text finde ich ganz einfach nicht zielführend, die Gründe habe ich dargelegt und muss ich hier nicht nochmal wiederholen. Auch Alternativen habe ich oben schon vorgeschlagen, was hältst du von denen? Ein Text, der Anfängern eine Empfehlung aussprechen sollte, sollte zumindest auch Anfängern verständlich sein und nicht ohne Erklärung einen Begriff wie „verkleben“ verwenden, von dem ein Anfänger gar nicht weiß, was das ist.

Ich bin, wie bereits gesagt, gern dazu bereit, an einem entsprechenden Text mitzuarbeiten. Aber der sollte dann nicht mitten im frühen Entwurfstadium zur Abstimmung gestellt werden und seine Mitmacher durch berechtigte Ablehnung zutiefst kränken.

–ks

Mal einfach gesagt:
Die, die Ablehnen wissen ja um welches Problem es geht.
Also erstellt einen Vorschlag nach euren Vorstellungen und der richtigen Wortwahl und stellt in zur Abstimmung.

Es geht nur um eine Empfehlung in DE Multipolygone nur zu verwenden, wenn es sich nicht mit einfachen Flächen (Polygonen) festlegen lässt. Ferner sollte die Verwendung von ways mit eigenen Schlüsseln und Werten für Polygone vermieden werden.

Sortierung nach Medien und dann Zeit:
Ankündigung Mailing-Liste: https://lists.openstreetmap.org/pipermail/talk-de/2018-November/115642.html mit anschließender Diskussion dort
Ankündigung der Abstimmung auf der Mailingliste: https://lists.openstreetmap.org/pipermail/talk-de/2018-December/115730.html
Diskussion im Forum (man beachte die erste Zeile: “**TL;DR **Ich denke, dass es an der Zeit ist, dass wir als deutsche Community Regeln einführen, die – das meine ich wirklich so – die übertriebene Nutzung von Multipolygonen für unerwünscht erklären.”): https://forum.openstreetmap.org/viewtopic.php?pid=725141#p725141
Benennung “letzter Punkte” durch mich im Forum, mit Hinweis, dass sonst die Abstimmung eingeleitet wird (zwei Tage vor Abstimmungsanfang): https://forum.openstreetmap.org/viewtopic.php?pid=729768#p729768
Ankündigung des Abstimmungsanfangs im Forum: https://forum.openstreetmap.org/viewtopic.php?pid=729986#p729986
Ankündigung in Wochennotiz #436, 4. Punkt der Rubrik “Mapping” etwa zwei Wochen vor Abstimmungsbeginn: http://blog.openstreetmap.de/blog/2018/12/wochennotiz-nr-436/
Bekanntmachung der Abstimmung in Wochennotiz #439 (wieder Rubrik “Mapping”, siebter Punkt): http://blog.openstreetmap.de/blog/2018/12/wochennotiz-nr-439/

Wo wären weitere Hinweise hilfreich gewesen?

Damit ich nicht nur meckere, hab ich mal ein paar erklärende Worte zu dem Thema aufgeschrieben, auf http://www.remote.org/frederik/tmp/multipolygone.pdf als PDF und http://www.remote.org/frederik/tmp/multipoly.zip mit Quelldateien in SVG und ODT. Das ist jetzt sicherlich auch wieder zu viel, um direkt Teil einer Empfehlung/Richtlinie/Regel zu werden, aber vielleicht sollte man das irgendwie abrunden und dann verlinken, oder man stampft es auf eine Seite zusammen und macht es dann doch mit in den Abstimmungstext mit rein oder… Lizenz zum beliebigen Verwursten hiermit erteilt :wink:

Leute, jetzt machen wir zig Baustellen auf und überall steht etwas wichtiges oder weniger wichtiges oder nur Empfehlungen oder eine Anleitung…
Alleine dieser Thread reicht schon, damit 50% der deutschen Mapper wissen, worum es geht.
Und ich denke, die erfahrenen Mapper sind einer solchen “Belehrung” mit diesem ganzen Diskussionsgerede irgendwie müde, weil sie es ja sowieso schon längst machen oder in einigen Fällen vielleicht auch, weil sie sich nicht belehren lassen möchten. Wen wollt ihr eigentlich erreichen?
Mal abgesehen davon, das ihr die beiden deutschsprachigen Länder A/CH mal außen vorgelassen habt, was ich als WN-Redakteur nun überhaupt nicht gut finde, liegt doch eigentlich das Ziel dieser Initiative der Information an Anfänger (Erg.: siehe auch aktueller Eintrag im A-Forum) und Nichtnutzer vom JOSM Editor. Oder?
Jetzt gibt es mehrere Anfänger-Tutorials. Ich möchte ganz besonders das von kreuzschnabel hervorheben, sehr schön als PDF strukturiert aufgebaut. Jetzt hat Frederik noch was Nettes zusammengestellt.
Kann man dies nicht irgendwie alles verlinken?
Auch das jetzige Proposal, wenn es mal etwas klarer dargestellt ist, und zwar wirklich als Richtlinie, worauf sich die “deutschsprachige” OSM Community geeinigt hat, gehört in solche Anfänger Seiten, zumindest verlinkt, die dann hoffentlich auch gefunden wird, wenn man “OSM für Anfänger” googelt. Der Stellenwert dieses Proposals sehe ich nicht höher als gute WIKI Vorlagen, die mal vor 8 Jahren erstellt wurden und noch immer gelten sollen, wie dieses hier, was dann an 2. Stelle steht in der genannten Suche. Erg.: Es wäre fast schon sinnvoller gewesen, dieses Tutorial auf den Stand der Zeit zu bringen…

Es wird hier immer der Anfänger betont… es geht auch um die erfahrenen Mapper.

Man soll einfach keine Monster bauen nur weil man es kann und gut findet… weil geht eins dieses Monster mal kaputt oder es verändert sich was. Dann ist es nicht schön diese Monster zu ändern bzw. zu reparieren. :frowning: Beim erstellen dieser ist ja alles noch gut und schön und leicht, aber später…

z.B. so was:
https://www.openstreetmap.org/relation/178160

…warum muss das alles in einem MP sein? Muss das sein? Hätte man da nicht mehrere machen können :frowning:

Der Punkt 5 macht das deutlich, wie unschön das ist… im Proposed

https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen

Gruß Miche

+1

Der Hürtgenwald (eine von mehreren kaputten Relationen) https://www.openstreetmap.org/relation/116883 bzw. http://tools.geofabrik.de/osmi/?view=areas&lon=13.18608&lat=52.07960&zoom=9&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags,ways

Oftmals haben sich solche Monster auch nur im Laufe der Zeit entwickelt und keiner traut sich/macht sich die Arbeit und setzt die Schere an… Darum kann man daas nich dem letzten Bearbeiter anlasten…

Sven

Und wie würdest du das mappen? Viele kleine landuse=forest, jedes mit name=Hürtgenwald? Dito, aber ohne name=* an den einzelnen Landuses? Wo soll der Name dann hin?

Das Beispiel zeigt doch, dass wir viel dringender als Empfehlungen zum Umgang mit Multpolygonen praxisgerechte Empfehlungen zum Mappen von Landuses mit eingeschlossenen Landuses brauchen.

Nun der Hürtgenwald hat ja jetzt schon 4 Teile: http://overpass-turbo.eu/s/EPr

Das Namensproblem kann man meiner Ansicht nach nicht dadurch lösen, indem man darauf verzichtet, Riesen-MP’s zu verkleinern… eine praktiable Lösung habe ich auch noch nicht parat… Das Namensproblem hat man aber bei fast allen großen Waldgebieten…
Vor allem tritt es auf, wenn durch ein Waldgebiet eine Niederungsrinne mit Seen und Bruchwald durchzogen wird… h

Ich kenn das hier von den großen Waldgebieten in Brandenburg…

Eine Idee, die in mir rumgeistert, ist eine einfache geschlossene Umgrenzungeslinie um alle Wald-Teilflächen, diese mit boundary=region + region=wood + name=XY (Relation sollte nur dann angewendet werden, wenn die Linie die 2000-Punkte-Grenze überschreitet. Inner-outer-Rollen halte ich für unnötig.

[Edit] Interessante Ecke… Die “Waldnamensvielfalt” ist/war ja echt groß: https://mapire.eu/de/map/europe-19century-secondsurvey/?bbox=690434.280728071%2C6555505.72779371%2C705071.9716446823%2C6561238.504915098&layers=osm%2C158%2C164
Rötgener Wald, Rollesbroicher Wald, Rotter Wald, Zweifaller Wald. Kornelimünster Wald, Raerener Wald, ect…[/Edit]

Sven