Nun ist der konkrete Fall leider kein richtiger Fehler, aber etwas verzwickt. Die Überlappung wird für beide Relationen nämlich jeweils durch eine inner-Fläche wieder ausgeschlossen.
Um die outer-Überlappung zu entfernen, habe ich es nun so geändert, dass sich nichts mehr überschneidet (Vielleicht kann mir jemand helfen, das mit Overpass-turbo zu verlinken).
Allerdings sagt der note-Tag des mittleren Grenzwegs:
Das wäre im Widerspruch zu meiner Lösung, weil sich die zwei outer-Ringe an zwei Punkten berühren. Ist das wirklich nicht erlaubt? JOSM meckert so nicht mehr.
Würde das reverten, falls das wirklich falsch ist. Dann kann ich aber leider keine Überschneidung mehr erkennen…
das Ding ist nicht in Ordnung. Nach OGC illegale MPs sind auch in OSM schlecht (bis auf eine Ausnahme). Sind die Sachen aber nach OGC OK, dann können sie in OSM trotzdem falsch sein.
Die Relation wird hier mehrdeutig, da die Sortierung der Elemente keine definierte Bedeutung hat. Man kann die vorhandenen Elemente auf mehrere Arten zu zwei Ringen oder gar zu einem Ring zusammensetzen und das darf nicht sein. Ich würde mal jeden Ring als einfache Linie machen.
http://wiki.openstreetmap.org/wiki/Tag%3Atype%3Dmultipolygon
Ich lese da nicht dass es auf die Reihenfolge ankommt.
Die “Ring-Anzeige” im Relationseditor in JOSM ist nur eine Hilfe für den Mapper,
Software kann die Ringe problemlos auseinanderdröseln.
Genau. Die Reihenfolge in der Relation ist bedeutungslos – die Auswertungssoftware muss die Reihenfolge ermitteln.
Das geht eben nicht. Es gibt mehrere Möglichkeiten und ist damit nicht mehr eindeutig:
Wenn ich die Linien mal in der Reihenfolge wie sie in der Relation 957703 genannt werden A, B, C, D, E, F, G, H und I nenne, dann zeigt JOSM jetzt die Ringe A-B-C-D-E-F-G und H-I.
Aber A-B-C-H-E-F-G und D-I wären ebenfalls Ringe.
Man kann es auch zu einem einzigen Ring zusammensetzen: A-B-C-D-H-I-E-F-G
Problematisch ist hier aber erstmal nicht der inner-way, sondern die outer-ways etwas östlich von der Kemptener Straße!
Da kreuzen sich zweimal die outer-ways ganz ohne inner-ways, das geht nicht und ergibt auch keinen Sinn.
Das Problem liegt darin, dass es mehrere Interpretationen gibt – also mehrere Möglichkeiten, aus den angegebenen Stücken Ringe für ein Multipolygon zu bilden.
Die Interpretation, die der Autor augenscheinlich gemeint hat, ist durchaus sinnvoll, hat keine Kreuzungen und beschreibt ein eigentlich zulässiges Multipolygon.
Es wurde hier schonmal beklagt, dass die OSM-MPs weniger strikt sind als die OGC-Polygone (siehe touching inner rings).
In einigen Punkten (touching points) scheint es also genau andersrum zu sein.
Was sagt denn eigentlich der OSMI-MP Inspector dazu? Checkt der boudaries genauso wie MPs?
OSM arbeitet weder bei Multipolygonen noch sonst nach den OGC-Regeln.
Es gibt nur eine OSM-MP-Regel, dass alle gemäß OGC kaputten MPs auch in OSM als kaputt gelten. (Ausgenommen ist dabei aber die OGC-Regel, dass innere Flächen nicht aneinandergrenzen dürfen). Ob das MP in OGC OK ist, spielt aber gar keine Rolle.
Habs mir nochmal durch den Kopf gehen lassen. Tatsächlich könnte es Sinn machen mit dem Konstrukt östlich der Kempener Str. Es ist auch nur eine der beiden Varianten sinnvoll.
Wenn man so etwas endlos schachtelt - und da findest sich bestimmt wer hier, der das macht - wäre das nur noch mit Großrechnern auswertbar. Und beim Anschauen auf der Karte unverständlich.
Wenn man das wirklich machen möchte, müsste die Exklave in eine eigene Relation und dann als Teil der Gesamt-Relation hinzugefügt werden. Dann “merkt” das Auswertprogramm auch nicht, dass sich da was berührt. Dieses Schachteln von Relationen scheint nur bei Grenzen erlaubt zu sein, bin mir aber nicht sicher.
Beispiel aus osm-Daten von Andorra, eine Relation als Teil einer Relation:
.
.
.
Ist das wirklich eine reale Grenze? So kompliziert, mitten im Wald?
Exactly two unclosed ways, and no more should share an endpoint
Inner polygons must not overlap with outer polygons or touch them.
Die Lösung vor meiner Änderung hat dann ja bereits die zweite Regel verletzt (Und das gilt wohl für tausende andere Beispiele in OSM).
Heißt das alles nun, in OSM gibt es keine vernünftige Lösung, so etwas zu modellieren? Das kann doch nicht sein!
Was mich wundert: PostGIS bekommt es ja gut hin, sich aus den Relation-Members ein Multipolygon zu bauen (auch ohne Sequenzsemantik).
Wenn es mehrere mögliche Sequenzen und damit Multipolygone gibt, so würde ich alle Interpretationen verwerfen, in denen sich Polygone selbst überschneiden.
Aus OSM wird mir nicht so ganz klar, wie die Ecke zwischen den beiden Orten nun eigentlich aussehen sollte. Kann das jemand evtl. beschreiben oder skizzieren?
Äh, OSM hat da keine Sequenzsemantik – die Reihenfolge in der Relation spielt keine Rolle. Was Postgis da macht, weiß ich nicht … aber die Angaben an sich sind mehrdeutig.
Ich fände das nicht so gut. Da überlegt sich ein Mapper irgendwas und merkt nicht, dass man es auch noch anders interpretieren kann. Er sollte dann nicht irgendetwas Legitimes statt einer Fehlermeldung bekommen.
Man könnte für jede Exklave eine durchgezogene geschlossene Linie und für das Randstück der großen Teile im “Kontakt-Bereich” der beiden Relationen eine Linie pro Relation nehmen. Dann hat man zwar Linien übereinander, aber die Angelegenheit ist klar formuliert und das MP ist OK.
Bei diesem Rechteck, das man da an der Grenze zwischen den beiden großen Flächen sieht, gehört abartigerweise der obere Teil zur unteren Fläche und der untere Teil zur oberen Fläche.
Das ist wie auf dem Schachbrett. Sieh Dir da eine Fläche mit 6 Feldern an (3 nebeneinander, 2 übereinander). Und dann stell Dir vor, Du müsstest ein MP für das schwarze Gebiet machen
