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

Naive Frage: Gibt es evtl. eine sinnhafte Möglichkeit, in einem solchen Fall analog zu “Superrouten” bei Fernwanderweg-Relationen eine Art “Super-MP” anzulegen, das Teil-MPs/-Teilflächen zum einem Konstrukt namens “Odenwald” kombiniert und dann - was offensichtlich von einigen hier gewünscht wird - auch in den gängigen Renderern als “Odenwald” angezeigt wird?

Ich würde dafür im Moment boundary=region nutzen… ggf. Bei Bedarf auch als Relation… Eventuell sollte das auch auf mittel- bis großflächig definierte Wald- oder Offenlandbereiche spezifiziert werden.

Sven

Super-Relationen sind vom Syntax her erlaubt, sind für diesen Zweck hier aber mMn unnötig.
Der Odenwald ist kein “Wald” sondern eine Landschaft, eine Region.
Auch wenn ich diese Gebilde nicht besonders liebe: Eine Grenze um das Gebiet mit
boundary=natural & natural=mountain_range o.ä. & place=region & name=Odenwald & … tut es auch (Beispiel: Schwäbische Alb).

Ob ein Renderer das dann anzeigt, ist seine Sache, mit Relationen von Relationen tut er sich ziemlich sicher aber auch schwer.

boundary=region (-> streckenkundler) geht auch, das Problem mit den “weichen Grenzen” ist dasselbe.

Ja, das ist richtig… In meinen Augen sind solche Grenzen immer weich…

boundary=natural gefällt mit in dem Kontext auch… (ist leider bisher nicht dokumentiert (?) ) Vielleicht fällt uns anstatt natural=mountain_range was spezielleres für Waldgebiete ein, es nicht mit im Kontext mit Berglandschaften steht… Dann haben wir auch für die Namensgeschichte eine Lösungsvariante…

Sven

Danke für den Hinweis. Damit ließe sich zum Beispiel schon mal der Deister im SW von Hannover behandeln.

Der Odenwald ist übrigens auch kein “Wald”, sondern ein Bergland.

@Streckenkundler: Ich meine mich erinnern zu können, dass der Muskauer Faltenbogen auch mit einer komischen Box überzogen war/ist, die den Namen auf Deutsch und Polnisch transportiert.

<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.