In Mapnik sind Teile von Norditalien unter Wasser
http://www.openstreetmap.org/?lat=44.593&lon=9.426&zoom=10&layers=B000FTF
Da scheint es entweder Probleme mit der Küste zu geben oder macht der Renderer Probleme ?
Das sieht nach einem Mapnik-Fehler aus, weil die “Küstenlinie” 100% rechteckig ist, sich nicht auf Tiles beschränkt und je nach Zoomlevel an unterschiedlichen Positionen ist. Wäre es ein Fehler in den Rohdaten, wäre die Linie in jedem Zoomlevel an der gleichen Stelle.
Die Verarbeitung von Küstenlinien ist bei mapnik ab einer gewissen Zoomstufe anders.
Das ist auf jeden Fall ein Problem mit einer coastline.
Ja, sieht nach einem coastline-Problem aus. Vor ca. einer Woche wurden die dort bisher zusammenliegende coastline und boundary getrennt. Danach hat ein Mapper zwei Abschnitte der coastline zu einem neuen gemeinsamen verknüpft. Ob das schon Behebungsversuche für den Fehler waren oder dessen Ursache, weiß ich nicht.
Die genannten Edits erscheinen mir ok, fehlerfrei und sinnvoll. Ggf. waren sie nur der Anstoß zum Neurendern der Kacheln durch Mapnik. Dieses hat dann eventuell aufgrund zwischenzeitlicher Veränderungen in den Render- oder anderer Routinen den Fehler produziert.
Ich habe das mit über 1700-Punkten sehr lange coastline-Segment mal aufgesplittet. Geholfen hat dies aber nicht.
… und Osmarender hat am Genfer See Wasserprobleme …
http://osm.org/go/0CHV@1G–?layers=0B00FTF
Viele Grüße
Dieter
Ja, jene sind aber ein Beispiel für die fehlende Abstimmung zwischen den Programmierern der Renderer und den Mappern bzw. Tag-Erstellern. Das Multipolygon des Genfer Sees ist OSM-technisch vollkommen korrekt und fehlerfrei. Der zugrundeliegende Aufbau ist für einen Renderer, der wie Osmarender funktioniert, bei Multipolygonen jener Größe aber kaum vernüftig umsetzbar. Bei Osmarender rendern viele unterschiedliche Rechner jeweils einzelne Kartenkacheln. Zum Rendern einer Kachel lädt der jeweilige Rechner nur den jeweils benötigten Bereich und etwas “drumherum” herunter. Andernfalls würden die Datenmengen schnell zu groß werden. Die Daten von weiter außen liegenden Objekte hat der Rechner also nicht und kann sie beim Erstellen der Kartenkachel nicht berücksichtigen.
Bei Gebieten wie dem Genfer See kann daher folgendes auftreten: bei Kacheln mitten innerhalb des Sees weiß Osmarender nicht, dass es sich um Wasser handelt. In den heruntergeladenen Daten sind keine Informationen über Wasser vorhanden, da der Seerand bzw. das Multipolygon mit den diesbezüglichen Daten außerhalb des heruntergeladenen Bereichs verläuft. Osmarender rendert also kein Wasser, sondern eine weiße Fläche. Am Seerand kann es passieren, dass Osmarender mangels vollständiger Daten des Seerandes nicht weiß, auf welcher Seite der Randkontur das Wasser liegen soll. Es wird ggf. auf der falschen Seite gerendert.
Dies ließe sich vermutlich durch das Herunterladen von mehr Daten beheben, jenes würde aber eine höhere Netzwerklast, langsamere Rendergechwindigkeit etc. bedeuten und dem Kachelprinzip von Osmarender etwas zuwider laufen.
Hier muss man sich also entscheiden: Entweder man hält sich “systematisch” an das Prinzip, mein Multipolygon ist technisch korrekt, ich mappe nicht für die Renderer, die Osmarender-Programmierer müssen nachbessern. Oder man ist “pragmatisch” und sagt, ich kann nicht alles stur nach den Regeln umsetzen, sondern muss eben doch manchmal Rücksicht zumindest auf die wichtigsten Renderer nehmen.
Ich persönlich würde in jenem Fall bei einem Objekt wie dem Genfer See den zweiten “pragmatischen” Ansatz wählen. Das Multipolygon des Sees wäre dann allerdings weniger “schön”, würde aber korrekt gerendert werden. Da der See aber kein “ruhendes” Objekt ist, welches monatelang von keinem Mapper angefaßt wurde, sondern aktiv in den letzten Wochen bearbeitet wurde, werde ich mich dort nicht einmischen und den See umbauen. Da müssen die Vor-Ort-Mapper selbst ihre Prioritäten setzen.