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

Die Idee dahinter ist ja nicht schlecht, da wollte jemand den Odenwald komplett als ein Waldgebiet dargestellt haben. Doch hat ja die Diskussion hier: https://forum.openstreetmap.org/viewtopic.php?id=64923 gezeigt, dass es dafür bessere Möglichkeiten gibt, als ein landuse-multi-Poligon. Ich möchte hier nur eins einwerfen: Bei landuse=forest ist ja u.A. vorgesehen, die Baumart anzugeben. Nadelwald, Laubwald und Mischwald werden dementsprechend in der Standartkarte auch unterschiedlich dargestellt, Wenn man das umsetzen möchte, muss man Waldflächen entsprechend der Bestandsflächen sehr kleinflächig eintragen.

Damit entfällt zwar die Notwendigkeit, den gesamten Odenwald als ein Objekt zu erfassen, an Multipolygonen kommt man trotzdem nicht vorbei. Zumindest habe ich für solche Fälle in diesem langen Faden, in dem zur Abstimmung gestellten Empfehlungen und auch nicht in Frederiks Checkliste keinen Hinweis gefunden, wie man solche Situationen ohne MP in OSM abbilden kann. Vielleicht kann das mal jemand beispielhaft an dem Gebiet zwischen St2311, MIL7 und der Verbindungsstraße Würzberg-Hesselbach machen.

Ach, wo denkst Du hin :wink:

https://www.openstreetmap.org/relation/3957497 ist eine Insel mit 460.000 Punkten.

Insgesamt gibt es rund 50 Polygone mit mehr als 100.000 Punkten (Grenzen dabei nicht mitgezählt). Auf den ersten Blick scheinen mir die meisten davon Seen oder Inseln zu sein, der größte Wald ist

https://www.openstreetmap.org/relation/8319625

mit 280.000 Punkten. Da kann schonmal der Lüfter im Laptop hochdrehen, wenn man die URLs anschaut :wink:

Bye
Frederik

Mein Laptop stand kurz vorm explodieren… :stuck_out_tongue:

Hallo Zusammen,

klammert man mal eine mögliche Namensverwendung aus, welche Gründe könnte es denn dann noch geben z.B. ein Landuse-MP (als type=multipolygon) mit mehreren in sich geschlossenen Outer-Rollen anlegen zu müssen? Mir fallen keine ein…

Das ist genau der Hintergrund, daß OSM diese Möglichkeit zum detailierten Mapping bietet und ich sehr dafür bin, dies auch zu nutzen… Sehr oft sind noch MP’s anzutreffen, wo nichts detailiert ist… man gerade ist ein See als inner vorhanden, nicht aber ein am See angrenzender Moor-Bereich, mit ggf. Bruchwald, ect… Da funktioniert das mit dem Namen am MP oft nicht mehr, da nach detaliertem Mapping aus einer erfassten Waldfläche gerne mal 2,3 oder 4 werden können… Die Namensgeschichte muß in meinen Augen in einer völlig separate Datenebene sein.

Es geht doch nicht darum einen Weg völlig ohne MP’s zu finden. Es geht darum, daß diverse Dinge, die bisher als MP erfasst worden sind, dafür aber unnötig sind und simple Flächen (geschlossene Linienzüge) ausreichen und daß übergroße und nicht mehr händelbare MP’s verhindert werden.

Sven

Gerade gefunden: wofür meiner Ansicht nach MP’s nicht gedacht sind:
https://www.openstreetmap.org/relation/9187648
da wäre type=site besser… habs mal kommentiert…

Sven

Richtig, es geht darum, die Größe von (Landuse-)Flächen auf ein handhabbares Maß zu beschränken, so dass man sie nicht in MPs zu packen braucht oder nur MPs überschaubarer Größe bilden muss.

Da kommt man auch ohne site aus, weil zur Siedlung sicherlich auch die Gärten zwischen den Häusern gehören :wink: Also einfach einen RIng um das Ganze und place=neighbourhood dran…

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