Hallo Manuel,

du solltest dir bewusst sein, dass wir sachlich solange nicht zueinander finden können, wenn du Edits von GKremp einfach so löscht, nur weil sie DIR nicht gefallen. Wenn Gkremp, aber auch andere, einen Edit "bridge:name=" erstellen, kann ich das aus meiner Sicht nur begrüßen. Es sind also zumindest GKremp und ich, also 1+1, die gegen dein Votum stehen. Außerdem, das dürfte dir klar sein, ist dieser Eintrag absolut OSM-konform: Es gibt also formal nichts(!) daran auszusetzen. Guckt man nur in der deutschen OSM-Landschaft, findet man eine ganze Menge "bridge:name=". Offensichtlich ist also "bridge:name=" ein durchaus verwendetes, wenn auch vielleicht etwas weniger bedeutsames Merkmal.
Unschön wäre vor allem, wenn ich aus deinen Löschungen im OSM-dokumentierten Ablauf betrachtend, den Eindruck gewinnen müsste, dass du es auf den OSM-Mit-Mapper GKremp persönlich abgesehen hättest. Das sollten wir in jedem Fall vermeiden.
Also: Was hast du für ein Problem mit den paar Ergänzungen?
Übrigens: Ich bin seit ca. 15 Jahren aktiver OSM-Mapper und stehe für größt-mögliche Präzison.

Hallo Manuel,
natürlich hat dieser Eintrag an Bedeutung verloren. Das heißt aber umgekehrt nicht, dass "bridge:name=" völlig nutzlos ist. Ich komme aus der IT und arbeite täglich direkt mit OSM-Datenextrakten. Wenn ich Highways, Railways selektiere, liefert mir OSM zwar Informationen darüber, welche OSM-Ways über die Eigenschaft "bridge=yes" verfügen, ich habe aber keine Möglichkeit festzustellen, um welche Brücke es sich handelt. Darüber hinaus ist es in OSM praktisch unmöglich, ein "man_made=bridge"-Konstrukt deckungsgleich zu den "darüber" verlaufenden "bridge=yes"-High-/Rail-Ways zu gestalten.
Die hier aufeinander treffenden, unterschiedlichen Objekte, produzieren eine auf den ersten Blick unnötige Datenredundanz. Allerdings wird das nur durch die Aufbereitung dieser Situation im Explorer, JOSM, etc., suggeriert. Die machen nämlich nichts anderes, als die in OSM gespeicherten Objekte geolokalisiert aufeinander zu stapeln und im Aussehen hübsch, passend zu "tunen": Die "über" ein "man_made=bridge, layer=1" verlaufenden Ways "bridge=yes, layer=1", überlagern das "darunter" liegende Objekt.
Auch wenn der pratkische Nutzen durch eine wohl eher begrenzte Verwendung von "bridge:name=" für viele OSM-Mapper vernachlässigbar bleibt, spricht auf der anderen Seite auch nichts dagegen, oder?
Viele Grüße!

Kann man nur staunen. Ich belasse es mit Sachlichkeit und dem einleitenden Satz aus dem Wiki:
"Mit bridge:name=* wird der Namen einer Brücke angegeben, wenn name=* bereits für das Hauptobjekt wie eine Straße oder eine Eisenbahn verwendet wird."

Sorry, aber das ist Unfug. Würde diese Argumentation zutreffen, wäre der Eintrag "bridge=yes", der ja bereits in dem "man_made=bridge" steckt, in den entsprechenden Vektor-Abschnitten der High-,Railways auch nicht mehr nötig.

Warum machst du diese sinnvollen Ergänzungen einfach so kaputt? "brigde:name=" ist laut OSM-Wiki dafür vorgesehen, Nebenobjekte, hier Railway-Vektoren, ebenfalls, mit dem Brückennamen zu versehen, der bereits durch ein Hauptobjekt, hier "man_made=brigde", primär belegt ist. Dieser zusätzliche Eintrag ist völlig unschädlich und wird kartographisch nicht ausgewertet.
Ich denke, du solltest diese Änderungen retournieren.
Viele Grüße

Vektor-Längen von mehreren Kilometern, hier sogar > 99 km, behindern, bzw. unterbinden eine detaillierte Erfassung, Pflege von Eigenschaften, die diesem Vektor zugeordnet werden können.
Viele Grüße!

Hallo rempshaener,

sorry, da habe ich mich nach meinem kürzlichen Besuch vor Ort vorschnell ans Werk gemacht und nicht sauber recherchiert. Ich habe den Änderungssatz gerade revertiert und den alten Zustnad wieder hergestellt.

Viele Grüße!

Hallo Seewälder,

Danke für den Hinweis! Da habe ich nicht genau genug geguckt. Die Waldgrenze ist jetzt hinter den Fußweg zurück genommen, die "Aussenbeule" verschwunden

Viele Grüße!

Hallo rempshaener,

ich kann deine Abwägungen sehr gut nachvollziehen, allerdings nicht die Schlussfolgerung: Ausgangspunkt ist ja eine möglichst präzise Erfassung von Flächen-Polygonen, die sich über gemeinsame Eigenschaften eindeutig definieren. Für Flächen-Polygone, wie z.B. „landuse=forest“, stehen weitere Sub-Eigenschaften in der jeweiligen Klasse bereit, um weiter zu differenzieren. Für forests ist dies u.a. die Art des Baumbestands. Das kann aber in letzter Konsequenz aber nur funktionieren, wenn Polygone so angelegt werden, dass die weiteren zur Verfügung stehenden Beschreibungsmerkmale auch noch angewendet werden können. Im ersten Schritt erscheint es mir notwendig, dass Polygone nur solche Flächen überspannen, die tatsächlich die grundlegenden Eigenschaften aufweisen, über die OSM-Polygone definiert sind. In Deutschland beträgt die gesamte Trassenbreite von 2-spurigen Landstraßen laut Norm 9,50 Meter, im Fall der L 35 kommt einseitig über die volle Länge noch ein Rad-/Wanderweg hinzu, der die effektive Trassenbreite auf mindestens 11 Meter anhebt. Die L 35 durchzieht das Mühlenbusch-Wald-Areal über eine Länge > 950 Meter. Multipliziert mit der Trassenbreite von 11,0 Metern, ergibt sich eine Fläche > 10.000 m², also 1 Hektar(!), die vor Aufteilung der Einzel-Fläche in meinen Augen fälschlicherweise der Landnutzung „landuse=forest“ zugeschlagen war und beantwortet die Frage, ob aufgeteilt werden sollte, oder nicht.
Dass jetzt über die 2 separierten Flächen jeweils einmal "Mühlenbusch" auftaucht, ist in meinen Augen dagegen weniger bedeutend. Weit besser wäre es von vornherein ohnehin gewesen, den Namen "Mühlenbusch" über einen separaten Node, oder, wenn es denn wirklich nötig ist, ein separates Polygon "place=locality" zu setzen, statt einen künstlichen Konflikt durch Kombination mit einer landuse-Fläche zu erzeugen.

Viele Grüße!

Guten Morgen,
das ist schon ein paar Tage her, vermutlich habe ich zum Zeitpunkt der Änderung primär den bis Ottbergen eingleisig verlaufenden Ast der Strecke Paderborn-Göttingen im Auge gehabt.

Hallo habi,
Danke für den Hinweis, da habe ich wohl einen schlechten Tag gehabt. Die buildings sind auf "shed" korrigiert.
Viele Grüße!

Hallo ayxis,

oh wei, das ist jetzt über 8 Monate her. Ich bilde mir ein, dass ich da über etwas auf der östlichen Seite gestolpert war und daraufhin diese "schöne" Ausarbeitung gemacht habe. Kann es aber selbst nicht mehr nachvollziehen.
Jedenfalls hast du Recht: Wäre so nicht nötig gewesen.

Hallo habi,

daran kann ich mich sehr gut erinnern, schließlich ist die deutsche Community zu guter Letzt meiner Argumentation gefolgt. Diese Debatte steht im Übrigen nur beispielhaft für das Thema landuse in OSM.

Hallo habi,

sorry, da hätte ich den Changeset-Kommentar aktualisieren sollen.
Im Zuge einiger Korrekturen, die ich an der Außenlinie von relation/16249776 durchgeführt hatte, bin ich in die vineyards gelangt.

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.