Was ist in Multipolygonen erlaubt?

[Basstoelpel]

Hi,

zwei Dinge, die OSMI anmeckert, bei denen ich aber nicht recht verstehe, warum sie nicht erlaubt sein sollen, da sie auf ähnlichem level wie touching inner rings sind:
Dürfen sich zwei geschlossene outer-Ringe auf einer Strecke berühren?
Darf ein inner way eine gemeinsame Strecke mit einem outer way haben?

Hoffe auf Eure Meinungen,

Baßtölepel

[aighes (Henning)]

1: ja
2: nein, weil dann braucht man ja kein Multipolygon

[woodpeck (Frederik Ramm)]

@Basstoelpel

zwei Dinge, die OSMI anmeckert, bei denen ich aber nicht recht verstehe, warum sie nicht erlaubt sein sollen, da sie auf ähnlichem level wie touching inner rings sind:
Dürfen sich zwei geschlossene outer-Ringe auf einer Strecke berühren?
Darf ein inner way eine gemeinsame Strecke mit einem outer way haben?

Es gibt da einen GIS-Standard, der nennt sich “Simple Features Specification”, da ist genau erklaert, was in der normalen GIS-Welt eine Linie ist und was ein Polygon und was erlaubt ist und was nicht.

In dieser normalen GIS-Welt sind alle drei erwaehnten Faelle unzulaessig:

• zwei innere Ringe duerfen sich nicht linienhaft beruehren, denn dann braeuchte man ja keine zwei Ringe, sondern nur einen;
• zwei aeussere Ringe duerfen sich nicht linienhaft beruehren, denn dann braeuchte man ja keine zwei aeusseren Ringe, sondern nur einen;
• ein innerer und ein aeusserer Ring duerfen sich nicht linienhaft beruehren, denn dann koennte man stattdessen ja auch eine “Delle” in den aeusseren Ring machen.

Das muss man nicht zwangslaeufig so auf OSM anwenden, aber bei vielen Verarbeitungsschritten - so auch bei der osm2pgsql-Vorstufe fuer das Mapnik-Rendering - wird eben doch in solche “normalen GIS-Features” gewandelt, und deswegen ist es sinnvoll, sich daran zu halten.

Die Ausnahme, dass “touching inner rings” erlaubt sein sollen, haben wir uns genehmigt, weil bei uns ein “inner Ring” halt eine Doppelrolle haben kann - Loch im Polygon und zugleich ein See oder eine Wiese oder sowas, und da kann es durchaus nuetzlich sein, zwei davon benachbart zu haben (sonst muesste man ja fuer den Fall “Lichtung im Wald mit einer Wiese und einem See daneben” erst ein “inner”-Loch in den Wald schneiden und innerhalb dessen dann einzeln einen See und eine Wiese malen).

Allerdings - und deswegen markiert der OSMI auch die “touching inner rings” - sollte man das nicht exzessiv betreiben, denn nicht jeder, der OSM-Daten verarbeitet, achtet da auch richtig drauf, so dass “touching inner rings” immer eine Achillesferse sind.

Bye
Frederik

[hurdygurdyman]

@woodpeck

…
Die Ausnahme, dass “touching inner rings” erlaubt sein sollen, haben wir uns genehmigt, weil bei uns ein “inner Ring” halt eine Doppelrolle haben kann - Loch im Polygon und zugleich ein See oder eine Wiese oder sowas, und da kann es durchaus nuetzlich sein, zwei davon benachbart zu haben (sonst muesste man ja fuer den Fall “Lichtung im Wald mit einer Wiese und einem See daneben” erst ein “inner”-Loch in den Wald schneiden und innerhalb dessen dann einzeln einen See und eine Wiese malen).

Allerdings - und deswegen markiert der OSMI auch die “touching inner rings” - sollte man das nicht exzessiv betreiben, denn nicht jeder, der OSM-Daten verarbeitet, achtet da auch richtig drauf, so dass “touching inner rings” immer eine Achillesferse sind.

Bye
Frederik

1+
und genau deshalb bevorzuge ich den inner ohne Attribute. Da passt dann auch noch Oma’s Kräutergärtchen ohne Fummelei neben die Wiese, den man erst auf den “SuperBing”-Bildern erkennt.

[fkv (Friedrich Volkmann)]

@Basstoelpel

zwei Dinge, die OSMI anmeckert, bei denen ich aber nicht recht verstehe, warum sie nicht erlaubt sein sollen

OSMI ist bei MP nicht zu gebrauchen. Er hat auch touching inner rings angemeckert, obwohl sie explizit erlaubt sind.

@woodpeck

Es gibt da einen GIS-Standard, der nennt sich “Simple Features Specification”, da ist genau erklaert, was in der normalen GIS-Welt eine Linie ist und was ein Polygon und was erlaubt ist und was nicht.

Zum Glück sind wir nicht an diesen Standard gebunden. Wir dürfen’s besser machen.

bei vielen Verarbeitungsschritten - so auch bei der osm2pgsql-Vorstufe fuer das Mapnik-Rendering - wird eben doch in solche “normalen GIS-Features” gewandelt, und deswegen ist es sinnvoll, sich daran zu halten.

Mapnik hat kein Problem mit solchen Fällen.

Ich weiß nicht, was genau dabei passiert. Wenn ich einen Renderer schreiben würde, würde ich alle Flächen - auch MP - in Quadrate bzw. rechtwinkelige Dreiecke zerlegen. Dann ist es völlig egal, ob eine Fläche am Rand oder in der Mitte von der anderen ausgenommen ist.

sollte man das nicht exzessiv betreiben, denn nicht jeder, der OSM-Daten verarbeitet, achtet da auch richtig drauf

Deren Problem.

[de_muur]

@Basstoelpel

Dürfen sich zwei geschlossene outer-Ringe auf einer Strecke berühren?
Darf ein inner way eine gemeinsame Strecke mit einem outer way haben?

Ob es erlaubt ist oder nicht ist m.E. egal. In beiden Faellen kann man ohne einen Informationsverlust die Objekte einfacher strukturiert erfassen, so dass man aus rein praktischen Erwaegungen solche Konstrukte ausschliessen sollte. Keep it simple!!!

Gruss
Torsten

[fkv (Friedrich Volkmann)]

@de_muur

ohne einen Informationsverlust

…aber mit dem Gegenstück, nämlich unnötiger Redundanz. Streckenzüge mehrmals nachzeichnen… Aber ich weiß schon, du magst Multipolygone generell nicht.

[hurdygurdyman]

@fkv

OSMI ist bei MP nicht zu gebrauchen. Er hat auch touching inner rings angemeckert, obwohl sie explizit erlaubt sind.

Zum Glück sind wir nicht an diesen Standard gebunden. Wir dürfen’s besser machen.

Mapnik hat kein Problem mit solchen Fällen.

Ich weiß nicht, was genau dabei passiert. Wenn ich einen Renderer schreiben würde, würde ich alle Flächen - auch MP - in Quadrate bzw. rechtwinkelige Dreiecke zerlegen. Dann ist es völlig egal, ob eine Fläche am Rand oder in der Mitte von der anderen ausgenommen ist.

sollte man das nicht exzessiv betreiben, denn nicht jeder, der OSM-Daten verarbeitet, achtet da auch richtig drauf

Deren Problem.

MP-Diskussion, die x-te…
Allein die Tatsache, dass wir dieses Theme immer wieder haben, zeigt, wie unzulänglich und schwer durchschaubar diese Materie ist.
Wenn OSM touching inner erlaubt, ist das unser Problem.

Standards haben haben auch für OSM ihren Sinn, sobald man über den OSM-Tellerrand und die Schnittstellen in die GIS-Welt da draußen hinausschaut. Ob wir es besser machen, wage ich zu bezweifeln.

Mapnik ist auch nur eine Insel.

Wie de_muur richtig bemerkt, kann man MP’s vermeiden, bei denen inner und outer gemeinsame Linien haben und sollte dies auch tun.

Ich hoffe das die nächste API hierzu mal klare Regelungen trifft.

So langsam kommt mir das dauernde Ignorieren der GIS-Welt außerhalb von OSM einschließlich aller Renderer so vor, als ob einige Kräfte in OSM Angst davor haben, endlich einmal die in den Jahren aufgelaufenen Probleme unseres Datenmodells anzugehen und zu lösen. Um eine offene Straßenkarte zu basteln, benötigt man nur Linien und Punkte. Wenn OSM mehr will, müssen wir auch mehr tun. Noch nicht einmal unser zweidimensionales Datenmodell ist sauber. Was soll erst aus dem Versuch der 3D-Abbildung werden.

[wambacher (Walter Nordmann)]

@hurdygurdyman

Standards haben haben auch für OSM ihren Sinn, sobald man über den OSM-Tellerrand und die Schnittstellen in die GIS-Welt da draußen hinausschaut. Ob wir es besser machen, wage ich zu bezweifeln.

1+

So langsam kommt mir das dauernde Ignorieren der GIS-Welt außerhalb von OSM einschließlich aller Renderer so vor, als ob einige Kräfte in OSM Angst davor haben, endlich einmal die in den Jahren aufgelaufenen Probleme unseres Datenmodells anzugehen und zu lösen. Um eine offene Straßenkarte zu basteln, benötigt man nur Linien und Punkte. Wenn OSM mehr will, müssen wir auch mehr tun. Noch nicht einmal unser zweidimensionales Datenmodell ist sauber. Was soll erst aus dem Versuch der 3D-Abbildung werden.

Harte Worte, aber du hast absolut recht.

Gruss
Walter