Bevor ich gestern mit meinen Wurstfingern unter Potlatch 2 in geistiger Verwirrung (aber ohne Alkoholeinfluss), daran bastelte, hatte der Überlingersee am MP noch natural=water als tag und enthielt Wasser im Gegensatz zum westliche Rest des Sees.
Nach Anschauen deiner Änderung und nochmaligem Studium der Wiki habe ich das mit dem “outer-inner-outer” auch kapiert.
Danke!
Setzt aber voraus, dass das “innerste” outer beim Flächentagmit dem äußeren outer übereinstimmt, oder?
Nö, denke ich nicht, “Wald - Wiese - Wasser” müßte eigentlich auch gehen.
Cave: Ich habe den OGC Simple Feature Standard nicht gelesen.
Möglicherweise ist achtfach-ineinandergeschachtelt auch keine gute Idee … 
Ciao,
Frank
Hallo Leute!
So, ich bin einen Schritt weiter und kenne jetzt die Ursache dafür, daß die MP-Seen nicht gezeichnet werden. Meine Renderkette enthält eine Optimierung mit partiellen Geometrieindexen, die das Rendern beschleunigt. Für die MP-Züge funktioniert das nicht, denn zu dem Zeitpunkt wo die Polygone für den Index ausgesucht werden, ist der See noch kein Polygon, sondern nur eine Relation. Deshalb landet er ohne Kennzeichnung in der DB, kommt nicht in den Index und wird beim Rendern auch nicht gefunden. Die Umwandlung MP-Zug → echtes Polygon in der DB macht osm2pgsql, da habe ich keinen Einfluß darauf.
Um die Theorie zu prüfen, habe ich den Starnberger See von Hand korrigiert und das Wasser erfolgreich wieder eingelassen.
Jetzt muß ich noch eine Methode finden, der Relation die nötigen Attribute so unterzuschieben daß sie nach der Konvertierung durch osm2pgsql “zufällig” auf die richtige Art am Polygon hängen. Und einen Mechanismus bauen, der es erlaubt, die Relationen zu verändern - bisher waren die in meinem Tool read-only. Und dann schauen was immer noch verkehrt ist. 
bye
Nop
hi frank,
genau das ist ja eigentlich der grund für die “verschachtelten” multipolygonstrukturen, sprich
wald-wiese-wald geht (meist)
wald-wiese-allesausserwasser geht eben (meist) nicht.
der grund hierfür ist, dass alle outer-ways eines multipolygons den gleichen zeichenstil haben sollen/müssen.
dabei spielt es (meist) keine rolle, ob diese äußeren wege neben- oder eben inneinander liegen.
wasser allerdings könnte da eine außnahme darstellen, da es so ziemlich über alles drüber gerendert wird,
was dann aber mit der struktur als multipolygon an u. für sich nichts zu tun hätte.
von daher hast du in deinem beispiel sicher nicht unrecht… 
…und dass du dieses eine innere mpg aufgelöst u. in das äußere waldmultipolygon mit aufgenommen hast, ist
sicher der einfachere weg!
wald-wiese=wiese-wald oder anders: outer-inner=outer-inner ist in diesem falle fast schon unsinnig bzw. umständlich
und wie man sieht, ist hier mapnik ähnlicher meinung!
grüßle, georg
@nop: ja super! dann mal weiterhin gutes gelingen!! und auf dass wir endlich wieder baden, segeln oder angeln können!!!
Die wiki sagt zur Insel in einem Loch mit anderer Flächenart:
“Eine solche Konstellation erforderte früher verschiedene Multipolygon Relationen, eine mit “way 1” als äußerem und “way 2” als innerem Ring und eine mit “way 2” als äußerem und “way 3” als innerem Ring. Solche Kaskaden sind nach wie vor zu empfehlen wenn die “Insel” in der Mitte etwas anderes als die äußere Fläche ist. Sind beide das selbe so genügt es ein Loch in einem Loch zu machen.”
…und weiter unten unter “Wald mit zwei Seen und einer Insel (Verschachtelte Multipolygone)” wird im grafischen Beispiel, bei anderer Flächenart der “Insel” ein inneres Multypoligon angelegt, dessen outer-way aus den "inner-ways des äußeren MP besteht?!? (versteht das hier noch einer?)
P.S.: Ich werde Dan Brown vorschlagen, nach “Da-Vinci-Code” und anderen für seinen nächsten Roman “Multipolygons-The Last Mystery” zum Thema zu machen. Wird sicher spannend über 600 Seiten, hat kein happy end und genug Stoff übrig für weitere Fortsetzungen…
+++ bin da voll mit dabei!!!
Klasse Nop,
auch wenn ich keine Ahnung von Optimierung mit partiellen Geometrieindexen habe, ist es deine Erkenntnis wert, hier noch einmal in voller Länge zitiert zu werden.
Ich habe eine Vision:
Nop kriegt das hin. Andere Renderer und Tools können das übernehmen. Die ganzen Vermutungen hier zur Ursachenforschung und -behebung sind hinfällig, wir müssen nicht an den MP und ihren wie auch immer angehängten und gestalteten Teilen herumbasteln, mappen uns eine gemütliche amenity=bench und genießen darauf die Abendsonne (ab April). 
Das alles darf uns aber nicht daran hindern, im Bedarfsfall auch im Interesse der Endanwender und Nur-Eben-So-Mapper auf einfach nachvollziehbare Strukturen und Mapping-Schemata Wert zu legen.
… und wenn es anders kommt als in meiner Vision, haben wir wenigstens keine Langeweile, die uns zwingt, Diskussionen über das taggen von Aufhängehöhen der Hundkot-Tütenspender zu führen 
edit:
Hab mir das auf der RuW mal angeschaut. Der Starnberger See ist wieder schön blau, das kleine Wäldchen ist auch da, allerdings ohne die Wiese und den großen Wald drumherum. Das kriegt Super-Nop aber auch noch hin (daumendrück).
Der Bodensee füllt sich wieder langsam…
Eure Sprüche sind ja mal klasse!
Das Mysterium der Multipolygone wäre sicherlich noch mal einen eigenen Thread wert, in dem man die Vor- und Nachteile der verschiedenen Multipolygonformen nebeneinander stellen könnte.
@ Nop
Ist Dir auch schon eine Idee gekommen, woran es liegen könnte, daß sich überschneidende Multipolygonlinien bei dem von Dir genutzten Renderer bislang zu Fehldarstellungen führten, während in der Mapnikkarte dieser Fehler anscheinend ignoriert wird?
Weiter viel Erfolg beim Programmieren!
Du bist klasse!
Gruß
tippeltappel
Hi,
Ja, so isses. Aber es ist gleichzeitig interessant, denn eine Dimension tiefer ist die Sache plötzlich jedem klar: Wege werden als Liste von Punkten dargestellt und jeder versteht, dass dabei Punkte auftauchen, die keine Tags haben und keiner kommt auf die Idee, Tags des Weges an seine Punkte zu schreiben.
Ich halte es für einen Fehler, dass Flächen keinen eigenen Datentyp haben – es sollte “nodes” (0-dimensional), “ways” (1-dimensional), “areas” (2-dimensional) und “relations” (abstrakte Objektkombinationen) geben.
MfG
Weide
Die Betrachtungsweise eine Dimension tiefer macht wirklich einiges klar. Vielleicht liegt es einfach an der Abstraktionsfähigkeit des Menschen. Unter Knoten, Weg und Fläche kann man sich noch was bildlich vorstellen.
Aber bei Relation??? http://de.wikipedia.org/wiki/Relation_(Begriffskl%C3%A4rung)
Für den optisch orientierten Hobby-OSM-Kartografen ist das nicht so einfach.
Die Idee mit dem Datentyp area finde ich gut.
Was ist an einer Wanderroute über etliche Kilometer so abstrakt? Weil sich mehrere Wanderrouten (oder Buslinien) ein Straßenstück teilen können, gibts dafür eben die Routen-Relationen.
Gruß,
ajoessen
Mit abstrakt meine ich, dass die Relation mit der durch Evolution und Erfahrung geprägten überwiegend optisch orientierten Wahrnehmungsfähigkeit eines durchschnittlichen Menschen nicht einfach zu verstehen ist. Deine genannten Beispiele erschließen sich diesem i.d.R. auch nur, wenn sie optisch dargestellt werden.
Konkret denken Menschen erst mal in sichtbaren Wegstücken.
Deshalb basierte das erste Taggingschema für Radrouten auch darauf, jede Route direkt an jedem Wegstück zu taggen. (lcn=, rcn=…)
Eine Relation ist erst mal “unsichtbar” und manifestiert sich erst über ihre Elemente. Darüber hinaus verwirrt natürlich noch, daß eine Relation je nach “type” Tag völlig unterschiedliche Auswirkungen auf ihre Elemente hat.
bye
Nop
+1
Das ist ein großer Designfehler bei OSM.
Das wurde wohl unter den Entwicklern ausführlich diskutiert, mit dem Ergebnis es sei einfacher möglichst wenig verschiedene Objekttypen zu haben.
Ich persönlich finde es besser, möglichst klar definierte und leicht verständliche Objekte zu haben, nicht möglichst wenig schwammige.
bye
Nop
1+
Klare Definitionen mit eindeutigen Zuordnungen, die man in einem “Lexikon” (einem aufgebohrten “how to map a…”) finden und verwenden kann.
Und wenn ich zur Ausgangsproblematik zurückkommen darf:
Ein noch besser verständliches workarround für Multipolygone, in das auch die (deine?) Notwendigkeiten aus Sicht der Verarbeitung zu Karten und anderen Anwendungen einfließen, macht vor dem Hintergrund dieses Threads (und unzähliger anderer) sicher Sinn und ist überfällig.
Eine Konsequenz daraus ist allerdings, das die in OSM verbreiteten und geduldeten Einstellungen “Hier kann jeder machen, was er will!” und “Was andere mit meinen Daten machen (müssen), ist mir egal!” nicht für alles weiter gelten dürfen.
-1
Kurz mal in den oben schon erwähnten “OGC Simple Feature Standard” reingespitzt,
dort gibt es Flächen (Surfaces) erst als abstrakte Klasse, interessanterweise ist multipolygon keine abstrakte Klasse.
Und wenn man die Unterstützung von z. B. PostGIS haben möchte …
Sudiosi der Geoinformatik werden mich jetzt gleich verbessern
Ciao,
Frank
Hast du dir das wirklich angetan? Ich war mal kurz auf dem Link, der in der Wiki unter Multipolygonen besteht und war gleich wieder weg, weil das Englisch doch meine Fähigkeiten übersteigt 
Mittlerweile habe ich das in Deutsch gefunden und als Wochenendlektüre vorgesehen:
http://www.wheregroup.com/files/praesentation_simple_feature_OGC.pdf
http://www.slidefinder.net/g/geoinformation_iii_vorlesung/5859813
Kann mir jemand sagen, ob die Infos für uns OSMler sinnvoll sind und dem englischen Standard entsprechen? Gibt es irgendwo was anderes leicht verdauliches?
Auf den ersten Blick würde ich sagen:
- durchdachter Standard (aus Geo-Profi-Sicht)
- nicht interessant für uns, da bereits selbst wieder zuviele Objekte, die nicht zutreffen, z.B. Curves
- nicht interessant weil aufgrund der Komplexität nicht intuitiv verständlich