Hi Pan,

I am correcting incorrect sequences or incomplete segment definitions in the sub-segments of the outer line and some inner-ways of the multipolygon. I also removed coupled nodes from a previous but deleted version.

Guten Morgen Manuel,

ich stimme dir hinsichtlich der Benennungen und "bridge=" völlig zu, habe aber an diesen bereits vorhandenen Benennungen und den Keys nichts geändert. Mein Fokus gestern lag auf der Entfernung eines kurzen Railway-Ways zwischen Biebricher Straße und Weiche 703 sowie der Anpassung des Brückenauflagers. Hierbei habe ich mich am deutlich ausgepägten Schattenverlauf Nord-West-Seite im Hintergrundbild "Mainz neueste Luftbild" orientiert und daraus den Rückschluss gezogen, dass bis in diesen Bereich das Brückenauflager reichen muss.
Daraus notgedrungen entstanden ist dann die neue Segmentierung der beiden Railways ab Weiche 703 bis zum Brückenende, angehoben auf Layer=1. Für diese beiden neuen Segmente wurde (leider) jeweils eine neue Chronik erzeugt.

Viele Grüße - Michael

Hallo silversurfer83,

Danke für den Tipp und ja, ich benutze wenn möglich auch die regionalen Karten. In diesem Fall bin ich in der Bing-Linie meiner "Vor-Mapper" geblieben, denn ich wollte "nur" den monolithischen Block etwas detaillieren, ohne die gesamte Struktur anzufassen.

Dir noch einen schönen Sonntag!

Guten Morgen UE_Su,

vielen Dank für Deine umfassende Antwort. Ich glaube nicht, dass wir so sehr auseinander liegen. Letztlich kreist unsere Diskussion um einen systemischen Mangel in OSM, denn im Gegensatz zu den den Flächen "landuse=railway" für OSM-Vektoren "railway" und natural=water" für "waterway", gibt es bei "highway" keine Entsprechung. Das lässt dann automatisch Spielräume für allerlei Interpretationen.
Im Unterschied zu deiner Sicht, sind mir aber präzise erfasste Flächen in OSM sehr wichtig: Prinzipiell, weil ich nicht nachvollziehen könnte, wenn bestimmte Gruppen in OSM, z.B. buildings, highways mit höchster Genauigkeit, andere Dinge dagegen nur "so la la", erfasst werden sollten. Zum anderen wird die OSM-Datenbank für unterschiedlichste Zwecke verwendet. Geofabrik z.B. stellt täglich aus der kompletten OSM-DB diverse Extrakte zur weiteren Verwendung zur Verfügung. Das, was darüber geliefert wird, lässt sich aber nicht mehr hinsichtlich der zur Verfügung gestellten Qualität der Daten prüfen, schon gar nicht korrigieren.

Ich habe gesehen, dass Du Deine Änderungen vom 19.12. zurückgenommen hast. Vielen Dank dafür! Ich werde mir über die Weihnachtstage noch einmal Gedanken machen, inwiefern "area=highway" hier helfen könnte.

Dir und Deiner Familie wünsche ich ein frohes Weihnachstfest!

Viele Grüße!

Hallo UE_Su,
sorry, das sehe ich völlig anders (und hatte es ja auch anders gemacht). Es kommt ja niemand auf die Idee, Weinanbauflächen beidseitig einer Autobahn in einer Abwicklung über den Autobahn-highway hinweg anzulegen, genauso wenig dies z.B. mit Waldflächen gemacht wird, oder "natural=water"-Linien orientieren sich streng an den Wasserrändern. Und wie gesagt: Es kommt ja auch niemand auf die Idee, einen Gebäudeumriss (und der ist i.d.R. erheblichst kleiner als ein landuse=vineyard) zwingend an einen highway anzulehnen, nur weil man den Bürgersteig nicht als "leeren" Zwischenraum belassen möchte. Wir können nicht einmal so, einmal so verfahren, nur weil uns subjektiv die tatsächliche Breite der highway-Fläche einmal zu groß, ein anderes Mal zu klein ist. Aber dies ist hier genau der Fall.
Es hat niemand den Anspruch ein korrektes Kataster in OSM zu hinterlegen. Ganz im Gegenteil: OSM stellt uns Schlüssel zur Verfügung, mit denen wir ganz konkret Flächen, dazu gehören vineyard, wood, building, water, etc. auf der Erdoberfläche mit Nutzungs-/Belegungs-Attributen beschreiben können. Ich halte es als langjähriger aktiver OSM-Mapper für unmöglich, entgegen dem, was deutlich auf dem Bildschirm sichtbar ist, Flächen mit nicht zutreffenden landuse-Deklaration zu belegen. Das sollte und kann nicht unser Anspruch sein.

Sorry, ist mir erst jetzt aufgefallen: Du hast eine überlappende landuse=vineyard-Flächen, "name=Kieselberg" auf einer boundary-Umrisslinie erfasst, die ihrerseits mit "name=Forster Mariengarten" deklariert ist. Was gilt jetzt?

Für mich ist auch eine Fläche natural=scrub, die einen wie auch immer definierten highway überspannt, falsch. Schließlich sind in der Realität Straßen und Wege nicht mit Büschen besetzt. Warum machen wir das dann in OSM? Bei der Erfassung einer Fläche, die zum building deklariert wird, achten wir ja auch peinlich auf die Übereinstimmung mit dem Grundriss.
Und dann muss man trennen, zwischen der namentlichen Besetzung eines Gebietes als "Weinberg", oder "Weinanbaufläche/-lage" und der tatsächlichen landuse-Anbaufläche. Ersteres sollte, wenn erforderlich, separat als "place=locality" definiert werden.

Gruß!

Hallo UE_Su,

warum hängst du die einzelnen landuse=vineyard-Flächen wieder aneinander? Dadurch werden die durchlaufenden Wegeparzellen und die um die Anbauflächen herum laufenden Grünstreifen wieder als Anbauflächen deklariert. Die Anbauflächen werden größer, als sie in Wirklichkeit sind.

Hallo limes11,

danke für den Hinweis, ich bin mir dessen bewusst, hier aber auch noch nicht ganz fertig. In OSM waren sowohl das östliche vineyard-Multipolygon, als auch das separat davon westlich erfasste und heute von mir zerteilte vinyard-Polygon jeweils identisch mit name=Bopparder Hamm getaggt. Laut Wikipedia bezieht sich die Bezeichnung "Bopparder Hamm" aber auf das linke Ufer der gesamten Rheinschleife, in dem sich auch die aktuell unter gleichem Namen befindlichen Weinanbauflächen befinden. Insofern dürfte im Moment ein place-node im Zentrum der Schleife am ehesten angebracht sein, aber da bin ich noch nicht ganz fertig.

Sorry, vergesse immer den angemessenen, richtigen Schlusspunkt:

Viele Grüße - Michael!

Hallo silversurfer83,

mir ist schon klar, dass nicht alles, was ich tue, ungeteilte Zustimmung findet. Anders herum - logisch - findet auch nicht alles, was ich in OSM entdecke, meine 100%ige Zustimmung.
Entscheidend ist doch aber, dass ein Projekt wie OSM durch ehrenamtliches Engagement vieler Leute vorangebracht wird, jeder davon mit unterschiedlicher Herangehensweise. Und "vorangebracht" nehme ich per Saldo auch ein Stückchen für mich in Anspruch.

Noch zu: "... feel free ...": Im Heckenheimer Eckweg stammt der Tag "note" von meinem Vorgänger und ist vollständig mit "feel free to change and improve" belegt. Das fand ich schon bemerkenswert, weil wir ja bei Anmeldung in OSM ausdrücklich bestätigen müssen, dass das, was wir in OSM erfassen, kein Eigentum des Erfassers ist.

Vielen Dank für deinen Vorschlag, genau so bin ich bis Mitte März vorgegangen ... und das seit mehreren Jahren: Es hatte bis dato niemanden interessiert. Mitte März 2023 allerdings wurde dann mein Account ohne Vorwarnung 14 Tage gesperrt. Es hat sich jemand - ich war zwei Tage nicht online - fürchterlich über die von dir vorgeschlagene, von mir so praktizierte Vorgehensweise der Detaillierung von landuse=vineyard-Flächen nahe Bad Neuenahr aufgeregt, dazu dann auch noch den an den Haaren herbeigezogenen Vorwurf konstruiert, dass meine Änderungen "unerlaubtes Micro-Tagging" sein würde. Jedenfalls wurden meine Detaillierungen nicht nur an dieser Stelle gleich wieder retourniert, so ein kartographisch eindeutig schlechterer Zustand wieder hergestellt. Und das vermutlich nur, weil die Einzelflächen nicht mehr unter der ursprünglichen Bezeichnung/"Markennamen" abgespeichert waren. Da fragt man sich schon ...

Die im "Heckenheimer Eckweg" vorher bereits erfassten Tags, habe ich daher 1:1 übernommen, inkl. der Botschaft "... feel free ...".

Na ja, wie immer steckt der Teufel im Detail: Die tatsächlich meist fast vollständig in den Boden eingelassenen, rechteckigen Belüftungs-/Absetzbecken könnten gut und eindeutig mit landuse=basin, basin=aeration/settling getaggt werden.

Moin,

gucke auch immer parallel, was das englische Wiki vermeldet, allerdings werden auch hier alle Optionen benannt, wenn auch eine Empfehlung Richtung man_made=strorage_tank, content=sevage abgegeben wird. Das halte ich aber auch für nicht ganz glücklich, denn in meinen Augen, stellen gemauerte, oder gegossene Becken innerhalb von Kläranlagen einen eigenständigen (Bauwerks-)Typ weltweit dar: Sie sind einzig dazu da, angeliefertes Schmutzwasser biologisch so aufzubereiten, dass das Wasser am Schluss der Kette wieder dem Frischwassersystem zugeführt werden kann. Die Becken unterscheiden sich nur in der Größe und können für nichts anderes verwendet werden. Alles andere, z.B. welche Art des Verfahrens, oder mit/ohne Drehbrücke, etc., sind nebenstehende Dinge. Die jetzt in OSM angebotenen Schlüsselkombinationen haben in meinen Augen alle mehr oder weniger den Nachteil, dass ein eindeutiges Taggen dieser Abwasseraufbereitungs-Klärbecken mMn. nicht möglich ist. mm=storage_tank/lu=basin, n=water, i.V. mit sevage/slurry/wastewater werden auch bei landwirtschaftlichen Objekten in OSM verwendet, oder sogar in Kläranlagen, wenn parallel noch Renaturierungsteiche/-becken vorhanden sind. Bisher hatte ich aber den Eindruck, dass die Kombi natural=water, water=wastewater in OSM ausschließlich bei Klärbecken angewendet wird. Klar, der Key "natural" ist isoliert für sich betrachtet zum Taggen eines gemauerten Klärbeckens unpassend, aber wenn die Kombi es eindeutig macht, wäre in meinen Augen das Ziel erreicht. Empfinde ich so wie bei building=digester: man_made wäre in meinen Augen viel passender, aber digester beschreibt es eindeutig. Insofern spielt es dann keine ganz große Rolle mehr, dass "building" vorangestellt werden muss (... sieht man von dem Stilbruch in der Argumentationskette ab).

Viele Grüße - Michael

Oh, sorry. War der Haken entfernt, kommt nicht wieder vor.

Gruß - Michael

@silversurfer83, alles gut!
@dieterdreist-CAI, stimme mit dir völlig überein.
Eine sehr "angenehme" Debatte, vielen Dank!

Hallo silversurfer83,

die L 578 ist gemäß der in Deutschland definierten Regelfahrbahnbreiten mindestens 7,5 Meter breit und durchschneidet die Waldfläche in diesem Verlauf auf einer Länge von über 300m und zwar im wahrsten Sinne des Wortes "pysikalisch". Das sind in diesem Fall zusammen mindestens 2250 m² Fläche, die vor meiner Aufteilung fälschlicherweise als landuse=forest angesprochen sind. Würde man Luftbilder aus einem Winterhalbjahr unterlegen, wäre die nicht von Bäumen bewachsene Trasse der L 578 deutlich sichtbar. OSM-highways sind Vektoren, können also keine Flächen belegen, OSM-landuse, -natural, etc ., dagegen schon und definieren diese Flächen mit konkreten Eigenschaften, wie z.B. "forest=Fläche mit Bäumen bewachsen".
Es ist offensichtlich selbstverständlich, dass u.a. OSM-Forest-Flächen entlang breiterer BAB-Trassen und anderen mehrspurigen Autostraßen immer aufgetrennt werden. Gibt es in Hinblick "Waldflächen-kreuzende" Autobahn und "Waldflächen-kreuzende" Landstraße einen Unterschied?
In meinem Verständnis kann die Frage, ob Waldflächen entlang "durchlaufender" Straßen aufzuteilen sind, eigentlich gar nicht gestellt werden.

Viele Grüße - Michael

Hallo PT-53,
das "Zeiler Saugatter", way/974350799, war in V1 als landuse=forest, inkl. der aktuellen Attribute "produce" erfasst. Die Fläche befindet sich zu geschätzt 70% innerhalb, zu geringen Teilen aber auch außerhalb der 2008 erfassten Relation 9991, landuse=forest, type=multipolygon.
Ich habe im Zuge der Aufspaltung BAB-überlappender forest-Flächen, die Zuweisung landuse=forest aus way/974350799 entfernt, stattdessen entsprechend der in V1 hinterlegten Beschreibung
"Saugatter bei Schloss Zeil als ausgewiesene Fläche hinzugefügt. Die Begrenzung ist gemäß Zaun und Wildroste. Einige Stellen waren nicht erreichbar mit GPS. Geschätzt gemäß optischen Verlauf.",
barrier=fence eingetragen.
"produce" erscheint mir auch völlig abwegig, zumal die Holzproduktion durch das darüber liegende Multipolygon landuse=forest eindeutig beschrieben ist.

Klar, das Koppeln von Flächen vereinfacht die Erfassung. Der Nachteil ist in meinen Augen, dass ein Stückchen Präzision verloren geht. Z.B. ist eine farmland-Parzelle in Deutschland immer durch einen Blühstreifen vom angrenzenden Feldweg getrennt. Werden landuse und highway zusammengelegt, wird der Blühstreifen zu landuse in OSM, also landwirtschaftliche Anbaufläche. Die Ackerfläche wird so um die halbe Fläche des angrenzenden Feldwegs vergrößert. Dazu kommt, dass benachbarte Feldflächen i.d.R. an mindestens 2 Seiten durch eine Wegeparzelle separiert sind, diese in OSM meist nicht erfasst ist.
Aber letztlich sind das Diskussionen, die schon ziemlich in das tiefste Detail gehen.

Guten Morgen,
habe mir auch deine Edits an der Stelle noch einmal angesehen und keine Kollisionen erkannt.
Die durch meine Trennung entstandenen 2 großen Forest-Einzelflächen, links und rechts der A29, müssten Multipolygone sein, weil sich innerhalb der beiden Flächen jeweils weitere landuse/natural befinden.
Ich vermeide das direkte Koppeln benachbarter Flächen. weil sich dadurch die spätere Pflege, z.B. wenn aus orchard farmland werden sollte, deutlich erschwert.