I don't conceal "fictional spaces" by wrongly enlarging a neighbouring area, just as I don't produce agricultural "meadow" areas that are oriented in a mirror image of a forest multipolygon oriented over the treetops. There is no such thing in reality!
What should be the result if I query land use via OSM?

I do not generate fictional spaces between landuses! I generate real landuses, but I don't fill spaces between two areas by arbitrarily enlarging one or the other area just to avoid gaps to the neighbouring area. landuse specifically assigns a real area to a use! Vines should only grow where this is the case in reality. Nobody (almost) comes up with the idea of connecting vineyards to the left and right of a motorway, or forests across the motorway, just to avoid the existing space between motorways.
I also don't orientate forest areas to summer treetops, nor do I use thousands of nodes or an endless number of multipolygons just to be able to use a single way in several relations, even if the orientation of the way is then no longer correct in one relation. And anyway: These sub-multipolygons are largely not closed and can no longer be maintained at all. The question of the extent to which further multipolygons may be contained within a multipolygon, which on their part are arranged in a featureless closed way, inner member in the outer multipolygon, is still open.
These large-area constructs need to be completely reorganised.

When recording multipolygons, the individual ways contained in the multipolygon as outer-, or inner- segments must be arranged in the correct order. If that will be correct, the relation editor in JOSM shows a closed rectangle in which all related ways are located.
https://josm.openstreetmap.de/wiki/Help/Action/CreateMultipolygon

Ways are defined as vectors in OSM and therefore have a “direction”. It is always good for subsequent processing if the individual ways, which together form a closed multipolygon outer line, all have the same direction. However, this is not possible when using ways that are assigned to several multipolygons at the same time. In addition, the isolated maintenance of individual polygons in OSM is made much more difficult.
The principle should always be Keep it small and simple

Sorry, but it's a fact: The currently downloaded relation/3105910 is not closed in all segments.

relation/3105910 is currently broken and not closed. This can be easily checked with JOSM. In addition, there are various other problems, e.g. landuse/natural areas located within the outer multipolygon 3105910, which are also recorded as multipolygons. In addition, there are the differently aligned ways within the outer line of relation/3105910.

This multipolygon is completely broken. Just have a look at the processing in the relations editor. The sub-segments of the outer and inner lines are aligned differently, and some of them are directly connected to adjacent ways. Maintaining such large structures is practically impossible.

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