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
Gruß Miche
PS: “Multipolygon des Grauens” wäre ein schöner Neuer Forumtitel neben “Kurioses”
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…
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.
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”.
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…
@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.
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…
@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.
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.
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.
Dem kann ich nicht folgen. Wenn auf einem Bauernhof eine gepflasterte Fläche ist, auf der der Landwirt mal seinen Traktor abstellt, mal dort einen Anhänger mit Heu ablädt, mal seine Kühe von einem Stall in den anderen treibt, was ist daran keine Bauernhofnutzung? Nur weil dort auch - wenn nicht gerade ein Traktor im Weg steht - dort der Postbote sein Fahrzeug abstellt? Oder weil vielleicht der Landwirt Wanderern gestattet, seinen Hof zu queren, obwohl es kein öffentlicher Grund ist?
Und was Einfamilienhausgrundstücke nimmt: Was ist denn Wohnnutzung, wenn die darauf angelegt private Zufahrt zur Garage keine Wohnnutzung ist? Auch der Gemüsegarten, auch der Spielrasen, auch der Vorgarten, auch das Carport oder die Garage wären dann keine Wohnnutzung. Was bleibt dann übrig? Das Haus. Vielleicht noch die Terrasse…
Die Fußgängerzone kommt in OSM als Fußgängerlinie daher.
Die Kirchtürme des Westwerks sind externe Gebäude.
Nebenbei: Du mappst residentials nach den örtlichen Schneeräum-usus? Und wenn die Gemeinde Satzung oder Vorgehen ändert, dann mappst Du das residential um, oder wie muss man sich das vortstellen. Also da würde ich dir stattdessen zur langlebigen Gartenzaun-Grenzziehung bei residentials raten.
Nein, nicht negativ, das hört sich zu negativ an.
Sagen wir mal so: die Darstellung einer Verkehrsfläche, die offensichtlich bis an die umgebenden Gebäudekanten reicht,
durch eine Linie die irgendwo zwischen den Gebäuden hindurchführt,
wobei beachtliche durch nichts definierte Hintergrund-Restflächen mitten im Ortskern entstehen, ist
suboptimal.
(Sollte dies der Angst geschuldet sein, Dinge in der Fußgängerzone, wie landuse=grass nicht mehr dargestellt zu bekommen:
dies ist durch vernünftige Stückelung der Fläche, sinnvollerweise an den Wechseln des Oberbelags, möglich - ganz ohne Multipolygone.
Die bisherigen highway=pedestrian-ways können als highway=servive über highway=pedestrian + area=yes führen.)