OSM Carto style ignoriert falsche Rolle in multipolygon?

Ich wundere mich gerade, dass dieses multipolygon als water=lake gerendert wird, obwohl inner und outer vertauscht sind:
https://www.openstreetmap.org/relation/11787853
Klassischer Fall von vertauschten inner und outer Rollen.

Der Mapper hat offensichtlich Probleme, die Rollen mit Id richtig zu setzten, da der äussere Weg gleichzeitig auch ein inner in diesem MP ist:
https://www.openstreetmap.org/relation/8484

Das nur am Rande, mich interessiert hier nur das Rendering. Ich habe auch ein paar andere Karten angeschaut, alle ignorieren die falschen Rollen und betrachten offensichtlich nur die Geometrie. Auch JOSM rendert den See, nur die Datenprüfung meckert.

Das Programm mkgmap, der “Renderer” für Garmin maps, macht es zur Zeit anders: Wenn ein Weg mit role “inner” aussen ist, dann wird er, abgesehen von einer Warnung, komplett ignoriert und daher die Insel als See gerendert. Eine ziemlich fragwürdige Lösung, das will ich ändern, weiss aber noch nicht, in welche Richtung.

Man könnte auch einfach gar nichts rendern, wenn bei einem multipolygon irgendwas mit den Rollen nicht stimmt, wird aber nicht gemacht.
Wurde dieses Verhalten, also die Rollen zu ignorieren, mal irgendwo als “beste” Methode vereinbart?
Dann würde ich das in mkgmap auch so wollen.

Für Hinweise wäre ich dankbar.

Gerd

Gedankenexperiment: Auf einer Kugeloberfläche kannst du bei einer geschlossenen Kurve eigentlich nie sagen, wo “außen” und wo “innen” ist. Wir nehmen normalerweise an, dass die kleinere Teilfläche die Innenseite ist, aber stell dir mal einen geschlossenen Way längs des Äquators vor :slight_smile:

Solange nur ein inner im outer ist, sind die Rollen rein geometrisch gesehen beliebig vertauschbar. Der Renderer muss nur wissen, dass alles zwischen inner und outer das MP ist. Ob die kleinere Restfläche die Insel ist und die größere die Außenwelt oder andersrum, macht keinen Unterschied aus.

Wenn das inner dann mehr als 500 Millionen Quadratkilometer hat, ist das Gedankenexperiment doch sehr unrealistisch.

Sind wir beim Mappen nicht eher auf einer rechteckigen Fläche (-180° bis +180° und -90° bis +90°) mit eigenwilliger Metrik? (Siehe z.B. Relation 3237100)

Jede simple Linie zwischen zwei Punkten ist auf einer Kugel übrigens ebenso mehrdeutig … das wäre besonders für natural=coastline fatal.

Ich sag doch: wir gehen intuitiv davon aus, dass die kleinere Seite die Innenseite des Polygons ist. Aber geometrisch ist das austauschbar, es kann ebensogut auch andersherum sein. Deshalb macht der Renderer keinen echten “Fehler”, wenn er das hier angesprochene Multipolygon anstandslos rendert.

In der Kugelgeometrie ja (eine Linie ist Teil eines Großkreises, aber bei zwei Punkten ist nicht gesagt, welcher Teil). In OSM haben die zwei Punkte im way eine Reihenfolge, die es eindeutig macht. Wenn wir für Polygone ähnlich wie für natural=cliff festlegen würden, welche Seite richtungsabhängig innen ist, wäre es auch eindeutig. Aber das tun wir ja nicht.

Der Renderer verwendet eine von osm2pgsql erstellte Datenbank, osm2pgsql baut die Polygone mit osmium, und das kümmert sich nicht um die Rollen. Die Rollen waren schon immer überflüssig. Der OSMI bemerkt das Problem aber: https://tools.geofabrik.de/osmi/?view=areas&lon=14.23566&lat=42.45166&zoom=18

Oder auch davon, dass kein Teil des Polygons die Datumsgrenze überlappt :wink:

Vor gut 10 Jahren hab ich im Wiki eine Seite dazu angelegt, wie man aus einer Multipolygonrelation ein Polygon baut: https://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm schon damals stand drin: “You see that this algorithm doesn’t actually use the inner or outer roles”…

Danke, die Info fehlte mir.

Mir ist klar, dass man die Rollen nicht braucht, wenn das MP ansonsten korrekt und vollständig bekannt ist.
In mkgmap muss man sich aber auch mit unvollständigen Daten rumschlagen, sprich, irgendein mehr oder weniger vollständiger Extrakt aus OSM oder auch irgendwelche generierten Daten, die sich nicht unbedingt um OSM Regeln kümmen.
Bisher dachte ich auch immer, dass mkgmap bei vollständigen Daten die Rollen ignoriert, dem ist aber nicht so.

@woodpeck: Zum Thema Backtracking: Ist das in osmium implementiert? Dann würde ich evtl. mal versuchen, dass auch in JOSM und mkgmap einzubauen.

Ein brauchbares Fehlerprüfungstool ist jedenfalls: http://tools.geofabrik.de/osmi

Die falsch angelegten Rollen werden eindeutig erkannt und angezeigt:
http://tools.geofabrik.de/osmi/?view=areas&lon=8.84677&lat=51.80977&zoom=11&opacity=1.00

Nein, die Reihenfolge der Punkte macht es nicht eindeutig. Da die Punkte eine Reihenfolge haben ist es nur zweideutig statt vierdeutig.

Von Pol zu Pol bleibt es bei unendlich auch wenn nur die Hälfte von der Unendlichkeit ohne Richtung Reihenfolge.

Mein Fehler, ihr habt recht.