Einwand akzeptiert. Die Ringe sind allerdings egal, da es um die Fläche geht, und die
ist mMn eindeutig.
Grün: Untrasried
Grau: Wiltpodried
Man beachte dass im Gebiet des Schachbretts (zwischen den beiden drei-Länder-Punkten) alle Liniensegmente outer-member von beiden Relationen sind. Für Nicht-Mathematiker vermutlich zwei Nummern zu hoch. 
Wenn ich bei Wiltpoldried den vierten und den letzten gegeneinander tausche, dann bilden die ersten sieben einen Ring und die letzten beiden einen. Wiltpoldried hätte dann die Untasrieder Exklave hinzubekommen – und das auch noch doppelt. 
Weide
PostGIS hat da keine Chance. Den Job, aus “gestückelten Multipolygonen” was OGC-Konformes zu machen, erledigen Programme wie osm2pgsql so nebenbei. Dabei werden aber bestimmte Konstrukte (z.B. Super-Relationen mit Relationen als Member) einfach stillschweigend ignoriert.
Also: damit die Mehrzahl aller GIS-Programme überhaupt was mit OSM-Daten anfangen kann, muß vor oder bei dem Importieren kräftig konvertiert werden - und das schaffen die wenigsten Programmierer/Programme 
Einer der Gründe, warum es mit API-0.7 nicht weiter geht, liegt wohl darin verborgen, daß sich niemand so richtig an die Sache rantraut, OSM OGC-konform zu machen - was mMn dringenst notwendig ist. Die OSM zugrunde liegende Datenstruktur ist total veraltet und behindert uns nur zunehmend. Diskussionen darüber, was erlaubt oder tolerabel ist, können dann entfallen und man kann sich mehr auf das Kerngebiet von OSM - das Mappen - konzentrieren.
Gruss
walter
Also das spuckt PostGIS bei mir für folgendes Query aus:
SELECT relations.id, member_role, relations.tags->'name' as name, ST_AsText((ST_DUMP(ST_Polygonize(linestring))).geom)
FROM relations JOIN relation_members ON (relations.id = relation_id) JOIN ways ON (ways.id = member_id)
WHERE member_type = 'W' AND relations.id = 957703 OR relations.id = 448040
GROUP BY relations.id, member_role
448040;"outer";"Untrasried";"POLYGON((10.3781293 47.8816884,10.3785355 47.8817087, ...
448040;"outer";"Untrasried";"POLYGON((10.3917355 47.8078288,10.3908735 47.808136, ...
448040;"outer";"Untrasried";"POLYGON((10.3924616 47.8083198,10.3931324 47.8080592, ...
448040;"inner";"Untrasried";"POLYGON((10.3774061 47.8090754,10.3771568 47.8091827, ...
957703;"outer";"Wildpoldsried";"POLYGON((10.4520226 47.7574158,10.4516702 47.7564688, ...
957703;"outer";"Wildpoldsried";"POLYGON((10.3924616 47.8083198,10.3931324 47.8080592, ...
957703;"outer";"Wildpoldsried";"POLYGON((10.3917355 47.8078288,10.3908735 47.808136, ...
Da Wildpoldsried ja nur aus 2 Teilen bestehen sollte, ging das in der Tat daneben.
Ja, den Eindruck bekommt man.
Das ist mir doch klar! Ich dachte nur, PostGIS kommt trotzdem damit zurecht (ohne eine Sequenz zu beachten). Mein Test stützt diese Annahme jedoch nicht.
Wenn ich das richtig verstanden habe, hieße das doch, dass man nicht mehr aus den Daten (also den way IDs) ablesen kann, dass beide Grenzen sich dort berühren, oder? Das fände ich gar nicht gut.
Ja.
Na ja, aus den Daten schon … aber nicht aus den Way-Ids. Da muss man runter auf die Node-Ids.
Ich sehe keine andere Möglichkeit: Jeder Node, der Endpunkt von 4 Linien einer Relation ist, schafft eine Mehrdeutigkeit. Eine Linie durchgehen zu lassen, statt sie enden zu lassen, schafft eine Linie, die nur für eines der MPs geeignet ist und auf der also für das andere MP eine andere Linie liegen muss. Ich kenne mich mit Boundaries nicht so aus (ich mag sie nicht), aber bei MPs sehe ich keinen anderen Weg.
Weide
Es wäre für ein Auswertungstool ein prohibitiver Aufwand, die Nodes zu vergleichen, um benachbarte Gebiete zu erkennen.
Für meine Zwecke müsste ich OSM dann fast in die Tonne treten.
Auch wenn es sie bisher nicht gibt: Was spräche eigentlich gegen eine Sequenzsemantik für MPs und Boundaries?
Das Gegenargument vorweg: Natürlich erfüllen nicht alle MPS oder Boundaries eine “korrekte” member-Sequenz.
Es würde aber erstmal schon reichen, wenn die Sequenz nur im Zweifelsfall herangezogen wird.
Laut taginfo gibt es immerhin über 50.000 Relationen, die Member anderer Grenzrelationen sind.
Und ohne Member-Relation: Einfach die Exklave als einen einzigen Outer-Ring einzeichnen. Verbindungspunkt möglichst nicht an Verbindungspunkte des Hauptgebietes. Dann ist die Sache doch einfach aufzulösen.
Hmm, die Änderung würde nicht dafür sorgen, dass man nur noch Way-Ids vergleichen muss. Es gibt viele einfache Polygone mit derartigen Überlappungen, die dann alle MPs werden müssten. Es gibt die Ausnahme für die “touching inner”, die auch solche Vergleichsprobleme schafft.
Das alles könnte man wohl nur im Rahmen des “großen Wurfs” lösen, bei dem in OSM kein Stein auf dem anderen bleibt. Da müssten m.E. die geometrischen Objekte (Punkte, Linienzüge, Flächen, Volumina – ohne Tags) von den geographischen Objekten (Dinger mit Tags, die auf geometrische oder geographische Objekte verweisen) getrennt werden. Ich seh da schwarz.
Weide
Stimmt. Aber für (korrekt gemappte) Boundaries würde es reichen.
Das wird nicht pasieren. Hmm, ich könnte in meiner DB selbst eine Zwecktabelle anlegen, die alle geometrisch gleichen tagged-ways auf einen virtuellen geo-way abbildet. Schön wäre das aber nicht - und aufwendig zu pflegen.
Ja, aber ich bin eigentlich Fundamentalist
Wir haben bestimmte geschlossene Linien und die Multipolygone als Flächenersatztypen. Alle anderen sollten diese Flächen benutzen, wenn sie welche benötigen und sie nicht doppelt gemoppelt selbst bauen.
Weide
+1
Ich habe nochmal verschiedene PostGIS-Varianten ausprobiert, um eine korrekte Area für Untrasried/Wildpoldsried aus den Grenzsegmenten zu erstellen: mit Polygonize und BuildArea. Alle sind gescheitert, selbst wenn ich explizit eine Sequenzsemantik einzuführen versuchte.
ist mMn Schnee von gestern.