DE talk:Relation:multipolygon

Insel in einem Loch

Siehe Diskussion, der Abschnitt muesste klarer formuliert werden. http://forum.openstreetmap.org/viewtopic.php?id=54667 -User:Gppes 2016-05-21, 19:30 Uhr (CET)

Die Beschreibung zu Bild 7 ist falsch. Ob man die "Kaskade" braucht hängt von ganz anderen Eigenschaften ab:

Die Eigenschaften der von Linie 1 umschlossenen Fläche (also der Gesamtfläche) werden an die Linie 1 geschrieben.

Die Eigeschaften der von Linie 2 umschlossenen Fläche (weiss plus inneres grau) werden an diese Linie 2 geschrieben.

Die Eigeschaften der von Linie 3 umschlossenen Fläche (inneres grau) werden an diese Linie 3 geschrieben.

Die Eigenschaften der äußeren grauen Fläche werden an ein MP mit outer=1 und inner=2 geschrieben.

Die Eigenschaften der gesamten grauen Fläche werden an ein MP mit outer=1 und 3 und inner=2 geschrieben

Die Eigenschaften der weißen Fläche werden an ein MP mit outer=2 und inner=1 geschrieben.

Ob man also für die weiße Fläche ein MP braucht oder nicht, hängt nur davon ab, ob man die weisse Fläche beschreiben will. Es hat nichts damit zu tun, ob das innere und das äußere grau gleich oder verschieden sind.

Bei der ganzen Sache wird übrigens nichts "kaskadiert". jede Fläche wird ohne Rücksicht auf die Existenz der anderen nur gemäß ihrer eigenen Form beschrieben. Es wäre doch widersinnig, die Multipolygonregeln für ein Objekt zu ändern nur weil irgendein anderes Objekt auch noch in der Gegend ist.

--Weide 20:09, 25 Jan 18

Nachdem ich auf die gleiche schlechte Formulierung hereingefallen bin, habe ich den Abschnitt umformuliert. Der zuvor beschriebene Shortcut ohne zweites Multipolygon funktioniert nicht, bzw. nur dann, wenn man die weiße Fläche nicht beschreiben will. Der Use-Case existiert de-facto nicht und sollte hier nicht als Empfehlung gegeben werden. Limes12 (talk) 15:11, 4 August 2023 (UTC)

Forderung nach Umordnung

• Die Schritt-für-Schrittanleitung sollte in De:Relations eingearbeitet werden. Hier dann nur noch Hinweise, die direkt die Multipolygone betreffen. --Elwood 18:38, 8 August 2008 (UTC)

da sehe ich heute deinen Eintrag und dann hat er sich ja schon erledigt. Danke fürs Anpassen!

Allerdings muss ich wohl so ein paar Dinge ändern zwecks den sogenannten Umgehungslösungen. --Crissiloop 09:54, 14 August 2008 (UTC)

---

Was ist mit Bezeichnungen von Multipoligonen?

1. damit man verschiedene Multipoligone in den Listen auseinander halten kann
2. um Bezeichnungen von Objekten durch zuführen
   • zb bei Inseln im Fluß wenn sie einen Namen haben
   • aber muss jede Insel einen Namen tragen? manchmal möchte ich nur durch eine Notiz an das Multipoligon hinweisen was es it...

--cptechnik - DE:NRW:Windeck (talk) 16:02, 3 August 2013 (UTC)

Sich berührende innere Ringe - Wat nun??

im Beitrag steht

In "OGC Simple Feature Standard" ist diese einfache Möglichkeit nicht vorgesehen, dort sind sich berührende innere Ringe nicht erlaubt. Stattdessen wäre zunächst in den Wald ein Loch zu zeichnen und in dieses dann die einzelnen Polygone für See und Farmland.

In OGC Simple Feature Standard ist das selbstverständlich vorgesehen: ... A MULTIPOLYGON is valid if and only if all of its elements are valid and the interiors of no two elements intersect. The boundaries of any two elements may touch, but only at a finite number of POINTs. ...

Zudem steht weiter oben:

Sich berührende innere Ringe sind jedoch gültige Multipolygon-Relatione.

Was nun, das eine oder das andere?

--Jo (talk) 18:45, 22 July 2015 (UTC)

Die inneren Ringe/Polygone haben eine gemeinsame Kante/Gerade und Schneiden sich damit in unendlich vielen Punkten, dieser Fall ist also NICHT erlaubt.

--W 14:53, 2 October 2015 (UTC)

Hier duerfte es sich um einen Uebersetzungsfehler aus dem Englischen handeln. Dort wird OGS und OSM verglichen. Bei OGS ist es nicht erlaubt, bei OSM schon. Der mathematischen Sichtweise von User W kann ich somit nicht zustimmen.

--User:Gppes 2015-12-03, 00:05:52 Uhr

Ich schließe mich W an, überlappende Linienzüge innerhalb eines Multipolygons gibt auch die OSM Spezifikation nicht her. Der Grund ist folgender Satz:

The boundaries of any two elements may touch, but only at a finite number of POINTs.

Dürfen sich an einer endlichen Menge von POINTs berühren. schließt das Berühren an gemeinsamen Kanten/Linienzügen KLAR AUS.

POINT bezeichnet definierte Punkte, nicht irgendwelche. Zudem unterstreicht finite (endlich), dass ein Berühren in unendlich (infinite) vielen Punkten unzulässig ist. Gemeinsame Kanten/Geraden berühren sich aber an/in unendlich vielen Punkten.

Dieser Satz erklärt, dass ein Berühren von Flächengrenzen _nur_ in POINTs, also in Punkten, welche die Flächengrenzen definieren, zulässig ist. Leider ist diese Regel dennoch keine gute Idee, denn sie macht Backtracking bei der Zusammensetzung von Ringen nötig und ermöglicht mehrere Arten einer Zusammensetzung, wenn auf die Rolleninformation kein Verlass ist.

--Cmuelle8 (talk) 19:45, 12 January 2016 (UTC)

Dann sollte aus meiner Sicht auch das Beispielbild im entsprechenden Abschnitt falsch sein. Finite heisst auch begrenzt, nicht nur endlich. Weiters ist mir unklar wieso der Sachverhalt "mathematisch" definiert sein sollte, es waere dann ja einfacher zu sagen, dass die Grenzen nur sporadisch aus einzelnen, gemeinsamen Nodes, nicht aber aus gemeinsamen Ways bestehen duerfen. Es waere schoen, wenn dieses Missverstaendnis (was auch immer richtig ist) klargestellt wird.

--User:Gppes 2016-01-12, etwa 20:00 Uhr

Ja, absolut - das Beispielbild (und die Daten dazu) entspricht nicht der Spezifikation. Das Szenario dort ist aber einfach zu ersetzen, so dass es die Spezifikation erfüllt - ohne dass sich POINTs verschiedener Grenzen überhaupt innerhalb eines Multipolygons berühren müssten.

Ich finde, der Sachverhalt ist mathematisch definiert, aber in einfachem Englisch dargestellt, was zur Fehldeutung führen kann. Insbesondere, wenn die Bezüge nicht beachtet werden: Der Satz stellt ja nur durch die Großschreibung POINT sicher, dass Bezug auf bestimmte Punkte genommen wird und nicht beliebige.

--Cmuelle8 (talk) 20:30, 12 January 2016 (UTC)

Also: Der Fehler ist im deutschen und englischen Wiki, auch der josm gibt hier keinen Fehler aus, und die "richtige" Variante, innerer Ring um die beiden Flaechenfeatures insgesamt herum sieht man nur selten. Wenn trotz alledem so ist, sollte es zumindest in beiden Wikis dringendst korrigiert werden, ich trau mich da aber keinesfalls drueber.

--User:Gppes 2016-01-12, 21:00 (UTC)

Nun ja, da bereits Code geschrieben wurde, um auch diese hässlichen Fälle zu handhaben, wäre erstmal zu fragen, welche Datenkonsumenten dadurch tatsächlich negativ beeinflusst sind.. Gibt es denn Fälle/Software (außer josm), die mit derartigen multipolys nicht klarkommen? Ich weiß nicht, seit wann das schon so in den Beispielen steht (Versionsgeschichte crawlen..), falls es Jahre sind, dann ist es sicher nicht so dringend das abzuändern. Bzgl. Validierung in JOSM: Der Editor müsste zumindest überlappende Wege melden, als Warnung.

--Cmuelle8 (talk) 21:34, 12 January 2016 (UTC)

Bei josm kein Fehler, gerade noch einmal ausprobiert. Ich habe es bist jetzt auch immer falsch gemacht und validiere immer. Die alternative Methode ist doch aufwendiger und man kriegt noch mehr Ways auf Ways. Hat man eh schon so oft genug, steh ich nicht so drauf.

--User:Gppes 2016-01-12, 21:45 (UTC)

Alternative zu Beispiel 8, die nicht gegen die Spezifikation verstößt, aber dennoch berührende Ringe enthält

Nicht, wenn du die inneren Flächen auch als MP mappst - dann gibt es (für dieses Beispiel) genau 4 Flächengrenzen, also auch nur 4 Wege und kein Einziger davon überlappt. In Kürze: A drücken, 4 Wege zeichnen (Alt/Shift um neue Wege zu beginnen), dann 3x (Flächengrenzen auswählen, Strg+B, tags setzen). Häufig merkt man beim Auswählen der Flächengrenzen, ob der Umriss schlüssig ist. Einzelumrisse zu zeichnen und die zu taggen funktioniert aber offenbar auch. Gruß --Cmuelle8 (talk) 23:02, 12 January 2016 (UTC)

Man lese im Übrigen die Hinweise unterhalb der anderen Beispiele (die nicht meiner Edits wegen im Artikeltext enthalten sind):

Der innere Ring darf den äußeren höchstens in einem Knoten (Punkt) berühren!
Die äußeren Flächen (Linienzüge) dürfen sich höchstens in einem Knoten (Punkt) berühren!

Diese Hinweise unterhalb von erstem und viertem Beispiel interpretieren die Spezifikation imho richtig, während das achte Beispiel gegen die Spezifikation verstößt. Es ist aber sicher nicht verkehrt vor der kompletten Streichung dieses Beispiels in beiden Sprachvarianten, mal auf den Mailinglisten durchzuklingeln, um weitere Meinungen zu hören.

--Cmuelle8 (talk) 01:06, 13 January 2016 (UTC)

Das mit den verschachtelten MPs (schoenes Bild von Dir!) ist mir klar, aber ich glaube das sind auch die MP-Varianten, wo es zu unten angesprochenen Renderproblemen kommen kann. Unabhaengig davon bin ich auch von dieser Loesung persoenlich wenig begeistert, weil es komplizierter ist, als der "verbotene" Weg. Wo kann man die OSM Spec eigentlich lesen? Ich habe gestern zwar gesucht, aber war mir nicht sicher, ob ich die richtige Spec gefunden habe. Ich wuerde gerne das dort noch einmal schwarz auf weiss sehen, weil ich nach wie vor zweifle, ob die Geschichte mit den beruehrenden Ringen wirklich verboten ist. In ein Forum damit zu gehen halte ich fuer eine gute Idee!

--User:Gppes 2016-01-13, 07:04 (UTC)

Nein, Renderprobleme schafft diese Variante unter Garantie nicht, den Glauben kann ich dir nehmen :)

Ich würde in diesem Zusammenhang auch nicht von Verschachtelung sprechen, da jede Fläche für sich steht und unabhängig bearbeitet und gerendert werden kann. Und geographisch betrachtet existiert eine Verschachtelung unabhängig von der Art der Repräsentation.

Die im Bild 8a (hier am Rand weiter oben rechts) aufgezeigte Variante sichert, falls sich eine gemeinsame Flächengrenze ändert, dass sich stets auch die beteiligten Flächen ändern. Anders ist das bei der "verbotenen" Variante (gut, dass du das in Anführungszeichen gesetzt hast, denn es ist nicht wirklich verboten, ungültige MP in die DB einzutragen). Ändert sich hier die Flächengrenze zwischen See und Acker (etwa durch Landgewinnung), sind zwei Flächengrenzen anzupassen, die aber an der Stelle ihrer Überlappung ein und dieselbe Grenze repräsentieren - dabei kann "Totland" entstehen:

• JOSM wird zwar einen neuen Knoten auf überlappenden Wegen üblicherweise beiden Wegen hinzufügen, womit die Verschiebung dieses Knotens auch die Verschiebung beider Wege bewirkt, aber es gibt auch Mapper, die absichtlich "Totland" schaffen, um besser den einen oder anderen Weg auswählen zu können.
• Andere Editoren könnten aber neue Knoten auf überlappenden Wegen nur einem der beiden Wege hinzufügen. Das wäre übrigens auch in JOSM der Fall, wenn z.B. nur Farmland oder See heruntergeladen wurden (was nicht unwahrscheinlich ist..)

Auf die Überlappung als Repräsentation der Wirklichkeit ist dann oft kein Verlass mehr. (Totland meint hier nicht den Ort auf der Isle of Wight.)

Es ist auch möglich MP-Objekte in ganze vier Gültigkeitsklassen einzuteilen:

1. Das MP genügt der Spezifikation.
2. Das MP in der DB genügt nicht der Spezifikation, aber sämtliche Software behandelt ein bestimmtes aus der Menge der noch reparablen MP stets gleich. (D.h. es wird von jeder Software zum gleichen Mehrfachpolygon per Heuristik zusammengebaut.)
3. Das MP in der DB genügt nicht der Spezifikation, und es ist von Software zu Software verschieden, wie damit umgegangen wird. (Z.B. baut Software A per Heuristik jene, Software B diese und Software C gar keine Fläche zusammen.)
4. Das MP in der DB genügt nicht der Spezifikation und wird von jedweder Software verworfen.

Wenn Du einmal Google mit ein paar Abschnitten der Sätze von der Artikelseite fütterst, findest Du heraus, dass sie vermutlich der PostGIS oder rgeos Dokumentation entstammen. Es ist unklar, ob es für OSM eine gesonderte "Spezifikation" gibt, wie es die Artikelseite behauptet, aber wenn die Behauptung stimmt, muss diese gesonderte Spezifikation wohl die gleichen Sätze enthalten, wie die Dokumentation der Bibliotheken..

Im PostGIS Manual sind auch Beispiele oberhalb des Satzes enthalten, die ihn so interpretieren, wie W und ich es weiter oben taten: Sich berührende Kanten von Ringen des gleichen MULTIPOLYGONS sind ungültig, berührende Ecken erlaubt (Bild (j) im Link). Sollen auch berührende Kanten per Definition gültig sein, müsste dieser Satz gestrichen oder umformuliert werden. Er darf dann auf keinen Fall Teil einer wie auch immer gearteten "OSM spec" sein. Möglicherweise hat sich hier einfach jemand einen Witz erlaubt, indem er die beiden Sätze der OGC spec entnahm und hier behauptet sie entstammten einer "OSM spec" und sie zugleich gegenteilig interpretiert. Man könnte das ja auch benutzen, um zu testen, ob der Satz dazu taugt, Doppeldeutigkeit auszuschließen.. Letztendlich ist die Motivation mit der das Eingang ins Wiki gefunden hat nun schwer zu klären, dazu müsste sich zweifelsfrei mal die Person zu Wort melden, die das damals eingetragen hat..

--Cmuelle8 (talk) 17:04, 13 January 2016 (UTC)

Darstellungsfehler von Multipolygonen (?)

Bis dato (2015-12-15) kann es leider entgegen dem klaren OSM Regelwerk beim Endergebnis der gerenderten Karte auf der OSM Webseite Probleme geben. Abhängig von Richtung und Reihenfolge der äußeren und inneren Elemente kann es zu Darstellungsfehlern kommen[1]. Ein typisches Fehlerbild ist die sporadische Darstellung einzelner oder zusammenhängender quadratischer, weisser Felder im Bereich des Multipolygons, abhängig von der Vergrösserungsstufe. Eine entsprechende Anpassung des Multipolygons ist nicht unbedingt sinnvoll, es ist auf einen Fix des fehlerhaften Datenverarbeitungsprogrammes zu hoffen.

Klingt für mich eher nach einem Update-Problem von Tiles - mal die entsprechenden Kacheln mit "/dirty" am Ende der URL neu zu rendern, könnte helfen. Ansonsten können natürlich die MP tatsächlich ungültig (i.S. der Spezifikation auf der Artikelseite) sein, dann sollten das Objekt im Editor geladen und korrigiert werden.. --Cmuelle8 (talk) 19:45, 12 January 2016 (UTC)

Tags bei Relationen/Multipolygonen

Laut [[2]] gehören Attribute (z.Bsp. landuse) die das Multipolygon beschreiben in die Relation:

Attribute, die das Multipolygon beschreiben und somit für die gesamte Fläche abzüglich der Inner-Bereiche gelten sollen (zum Beispiel "landuse=forest"), gehören zur Relation. Die äußeren Linienzüge erhalten nur Attribute, wenn sie etwas Eigenes darstellen.

Auf [[3]] hingegen ist ein Beispiel gegeben, bei dem man ein Multipolygon hat, das aus einem See besteht, welcher eine Insel besitzt. Hier soll nun allerdings der "outer way" mit "natural=water,name=*" getaggt werden und nicht, wie beim ersten Beispiel die Relation. (Das der "inner way" mit "landuse=*/natural=*" getaggt wird erscheint logisch.)

The only way to map a named lake and an island within it is to include both ways with the roles outer and inner into a relation. The relation is tagged with type=multipolygon, the lake is tagged with natural=water,name=* and the island is tagged with landuse=*/natural=*.

Angenommen die Insel ist Teil des Sees, würden sich beide Beispiele nicht widersprechen, allerdings wäre es widersprüchlich zu [[4]]:

Creating islands in lakes

1. ...

2. ...

3. Tag the relation with type=multipolygon, natural=water, name=*, etc. Redundant tags should be removed from the way.

4. ...

Was ist nun richtig?

--David87 (talk) 23:55, 11 January 2017 (UTC)

Geschlossener innerer und äußerer Ring / Empfehlung

Im Artikel wird mehr oder weniger bestimmt empfohlen, den Äußeren und auch den inneren Ring als geschlossenen Linienzug auszuführen. In meinem Arbeitsbereich liegen viele Großflächige MP Strukturen ohne Äußeren Ring aus alten Importen vor. Ich versuche solche Strukturen wo es geht zu verkleinern, und so für eine weitere Verfeinerung bearbeitbar zu machen. Die Empfehlung jeweils einen Äußeren und auch inneren Ring herzustellen würde hierbei den Arbeitsaufwand beträchtlich steigern, wenn nicht sogar unmöglich machen. In der Empfehlung zum geschlossenen Linienzug steht nicht, wer diese Empfehlung ausgesprochen hat, und welchem Zweck solches dienen soll. --Wiki the map (talk)