Das sind einfache Multipolygone. Ob ein Innenpolygon wieder das Außenpolygon eines anderen Multipolygons ist, scheint zumindest für Mapnik, Osmarender und mkgmap inzwischen kein Problem mehr sein.
Da ich mich gerne und viel mit Multipolygonen in OSM beschäftige, wie einige hier im Forum sicher wissen , wie gewünscht meine Erfahrungen zum Einsatz und Rendering von Multipolygonen, insbesondere zur OpenCycleMap. Denn trotz des Ansatzes, wir Mappen nicht für die Renderer, muss und sollte die eigene Arbeit natürlich möglichst fehlerfrei dargestellt werden.
Einfache Multipolygone:
(mit diesen sollten Mapnik, Osmarender und die meisten anderen Tools ohne Probleme klarkommen)
- nur ein Außenpolygon, nur aus einer geschlossenen Kontur bestehend
- ein oder mehrere Innenpolygone, auch jeweils aus nur einer in sich geschlossenen Kontur bestehend
- Außen- und Innenpolygone berühren und überschneiden sich nirgendwo
- Innenpolygone überschneiden sich nirgendwo miteinander, dürfen sich aber an Punkten oder Kanten berühren
- Ein Innenpolygon darf das Außenpolygon eines weiteren Multipolygons sein
Alles andere sind komplexere Multipolygone:
Zum Beispiel: die Außenkontur besteht aus mehreren hintereinanderliegenden Kurvenzügen, die erst alle zusammen ein geschlossenes Polygon ergeben. Mapnik kann das inzwischen. Osmarender macht da (noch?) Fehler, andere Tools wie zum ArcGIS-Export auch.
In Osmarender sieht man das z.B. an einer Stelle des Bodensees, dem hier diskutierten Neusiedler See und wohl auch einigen Schweizer Seen. Dem Rechner, der eine Osmarender-Kachel rendert, fehlen ggf. Kurvenzüge der Außenkontur, die mehrere Kacheln fernab liegen. Dann weiß Osmarender nicht, wo Innen und Außen bei dem Multipolygon liegen und macht Fehler. Osmarender könnte vermutlich immer mehr drumherum liegende Daten laden, um dies zu vermeiden. Das widerspricht aber irgendwie dem verteilten Kachelprinzip. Hier wäre etwas mehr Kommunikation zwischen Mappern und Programmierern wohl gut gewesen, bevor man derartiges nutzt und Objekte wie den Bodensee darauf umstellt.
Noch komplexer sind Konstrukte mit mehreren voneinander getrennt liegenden Außenpolygonen, wo ggf. noch teilweise Innenpolygone drin liegen. Hier muss man wohl bei allen Renderern mit Fehlern rechnen. Solche Konstrukte lassen sich aber fast immer auch durch mehrere getrennte Multipolygone umsetzen. Ein Beispiel war der hier im Thread angesprochene Schilfgürtel des Neusiedler Sees (inzwischen geändert).
Rendering der Radfahrerkarte/OpenCycleMap, Tipps dazu:
Zur Festlegung von Außen- und Innenpolygonen eines Multipolygons verwendet man heute “outer”- und “inner” in der Relation. Früher drehte man stattdessen das Außenpolygon im Uhrzeigersinn und das/die Innenpolygone gegen den Uhrzeigersinn. Die OpenCycleMap verwendet meinem persönlichen Eindruck nach immer noch jenes Schema. Wenn man heute wirklich noch auf die OpenCycleMap Rücksicht nehmen will, kann man also darauf achten, das Außenpolygon im Uhrzeigersinn zu drehen und das/die Innenpolygone gegen den Uhrzeigersinn. Dann weiß auch die OpenCycleMap, wo Außen- und Innenpolygone sind.
Bei Seen/Wasserflächen als Innenpolygone geht dies nicht, denn diese sollen sich per allgemeiner OSM-Definition im Uhrzeigersinn drehen! Die OpenCycleMap hält diese infolgedessen “gerne” für das Außenpolygon und die Fläche außerhalb des Sees für ein mit Wasser zu füllendes Innen. So wird alles bis zum “echten” Außenrand des Multipolygons “geflutet”.
Wie gesagt, die Drehrichtung des Innenpolygon-Sees zu ändern, geht nicht. Man könnte aber eine Extra-Kontur auf den Rand des Innenpolygon-Sees legen, jene dann gegen den Uhrzeigersinn drehen und statt des Sees als Innenpolygon nutzen. Das wäre allerdings reines Mappen für sogar nur einen einzigen Renderer. Gerade solche doppelten Kurven wollte man durch die neuere Umsetzung mit “inner” und “outer” vermeiden. Ich würde das daher keinesfalls machen. Stattdessen “ertrage” ich lieber das fehlerhafte Rendering der OpenCycleMap.
Weiterhin scheint es meinem Eindruck nach bei Multipolygonen in der OpenCycleMap zu helfen, wenn das Außenpolygon am Ende der Relation steht. Dann macht die OpenCycleMap anscheinend weniger Fehler beim Zuordnen des Flächentyps für das Außenpolygon. Bei oben genannten Seen bringt das aber wohl nichts. Vielleicht ist es sogar auch sonst nur Einbildung.
Selbstverständlich kann man auch versuchen, ganz auf Multipolygone mit Seen als Innenpolygone verzichten und ggf. stattdessen Flächen um den See herum legen (Das kann ich z.B. im Harz bei den großen Talsperren so machen. Aber bei über 60 weiteren kleinen Bergbauteichen irgendwo im Wald würde das die Gegend unsinnig zerstückeln. So sieht man auch dort diese überfluteten Flächen.).
Unbefriedigend ist natürlich, dass gerade die Gegenden, wo z.B. “ordentliche” Multipolygone statt “falscher” Layer für Flächen verwendet wurden, in der OpenCycleMap eventuell am schlechtesten aussehen. Aber es gibt ja inzwischen viele andere OSM-Online-Karten-Alternativen. (wenn auch keine echte Radfahrerkarte, oder doch?)