Neusiedler See verschwunden (seit er als Multipolygon gemappt ist)

Dies hängt von der Art des Multipolygons ab.

Bei den “normalen” Multipolygonen, wo man nur eine Außenkontur aus einem einzigen Kurvenzug hat, gibt man die Tags für den Flächentyp direkt an jener geschlossenen Außenkontur an.

Bei “komplexeren” Multipolygonen, wo die Außenkontur aus mehreren aneinander gehängten Kurvenzügen besteht, ist das nicht möglich. Ein einzelner dieser Kurvenzüge bildet keine in sich geschlossene Fläche, sondern ist nur eine Linie. Deshalb kann man diese einzelnen Kurvenzüge auch nicht mit einem Flächentag versehen. Erst das Multipolygon aus allen Kurvenzügen ergibt eine geschlossene Außenkontur und damit ein Fläche. Also müsste hier das Multipolygon die Flächentags bekommen. Aufgrund der sich dadurch ergebenden teilweise hohen Komplexität sowohl für die Renderer als auch andere Bearbeiter, benutzte ich solche Multipolygone daher nur bei Grenzen und vermeide sie ansonsten.

Ja, den Schilfgürtel kann ein Renderer nur mit “viel Glück” richtig hinbekommen. Mehrere vollkommen voneinander getrennte Außenpolygone, außerdem zusätzlich ein Innenpolygon, das irgendwo einsortiert werden muss. Weiterhin passen die Außenkonturen nicht zusammen.

Osmarender scheitert daran definitiv, das weiß ich von anderen solchen Fällen (die hatten wir hier auch im Forum, da ging es nur um Wald statt Schilf). Das kann man dem Renderer hier auch nicht vorwerfen, da er so ziemlich raten muss und aufgrund der kachelbasierten Arbeitsweise ggf. gar nicht alle Informationen geladen hat. Ich muss mal schauen, ob ich das in einzelne getrennten Polygone aufdröseln kann.

Beim See selbst würde ich empfehlen, auf das Multipolygon mit mehreren Außenkurvenzügen zu verzichten und stattdessen mehrere Polygone nebeneinander zu verwenden. Dann hat man zwar überschneidenden doppelte Kanten mit dem Schilfgürtel und außerdem und “Linien” innerhalb des Sees. Dafür aber eine klare Struktur. Beim Bodensee wurde das auch so gemacht (falls es nicht schon wieder irgendwie geändert wurde).

Ja, mich interessieren die Details, da das Probliem in der Rheinaue und im Kottenforst auftritt.
Wenn ich das durch einfaches Ändern, natürlich immer noch korrekt, beseitigen könnte,
fände ich das sehr angenehm. So wie es im Augenblick ist, kann ich die Radfahrerkarte
gerade da, wo die Höhenlinien sehr hilfreich wären (Beispiel Kottenforst), nicht verwenden.

In beiden Beispielen handelt es sich um relativ einfache Multipolygone mit einem
geschlossenem Weg als Outer aber mehreren innen liegenden Flächen, die teilweise
selber Multipolygone sind (Inseln im See). Welcher der vielen Seen/Teiche, im
Kottenforst tatsächlich ausläuft, ist dann die nächste Frage.

Edbert (EvanE)

Ja, genau das geht eben nicht. In Krefeld war neulich die gesamte Innenstadt eine Kirche, weil das landuse-mutlipolygon residential einen Platz als inner hatte, der wiederum outer war mit der Kirche als inner.
Bei sowas blickt eben der Renderer eventuell nicht mehr durch.

Als würgaround die inner allesamt nicht als multipolygon ausbilden, sondern als einfache Fläche, und dicht daneben innerhalb ein neues multipolygon setzen. Oder an geeigneter Stelle aufschlitzen.

gruß,
ajoessen

Verschachtelte aber getrennte Multipolygone sollten kein Problem für ein Renderer sein.
Ich meine diese Beispiel :

EIne Insel im See und der See liegt in einem Wald.

Multipolygon1: Wald(outer) See (inner)
Multipolygion2: See(outer), Insel (inner)

Wenn ein Renderer so etwas einfaches nicht schafft, dann ist das ein Bug der gemeldet werden sollte.

Das ist übel. Dieses einfache Beispiel sollte meines Erachtens jeder Renderer können.
Dass ein Renderer Probleme mit einem Teil der “Advanced Multipolygons” haben kann,
ist ja noch nachzuvollziehen, aber Multipolygon in Multipolygon sollte jeder Renderer können.

Die Würgarounds sind für mich alle nicht akzeptabel.

Da werde ich wohl meinen ersten Bug-Report ins OSM Tracking-System einstellen müssen.

Edbert (EvanE)

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 :wink: , 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. :slight_smile:

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. :wink:

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. :slight_smile: (wenn auch keine echte Radfahrerkarte, oder doch?)

Immer gut, habe ich auch noch nie gemacht. :slight_smile: Bei Osmarender kann das wohl helfen.

Für die OpenCycleMap ist das OSM Tracking-System aber wohl nicht “zuständig”. Die macht Cloudmade unabhängig von jenem. Ich erinnere mich “dunkel” daran, dass dies früher auch schon mal jemand aus dem Forum oder der Mailing-Liste versucht hat. Aber mal sehen, vielleicht höhlt steter Tropfen ja auch irgendwann diesen Stein. :wink:

Das kannst du ja gerne machen, aber bis das gefixt ist, vergehen vermutlich Monate (besonders bei der Cycle Map). Da ist es doch einfacher, seine Mulitipolygone einfach zu halten.

Gruß,
ajoessen

Erst mal Danke für deine ausführliche Beschreibung der Sachverhalte im Allgemeinen
und der Probleme von OpenCycleMap im Besonderen.

Soweit ist das mit den einfachen Multipolygonen erst mal klar.
Es ist so wie man es erwartet und im Wiki beschrieben ist.

Die Drehrichtung des Sees scheint keinen direkten Einfluss zu haben, das hatte ich bereits
ausprobiert. Allerdings habe ich dabei nicht auf die Richtung des Aussenpolygons geachtet.
Das werde ich als nächstes ausprobieren.

Die Richtung des Sees hat bei den anderen Renderern scheinbar keinen Einfluss, solange der
See einen geschlossenen Weg als Aussenkontur hat. Von daher kann ich das durchaus probieren.

Den Tip mit dem Outer als letztes Member werde ich ebenso testen.

Linie über Linie mag ich überhaupt nicht. Eine Extra-Kontour wäre unübersichtlich.
Das werde ich auf keinen Fall machen.

Auch das Aussenpolygon aufzutrennen scheint mir in den beiden erwähnten Fällen
kein sinnvolle Lösung zu sein.

Wenn meine weiteren Versuche keine Besserung bringen, werde ich und die anderen
wohl mit den Unzulänglichkeiten von OpenCycleMap leben müssen.

Edbert (EvanE)

Gute Nachricht, Cloudmade und OSM haben sich letzten Sommer darauf geeinigt,
das OSM-Tracking-System auch für die OpenCycleMap zu benutzen.
Siehe: http://trac.openstreetmap.org/query?status=new&status=assigned&status=reopened&component=opencyclemap&order=priority

Auch das Multipolygon-Problem ist dort schon verzeichnet. Siehe Ticket 1656.
Dort schreibt Andy Allen am 16.Dez.2009:
Definitely a problem with osm2pgsql’s handling of multipolygons,
where the tags from “inner” members get applied to the whole polygon.
An update of osm2pgsql will fix this, just need to check how modern
versions work in non-slim mode.

Den Wahrheitsgehalt kann ich nicht einschätzen. (BTW: Umbruch von mir)
Auf jeden Fall ist das ein bekanntes und noch nicht vergessenes Problem.
Ich werde das mit meinen Beispielen noch einmal in Erinnerung bringen.

Edit 13:09: Und erledigt.

Edbert (EvanE

Stimmt, schon vor über einem Jahr wurde auch die (englische) WIKI-Seite entsprechend angepasst. Früher sollten sich Seen im Uhrzeigersinn drehen. Das man schon lange davon abweichen kann, war mir bis jetzt entgangen.

(Ergänzung, 09.03.2010: der im folgenden zusammengefasste behelfsmäßige Workaround funktioniert doch nicht.)

Wie gesagt, Multipolygone scheinen meinem Eindruck nach dann in der OpenCycleMap korrekt zu sein, wenn
a) alle Innenpolygone ohne Ausnahme gegen den Uhrzeigersinn drehen,
b) das Außenpolygon im Uhrzeigersinn dreht,
c) das Außenpolygon ganz unten in de Relationsliste steht.

Mit Seen hatte ich das aufgrund meiner veralteten Drehrichtungsannahme nie so gemacht. Aber z.B. bei Multipolygonen mit Wald und Wiesen scheint das Rendering in der OpenCycleMap dann ok zu sein. Ob a) bis c) vollständig notwendig sind, sei dahingestellt. Aber ob man nun nur a), b) oder c) oder alle beachtet, ist vom Aufwand kein großer Unterschied. Da das ganze vollkommen konform mit den sonstigen Mapping-Regeln ist, kannst Du es mit Seen mal testen. Es sollten keine Diskussionen über Mappen für die Renderer ausbrechen. Nur daran denken, dass die OpenCycleMap sich nur einmal die Woche aktualisiert.

Last edited by Ebbe73 (2010-02-25 15:29:18)

Da das Ganze den Mapping-Regeln nicht widerspricht, sollte es keine Diskussion geben.
Es ist allein meine Sache ob ich den Zusatzaufwand betreiben will, OpenCycleMap mit
seinem Blindenstock zu helfen, das Gebiet richtig zu rendern.

Allein schon aus Neugier werde ich das mindestens einmal machen.

Der Ärger mit dem seltenen Update ist mir leider nur zu klar.
Gemeiner Weise schreiben die nicht, von wann die Daten sind, die sie Rendern.

Nochmal Danke für deine vielen Informationen.
Edbert (EvanE)

Nach meiner Erfahrung im Laufe des Donnerstag mit den Daten von Dienstag.

Gruß,
ajoessen

Obige Workarounds sind übrigens falsch bzw. funktionieren nicht (oder nur “zufällig”)… obwohl ich selbst diese vorgeschlagen habe. :wink: Ich habe sie mal gezielt ausprobiert und keinen Erfolg gehabt.

Wir müssen also wohl doch warten, bis dies in der OpenCycleMap behoben wird bzw. deren osm2pgsql-Version aktualisiert wird.

Ich muß den Faden nochmal herholen:

auch der Feldmochinger See, der eigentlich dem einfachstmöglichen multipolygon entspricht, ist im Mapnik futsch.
http://www.openstreetmap.org/browse/way/4410879
Kann mir das einer erklären? Ich dachte, ich hätte die Mutipolygone inzwischen verstanden.

Baßtölpel

Hast Du vermutlich auch. :slight_smile:

Dieses Problem wird an den TMC-Tags liegen, welche dem Multipolygon irgendwann später hinzugefügt wurde, siehe folgendes Posting zu dem gleichen Problem beim Steinhuder Meer (bei Hannover) und dem Überlinger See (Teil des Bodensees):
http://forum.openstreetmap.org/viewtopic.php?id=7177

Darauf zu kommen, war etwas tricky. Die Behebung ist aber einfach, die TMC-Tags müssen vom Multipolygon an den "outer-way"verschoben werden. Da ich den See nun sowieso gerade in JOSM geöffnet habe und das Verschieben der Tags nach Kenntnis des Problems eine einfache Tätigkeit ohne zusätzlichen Lerneffekt ist, habe ich das auch gleich gemacht.

Also, soweit ich aus Versehen keinen neuen Fehler eingebaut habe…