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

<nicht_ernst_gemeint>Wenn wir das konsequent durchziehen, lässt sich DE komplett abdecken, sogar in mehreren Hierarchiestufen.
Ich nehme als Beispiel den Schwäbischen Wald mit den Untergliederungen Schurwald, Welzheimer Wald, Murrhardter Wald und noch einige mehr.</nicht_ernst_gemeint>

muß ich mal bei Gelegenheit schauen… Hier ist es ja auch so… der Muskauer Faltenbogen ist eine spezielle geologische Formation die man mindestens als Linie mit natural=ridge erfassen könnte (um ein Minimum zu erfassen)… er ist auch ein geologischer Park (meines Wissens grenzübergreifend) deren Grenze ohnehin noch fehlt… Das ist auch eine Bereich, der durch Detailtagging stark strukturiert wird.

Diese “Namensproblematik” ist meines Erachtens das einzigste, womit User ein MP mit mehreren Outern begründen wollen… Letztendlich ist es aber so, daß man das in der Regel immer mit anderen Tag erfassen kann… allein eine einheitliche Erfassung fehlt… (ich vermute mal die Regionen) oder die Doku ist unvollständig oder fehlend… siehe oben…

Sven

Doch das kann man durchaus ernst meinen… wenn man sich solche Namensproblematik im Detail betrachtet, kann man durchaus zu diesem Schluss kommen, daß es auch mein den Namen lokal zu Hierarchen kommen kann (nicht muß)

Sven

der ins Bett muß (!)

Bei der aktuellen Witterung -Schneefall- zeigt sich, dass in OSM erfasste Straßengrenzlinien sehr sinnvoll sind. Unsere Schneeräumung ist mit gps.at Equipment unterwegs. Das primäre Kartenmaterial hierzu stammt aus OpenStreetMap.
https://www.tt.com/panorama/wetter/15189206/winter-hat-tirol-im-griff-mitte-der-woche-droht-lawinenwarnstufe-5

Oder man handhabt das so wie beim ÖPNV, zumindest von der komplexen Datenlage. Dort werden die Varianten die alle für sich vollständig getaggt sind durch ein “route_master” zusammengefasst. Um die Zusammengehörigkeit auch nicht nur über ref= usw. darzustellen. Alles in einer Relation darzustellen geht schon gar nicht mehr. Durch das vollständige Tagging ist auch sichergestellt das Software die “route_master” nicht versteht trotzdem noch die Daten verarbeiten kann.

Wenn man das auf eine Wald anwendet wäre jeder an natürlichen Grenzen abgetrennter Waldteil ein Multi-/Polygon “möglich”… welches über ein (Master|Super)-Relation zusammengefasst wird.

  • Software könnte trotz alle dem die Gesamtgröße erfassen…
  • die Namensproblematik wäre auch händelbar und
  • die Mapper hätten kleinere Multipolygone
  • Software die damit nicht arbeiten kann würde gegebenfalls “nur” mehrmals einen Namen Rendern (was manchmal aber auch nicht schlecht sein kann)… oder früher ausblenden…

Bleibt nur zu definieren ab wann ein Multipolygon ein “Multipolygon des Grauens” ist :wink:

Gruß Miche

PS: “Multipolygon des Grauens” wäre ein schöner Neuer Forumtitel :laughing: neben “Kurioses”

→ zu ÖPNV Beispiel http://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html

Ja natürlich. Korrektes Tagging wäre allerdings area:highway zu diesem Zweck zu nutzen.

Das fände ich gar nicht toll…

Letztendlich sind inhaltlich die Waldnamen mit Namen von Regionen und Landschaften, ect. thematisch verwandt, genauso, wie ich z.B. natural=ridge oder place=locality thematisch dazuzähle… Man muß sich ja auch gewiss sein, daß sich solch ein Name nie scharf abgrenzen lässt. Hier sollte man es möglichst einfach halten und nicht mit der nächsten MP-Keule (geschachtelte MP’s) anfangen… Eine einfache Umgrenzungslinie mit den entsprechenden Tags ist da besser…

Sven

Sollte man aber besser nicht ernst nehmen. Damit schafft man Hierarchien, die noch weniger verständlich und noch schlechter zu editieren sind, als die MPs. Schließlich weiß man nie, ob noch irgendwo eine Super-super-super Relation rumfliegt, die man übersehen hat und die noch was an dem Objekt ändern würde. Z.B. die noch einen weiterne Namen beisteuert - natürlich alle mit demselben name-Tag.

Und nachdem eine Super-Relation auch ohne Probleme Mitglied in mehreren Super-Super-Super Relationen sein kann, können wir noch mehr Tags sparen, indem wir unterschiedlich Zusammenhänge auf verschiedene Super-Super Relationen aufsplitten. Und wir können endlich mehrfache Bedeutungen abbilden indem wir das Haupttag in die Super-Super-Super Relation tun und unterschiedliche Nebentags dazu in die Super-Super Relation.

Im Ernst, es gibt einen Grund warum Mehrfachvererbung aus modernen Programmiersprachen wieder verschwunden ist. Aber wir können alle Fehler der Vergangenheit mit Hilfe von Relationen bei OSM nachbilden. :slight_smile:

Relationen an sich sind frei, können alles beinhalten.
Bei MPs allerdings sind zum Glück keine Verschachtelungen erlaubt.

Zusätzlich? Wenn ja dann bin ich dagegen…

Manche nicht, manche schon… weil es ensprechende Unterlagen gibt… da viele Namen schon sehr alt sind… teils aus dem Mittelalter… und dort aus Beschreibungen resultieren… z.B. Das Waldstück östlich der Ortschaft “A” in Richtung “B” um den Grundbesitz zu verwalten. Von damals gibt es noch ganz ganz viele Namen… für Wald, Wiesen, Äcker, Seen, Flüsse, Gräben, Sümpfe die wenigsten sind jetzt schon eingetragen. Da kann man noch lustig MP bauen um diese Darzustellen…

In Bebauungsplänen sind Straßen keine Wohnnutzung, auch nicht die “Wohngebietsstraßen”.

die Flächen sind zumindest von der Nutzung ausgenommen, d.h. dort würde keine Bauernhofnutzung stattfinden oder keine Wohnnutzung. Wir mappen ja normalerweise keine Grundstücke (bisher), von daher auch keine Wohngrundstücke sondern Flächen wo Wohnnutzung stattfindet.

Es gibt bisher keine weitere Dokumentation, inwieweit man Nebennutzungsflächen, Wege usw., ausschließt oder getrennt mappt, was wo dazugehört und was nicht, etc., von daher würde ich die geschilderte Art des Mappens zwar unüblich sehen, aber nicht zwangsläufig “falsch”.

ja, würde ich hier auch genau so sehen.

Du kannst es dir aussuchen, entweder zombihafte, geschachtelte MP’s mit einem weiteren Kompliziertheitsgrad (denn wir ja eigentlich nicht wollen) und das “nur” wegen Namen, oder eine Umgrenzung als separate Datenebene, die den Bereich mit der Namensgültigkeit abdeckt…
Mir fällt da keine andere Lösung ein…

Ja gut, man soll in dem Fall “nie” vermeiden… aber eine scharfe Abgrenzung ist auf Basis alter und sehr alter Informationen oft nicht mehr möglich… und MP’s dafür will ich auf keinen Fall bauen, wenn es nicht aus technischen Gründen zwingend nötig wäre…

Sven

@Streckenkundler: Schon beim Deister würdest Du mit einem einfachen Outer nur des Namens wegen wahrscheinlich an die 2000-Nodes-Grenze stoßen. “Man” könnte sich natürlich auch mit einem stilisierten Mehreck begnügen, an dem der Name aufgehängt wird. Aber das ist den meisten hier wohl zu pragmatisch gedacht. :sunglasses:

Ich würde ja hier auch pragmatisch denken… Aber aus dem Grunde erwähnte ich ja die technischen Gründe (2000-Nodes-Grenze). Wenn ich die Lieberoser Heide versuchen würde abzugrenzen würde ich sicherlich auch an die 2000-Nodes-Grenze kommen… Hier hab ich aber die Schwierigkeit eine hinreichend valide und nachvollziehbare Grenze ermitteln zu können… Es gibt hier viele Ecken, da kann ich nicht ohne weiteres sagen, ob man diese hinzuzählen kann oder nicht…

Sven

@Pfad-Finder
“stilisiertes Mehreck”, da hätte ich kein Problem mit. Warum mehr Nodes als dafür nötig. Müssten uns nur noch auf einen gemeinsamen Standard für diese “Umgrenzung” einigen.

Hier auch nochmal ein Multipolygon, welches als Mapper nett zu bearbeiten ist, weil man in einer Relativ großen Zoomstufe den kompletten Rand abgehen muss, bevor man etwas daran ändern darf…
https://www.openstreetmap.org/relation/3339472#map=13/52.6725/10.6721
(Dank des Elbe-Seiten-Seitenkanals ist das Teil Gott Sei Dank nicht noch größer…)

Warum eigentlich nicht?

area:highway ist für mich nicht ausreichend, ich habe eher die Perspektive der Schneeräumung
https://www.openstreetmap.org/way/247540379


wo befindet sich die Grünfläche, und wo der befestigte Vorplatz zur Kirche.

Zwei weitere Beispiele:
https://i.imgur.com/Mxzns8b.jpg
https://i.imgur.com/H8i4WBn.jpg
Ich löse das daher in St. Johann in Tirol so, dass ich auch den Pfad zur Wohnungstüre, der zwar nicht öffentliche Straße ist, aber dennoch im Winter geräumt wird, von residential ausspare.

Der hierbei in Bezug auf Multipolygone angenehme Nebeneffekt besteht darin, dass aufgrund der Separation durch den Gehweg zur Haustüre, daher nur kleine residential Polygonstrukturen enstehen. Kleine Strukturen sind leichter wartbar, und auch nicht so Fehleranfällig.

Ich befürchte, dass Du eher die Perspektive “Mappen für den Renderer” hast, weil auf der Standardkarte das Klein-Klein nicht dargestellt wird.
Es bleibt jedem unbenommen solche Details mit geeigneten tags zu beschreiben. Die Gruppe um “area:highway” hat das völlig richtig gemacht und das Ergebnis entsprechend visualisiert: http://www.osmapa.pl/w/areade/?lat=48.22028&lon=11.58863&zoom=18&ol=BPN . Landuse dafür zu Missbrauchen um befestigte Flächen zu sehen finde ich anderen Datennutzern gegenüber nicht nett.

Ich finde wir brauchen ganz dringend ein Tagging für mögliche Dachlawinen! :sunglasses:

Noch einmal: Das Aussparen von befestigten Flächen aus landuse=residential macht keinerlei Aussage darüber, ob es sich dabei um eine befestigte Fläche handelt oder irgendetwas Anderes. Es macht allein die Aussage, dass diese Fläche nicht Teil eines Wohngebiets bzw. eines Wohngrundstücks ist.
Um befestigte Flächen einzutragen, muss man eine Fläche mit passenden Attributen einzeichnen. Und nur wenn diese im Widerspruch zu dem landuse=residential steht, muss sie dort ausgespart werden.

Aber davon ab: Ich glaube kaum, dass ein Winterdienst in einer OSM-Karte nachschaut, wo er den Schnee abladen kann. Das wird nach Augenschein oder Absprache entschieden. Davon ab: die frei zugängliche Grasfläche neben einer Straße ist dazu mindestens ebenso geeignet wie ein befestigter Kirchvorplatz.

Ich habe den Eindruck, Du willst hier um jeden Preis Argumente für Deine Taggingpraxis finden, die zwar den einschlägigen OSM-Wikiartikeln widerspricht, aber aus Deiner Sicht schön aussieht und in deren Umsetzung Du schon sehr viel Arbeit gesteckt hast.