MP-Grenzproblem: Untrasried / Wildpoldsried

Sieht mir momentan sauber aus. Berührungspunkte sind ja laut OGC erlaubt. Beispiel (j) und (p).

chris66 wrote:

Sieht mir momentan sauber aus. Berührungspunkte sind ja laut OGC erlaubt. Beispiel (j) und (p).

Dann könnte die note ja gelöscht werden. Ich hab eh nicht verstanden, was hier mit "Niemandsland" gemeint war.

Hi,

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.

MfG
Weide

Weide wrote:

das Ding ist nicht in Ordnung.

http://wiki.openstreetmap.org/wiki/Tag% … ltipolygon
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.

chris66 wrote:

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,

Genau. Die Reihenfolge in der Relation ist bedeutungslos -- die Auswertungssoftware muss die Reihenfolge ermitteln.

chris66 wrote:

Software kann die Ringe problemlos auseinanderdröseln.

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

Weide

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.

Pepito wrote:

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.

Der Fehler liegt in der Mehrdeutigkeit.

Weide

Hier mal die Regeln, die für die Eindeutigkeit sorgen und bei den genannten Relationen verletzt werden:

(aus http://wiki.openstreetmap.org/wiki/Rela … tipolygon)

von beiden verletzt:

Exactly␣two␣unclosed␣ways,␣and␣no␣more␣should␣share␣an␣endpoint

Vom westlichen verletzt:

Inner␣polygons␣must␣not␣overlap␣with␣outer␣polygons␣or␣touch␣them.

Weide

Edit: PS: Dieser Abschnitt fehlt in der deutschen Übersetzung des Wiki.

Weide wrote:

Inner␣polygons␣must␣not␣overlap␣with␣outer␣polygons␣or␣touch␣them.

Diese Regel wird z.B. von Mapsforge strikt beachtet und führt bei Nichteinhaltung zum Verwerfen des Multipolygons.

Gruß Klaus

chris66 wrote:

Sieht mir momentan sauber aus. Berührungspunkte sind ja laut OGC erlaubt. Beispiel (j) und (p).

meinst du jetzt das OSM nach den festgelegten Standards vom OGC arbeitet, oder ist das nur bei Multipolygonen so?

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?

FGOSM22 wrote:

meinst du jetzt das OSM nach den festgelegten Standards vom OGC arbeitet, oder ist das nur bei Multipolygonen so?

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.

Weide

Danke @Weide für die ausführliche Erklärung

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:
<relation id="79981">
.
<member type="way" ref="28494692" role="outer"/>
.
<member type="relation" ref="82675" role="outer"/>
.
<tag k="admin_level" v="3"/>
<tag k="border_type" v="territorial"/>
<tag k="boundary" v="administrative"/>
</relation>

Ist das wirklich eine reale Grenze? So kompliziert, mitten im Wald?

Weide wrote:

Hier mal die Regeln, die für die Eindeutigkeit sorgen und bei den genannten Relationen verletzt werden

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.

Pepito wrote:

Dieses Schachteln von Relationen scheint nur bei Grenzen erlaubt zu sein, bin mir aber nicht sicher.

Nein, ist "offiziell" weder bei MPs noch bei boundary-Relations erlaubt.
http://wiki.openstreetmap.org/wiki/Relation:boundary
Nur die subareas sind als Relation-member zugelassen.

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?

Gehrke wrote:

Was mich wundert: PostGIS bekommt es ja gut hin, sich aus den Relation-Members ein Multipolygon zu bauen (auch ohne Sequenzsemantik).

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

Gehrke wrote:

Wenn es mehrere mögliche Sequenzen und damit Multipolygone gibt, so würde ich alle Interpretationen verwerfen, in denen sich Polygone selbst überschneiden.

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.

Gehrke wrote:

Heißt das alles nun, in OSM gibt es keine vernünftige Lösung, so etwas so modellieren? Das kann doch nicht sein!

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.

Weide

Prince Kassad wrote:

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?

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 :-)

Weide

Weide wrote:

chris66 wrote:

Software kann die Ringe problemlos auseinanderdröseln.

Das geht eben nicht. Es gibt mehrere Möglichkeiten und ist damit nicht mehr eindeutig:

Einwand akzeptiert. Die Ringe sind allerdings egal, da es um die Fläche geht, und die
ist mMn eindeutig.

Prince Kassad wrote:

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?

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

chris66 wrote:

Die Ringe sind allerdings egal, da es um die Fläche geht, und die
ist mMn eindeutig.

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

Weide wrote:

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

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

wambacher wrote:

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

wambacher wrote:

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.

Ja, den Eindruck bekommt man.

Weide wrote:

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

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.

Weide wrote:

Gehrke wrote:

Heißt das alles nun, in OSM gibt es keine vernünftige Lösung, so etwas so modellieren? Das kann doch nicht sein!

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.

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.

Gehrke wrote:

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?

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

Weide wrote:

Gehrke wrote:

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?

Na ja, aus den Daten schon ... aber nicht aus den Way-Ids. Da muss man runter auf die Node-Ids.

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.

Gehrke wrote:

Was spräche eigentlich gegen eine Sequenzsemantik für MPs und Boundaries?

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

Weide wrote:

Gehrke wrote:

Was spräche eigentlich gegen eine Sequenzsemantik für MPs und Boundaries?

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

Stimmt. Aber für (korrekt gemappte) Boundaries würde es reichen.

Weide wrote:

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.

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.

Gehrke wrote:

Stimmt. Aber für (korrekt gemappte) Boundaries würde es reichen.

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

wambacher wrote:

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

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

Siehe dazu auch Diskussion hier: http://forum.openstreetmap.org/viewtopi … =24132&p=6

ist mMn Schnee von gestern.