@ fkv
Es ist schon eigenartig, wie Du darauf herum reitest, daß die Wanderreitkarte keine modernen Relationen darstellen kann.
Wenn dem so wäre, läge es nicht an der Wanderreitkarte, sondern an dem Renderprogramm, mit dem sie erstellt wird. Und das betrifft dann auch alle anderen Karten, die mit diesem Renderprogramm hergestellt werden. Darüber zu diskutieren bringt aber nichts, denn zur Problemlösung trägt das bei den von mir genannten Beispielen nicht bei.
Bei diesen Beispielen war bisher jedes Mal eine winzige, kaum sichtbare Überschneidung von zwei nebeneinander liegenden Multipolygonen die Fehlerursache. Nachdem ich sie gefunden hatte, erschienen die Flächen richtig auf der Wanderreitkarte.
Daß der Mapnik-Renderer die fehlerhaften Multipolygone trotzdem richtig dargestellt hat, spricht für seine Fähigkeit, Fehler zu ignorieren. Deshalb ist der für die Wanderreitkarte genutzte Renderer nicht schlechter. Ich würde ihn eher empfindlicher nennen. Und diese Empfindlichkeit erzieht zu sauberem Mappen, was nicht unbedingt ein Nachteil ist.
Ein anderes Problem ist die Darstellung übereinander gelegter Polygone, die ohne Einbindung in Multipolygon-Relationen einander überdecken.
Bei der Schichtung übereinanderliegender, einfacher Polygone spielen die vom Kartenbastler erstellten Renderregeln eine Rolle.
Zumindest war es bislang so, daß man die Möglichkeit hat Layer zu definieren, mit deren Hilfe die Reihenfolge der “Stapelung” unabhängig von der Größe der Polygone bestimmt wird. Außerdem spielt noch die Reihenfolge der Elemente während des Renderprozesses eine Rolle. Inwieweit sich da das Rendererverhalten eventuel verändert hat, indem beispielsweise die Größe der Polygone im Gegensatz zu früher berücksichtigt werden, kann ich nicht beurteilen. Es ist mir auch ziemlich egal. Jedenfalls war es bei diesem System ursprünglich nicht möglich, Polygone mit derselben Definition sowohl zu oberst als auch zu unterst darzustellen. Beispiel: riesiger Wald - darin große Wiese - darin ein See - darin eine bewaldete Insel. Je nach Aufbau der Renderfolge verschwand entweder der kleine Wald unter der Wiese oder alles unter dem großen Wald.
Diesem Mißstand kamen die Multipolygone mit den outer und inner Definitionen bei, indem mit ihrer Hilfe in die outer-Flächen Löcher geschnitten werden. Schon das einfache System läßt theoretisch eine endlose Verschachtelung zu, indem eine inner-Fläche gleichzeitig als outer-Fläche einer weiteren Relation für darin liegende Ausschnitte definiert werden kann.
Sofern man sich an das einfache Grundprinzip hält, daß mit einem Außenring stets ausschließlich die nächsten Innenringe in einer Relation zusammengefaßt werden, bleibt das ganze klar und übersichtlich. Und wenn jeder Ring auch noch seine Flächentags trägt, weiß man immer, woran man ist.
Wenn der gar nicht so seltene Fall eintritt, daß eine verschiedene Multipolygone überdeckende Fläche definiert werden muß, handelt es sich meiner bisherigen Erfahrung nach um Flächen wie z.B. Naturschutzgebiete, Militärgebiete, Freizeitparks, Freilichtmuseen oder politische bzw. Verwaltungs-Einheiten (Ortschaften etc. )
Solche Flächen sind in Karten, in denen sie nicht transparent gerendert werden, ein Problem. Entweder überdecken sie alle Details oder aber sie verschwinden bei komplett gemappter Landbedeckung mehr oder weniger unter den Details. Je nach dem, in welchem Layer sie stecken. Da helfen auch die modernen Multipolygone nicht. Denn das ist keine Frage ob der Renderer mit Multipolygonen umgehen kann, sondern abhängig davon, welche *.png der Kartenbastler für diese Flächen einsetzt.
Wenn er geschickt ist, sucht er sich für häufig auftretende Kombinationen *.png aus, deren transparente Muster sich gut kombinieren lassen. Dann ergibt sich ein ähnlicher Effekt, wie bei einer Overheadprojektor-Präsentation, wenn nach und nach mehrere Folien übereinander gelegt werden.
Solche übergreifenden Flächen in ein Multipolygon zu stecken, mag für die Analyse der Datenbank theoretisch interessant sein. Und da macht die Auslagerung der Eigenschaften in die Relation auch durchaus Sinn, weil man dann bei jedem Relationsmitglied durch Einsicht in die Relationstags feststellen kann, welcher abstrakten Einheit die Fläche zugeordnet ist. Den Nutzen sehe ich ähnlich wie bei Wanderweg-Relationen. Derartige Zuordnungen können nur in begrenztem Maß mit einem is_in=* oder associated_with=* ausgedrückt werden. In derartige Relationen müßte man dann aber nicht nur Flächen sondern auch Punkte und Wege einbinden dürfen.
Für die optische Darstellung in einer Karte sind diese Bezugsetzungen jedoch erst einmal unerheblich. Mit dem bisherigen System sind ineinander verschachtelte Flächen mühelos mit dem bisherigen Multipolygonsystem darstellbar und gleichzeitig kann eine große, transparente Fläche als einfaches Polygon darüber gezogen werden, das keinerlei Rücksicht auf die Linien der darunter liegenden Multipolygone nehmen muß und diese schneiden darf. Das wird in der Praxis so gebraucht, denn die Grenzen per Definition geschaffener “abstrakter” Flächen richten sich nicht zwangsläufig nach den sich aus “gegenständlichen” Flächen ergebenden Grenzen. So verläuft der Absperrzaun eines Truppenübungsplatzes beispielsweise mitten durch ein großes Waldpolygon, schneidet die Grenzlinien von Wiesen, Heideflächen usw.
So eine Fläche kann man nicht als outer definieren. Das bringt wegen der Überschneidung zwangsläufig Probleme mit sich.
Wurde das bereits bei der Entwicklung des modernen Multipolygons berücksichtigt?
Es müßte ein neues Rollentag her. Etwa in der Art wie Rolle= cover
Dieser Flächentyp müßte von den Renderern so verarbeitet werden, daß das Polygon durch das Tag “cover” automatisch nach oben gelegt wird. Und verschiedene Cover müßten sich schneiden dürfen.
Diese Art von Multipolygonen hat meines Erachtens ausschließlich abstrakten Mehrwert. Für eine korrekte Kartendarstellung kann ich keine Notwendigkeit erkennen. Die ist auch mit einfachen Polygonen möglich.
Eine Ausnahme davon würde sich ergeben, wenn in einem “Cover”-Gebiet Enklaven liegen. Beispiel: riesiger Nationalpark, darin ein Dorf mit Wiesen und Feldern, das nicht den Nationalparkregeln unterliegt. Betrifft Nationalpark Eifel und Wolfsgarten.
Um das korrekt rendern zu können, dürfte Cover nicht automatisch in die oberste Ebene gelegt werden. Vielmehr müßten alle untergeordneten Mitglieder darunter liegen und alle Nicht-Mitglieder darüber.
Das würde bedeuten daß der neue Multipolygontyp ein Pendant für Cover benötigt. So wie es inner/outer gibt, müßte es dann cover/included oder ähnliches geben.
Die Erfassung derartiger Multipolygone stelle ich mir ziemlich fehleranfällig vor. Daher erhebt sich die Frage, wie sinnvoll so ein Aufwand wäre.
Gruß
tippeltappel
