Ich hoffe, daß auf diese Weise zwei Bilder sichtbar werden. Sie zeigen den Bodensee, die Karten mit splitter und mkgmap erzeugt im Prinzip aus dem gleichen Datenmaterial von geofabrik (am 10.7 bzw 11.7 heruntergeladen.). Einmal ist es ein Ausschnitt aus der Karte Alpen (alles in Ordnung), das andere ist ein Ausschnitt aus der Karte Deutschland. Offensichtlich kommt hier ein Multipolygon mit den Kartenrändern in Konflikt. Der Effekt tritt auf, gleich ob ich in Splitter die Option --polygon-file= … dazu nehme oder nicht.
Ein Auszug aus meiner erzeugenden Batchdatei:
:Ohnepoly
java -Xmx4000m -jar q:\prog_r304\splitter.jar --overlap=0 --keep-complete=true --precomp-sea=q:\sea\ –output-dir=Q:\erg1\ –max-nodes=600000 --mapid=6%3001 q:\osm_Daten%1
“Schau” Dir mal die Original-Daten an: Ist das Bodensee- MP komplett in dem DE Auszug enthalten oder nicht?
Das Anschauen könnte bei der Dateigröße ein Problem sein, aber mit LINUX grep/sed etc. sollte man an die
wichtige Info kommen.
So ist es, ich habe kein Linux und josm steigt bei dieser Dateigrösse aus.
Das Problem dürfte mit den Multipolygonen Bodensee (Rheinsee) und Bodensee(Zellersee) zusammenhängen, denn wenn ich mir die “Fehlergrenze” zwischen Konstanzer Hörnle und Insel Reichenau in josm anschaue, wird diese nur von diesen beiden Multipolygonen gebildet.
Spekulation: Es könnte damit zusammenhängen, daß ich mit recht kleinem Wert --max-nodes=600000 arbeite (grosse Werte haben immer mal wieder leere Flächen in der Karte erzeugt) und damit ein Multipolygon über mehrere Kachelgrenzen über den eigentlichen kartenrand hinaus verläuft. Ich werde also mal dieselben Daten mit --max-nodes=1600000 bearbeiten.
Der “Fehler” liegt in den Roh-Daten. Der Bodensee ist auf der Grenze, an welcher geschnitten wurde (Deutschland-Extrakt). Da bringen verschiedene Splitter-Optionen nur wenig Unterschiede, trotz evtl. gefundenem, bestem Aussehen sind immer noch die Fehlstellen in den Daten vorhanden. Wer Grenzregionen benötigt, muss auf den Europa-Extrakt zurückgreifen und selbst schneiden.
Der Fehler sollte vor dem Schritt Splitter liegen. Mit keep-complete packt splitter alle Objekte komplett in das Kachel, die einen Teil in einer Kachel haben. Wenn die Daten nicht in der Quelle sind, kann splitter die natürlich auch nicht in die Kacheln kopieren. Wenn du dein Extrakt nicht untersuchen kannst, könntest du bspw. europe herunterladen und mit der generierten areas.list schauen, ob dann der Bodensee vorhanden ist. Alternativ ginge wohl auch das Alps-Extrakt, wenn es das noch gibt.
Ich bin zurück von einem wichtigen Test: Ich war schwimmen im Bodensee und konnte mich davon überzeugen, daß an Stellen, an welcher meine Deutschlandkarte “Land” zeigt, doch noch ausreichend Wasser ist.
@ Henning: Ja, das Alps Extrakt gibt es noch, die als richtiges Beispiel gezeigte Karte stammt davon. Insofern ist das Ganze für mich kein Problem sondern nur ein Schönheitsfehler. @Mario: daß der “Fehler” in den Rohdaten liegt, ist wohl richtig. Dennoch kann dies noch nicht die ganze Wahrheit sein. Denn ich habe mal die Deutschlandkarte von Raumbezug heruntergeladen, welche dasselbe Ausgangsmaterial verwendet. Sie zeigt zwar zwischen Örlikon am Rhein und Obergailingen genau dieselbe Grenze zwischen blau und gelb wie meine Deutschlandkarte, Der gesamte Überlinger See, (in dem ich soeben schwimmen war) ist jedoch noch nicht verlandet.
Übrigens: das max-nodes=1600000 hat keine Besserung gebracht. Ich werde in Splitter mal das keep-complete weglassen.
Danke für alle Antworten.
Was mich verwundert: Der Bodensee wird durch drei Multipolygone beschrieben, welche sich nicht nur überlappen, sondern sogar teilweise dieselben Elemente verwenden. (ID 1156846, ID 1547658, ID 2066485). Ich könnte mir vorstellen, dass eine solche Konstellation das Programm durcheinanderbringt. Ich verstehe von MP’s sowie von den Programmen splitter und mkgmap leider viel zu wenig, so dass ich dem nicht weiter nachgehen kann.
Mal ne allgemeine Frage an die Relation-Fachleute.
Hab mir letzte Woche den Bodensee auch mal näher angeguckt, weil auf den openandromaps (Android-Vektorkarten) der ganze Hauptsee plötzlich komplett weiß war (oder noch ist? kA). Die BaWü-Karte hat dort sehr großzügige Grenzen und der See ist komplett drauf mit noch reichlich Umland ringsrum. Mit den vorigen Ständen war noch alles okay, das ist erst mit dem Wechsel vom 17.Juni auf 2.Juli passiert lt. Datum von FTP-Seite, also liegt es vermutlich eher an Detail-Änderungen als an grundsätzlichen Problemen.
Hatte dann ein paar Häfen und Marinas verglichen, dabei festgestellt, dass die ganz unterschiedlich eingetragen sind, konnte aber nicht rauskriegen, was denn nun eigentlich richtig sein soll und hab die Finger davon gelassen.
Aber was ist denn nun richtig? Sind Häfen etc. nun relation-relevante Flächen oder nicht??
Wenn z.B. in einem riesigen Wald tief drin jemand eine winzige Wiese reinmalt und die nicht ans Multipolygon anbindet, kann das bei empfindlichen Renderern die Wald-Aussengrenze stören. Wenn man dagegen sowas wie ein Naturschutzgebiet oder Truppenübungsplatz reinmalt, darf das problemlos kreuz und quer über verschiedene anderen Flächen liegen, das macht gar nichts. Die sind für überlappte Flächen neutral. Aber welches Verfahren nun bei Seen mit Yachthäfen etc. angewendet werden soll hab ich bisher noch nicht rausgekriegt.
=> Soll man sowas wie Yachthäfen vom See flächenmäßig abtrennen oder nicht?
Bzw. dürfen die sich überlappen, oder müssen sie es sogar?
=> Muss man denen zusätzlich zu leisure=marina auch noch natural=water verpassen, ist das egal, oder gar verboten? Denn wenn Marinas nicht Teil vom See sind und auch kein natural-water, lässt Mapnik die Fläche anscheinend leer?
Und wie ist das mit swimmingspools und Stränden innerhalb der See-Relation-Fläche, mit halb ufer-überlappenden Waterparks etc.? Bei solchen Flächentypen hab ich ja schon wesentlich stärkere Zweifel, ob das okay ist… Falls nicht, vielleicht kann mal jemand Schlaueres das korrigieren, war am Südufer, glaub so etwa bei Romanshorn und etwas östlich davon. Westlich herum bis Überlingen hab ich am Ufer nur normale Sachen gesehen (Marinas in allen Variationen), andere Uferabschnitte hab ich dann nicht mehr angeschaut.
In meinen Augen sollte ein guter Renderer die Flächen einlesen, umsetzen (Auswertung der Tags, Zeichenreihenfolge etc.) und auf die Karte malen. Wenn eine kleine Wiese, die nicht im MP ist dazu führt, dass das MP nicht gerendert wird, dann ist der Renderer irgendwo kaputt oder aber es ist so gewollt. Bspw. weil er soclhe Fehler visulisieren möchte.
Das ist relativ einfach. Garnicht an Überlappung denken. Es geht beim Wald-Multipolygon nur um die Frage “Wo ist Wald?”. Wo eine Wiese ist, kann nunmal kein Wald sein. Ein Naturschutzgebiet kann aber ohne Weiteres auch Wald enthalten. Nur über die Realität nachdenken, nicht über die Tags.
Hinterlistig ist da allerdings “landuse”, weil es “die Hauptnutzung” angibt. Daher können sich zwei “landuse”-Flächen nie überlappen, denn es können ja nicht beide “die Hauptnutzung” sein. Das führt manchmal zu eigenartigen Ergebnissen: Ein nicht allzu oft militärisch genutzter Acker könnte auf zwei Arten angegeben werden, beides kann man aber nicht angeben. Die Entscheidung ist dann willkürlich, aber an muss sich entscheiden. Das hat aber nichts mit Multipolygonen zu tun, es passiert bei landuse auch ganz ohne Multipolygone.
Wie man sich auch entscheidet:
Über “inner”-Teile kann man aus Multipolygonen nichts rausnehmen, was am Rand liegt. “inner”-Teile müssen innen sein. Da muss man statt dessen die äußere Grenze verändern.
Keine Fläche sollte doppelt mit natural=water versehen werden.
-“marina” hat gewöhnlich Teile an Land und Teile im Wasser, ist daher nicht automatisch Wasser. Irgendwo muss der Wasserteil der Marina also ein natural=water kriegen – entweder als Teil des Sees oder als eigenes Gebiet.
Das ist wahrscheinlich der Kern der Sache, und gut zusammengefasst!
Ja die Wiki-Seite hatte ich schon auch gesehen, aber dann hatte mich wieder diese Warnung untendran verwirrt:
…was war jetzt genau gemeint mit “suitable tagging”, das stand nicht mehr dabei, ein Beispiel hätte geholfen…
… und dass anscheinend jeder auf seine eigene Weise tagged, wenn ich die vorhandenen Häfen so angucke…
Aber ich nehm das jetzt mal so als Ergebnis mit:
Marinas sind flächenmäßig neutral und müssen NICHT in relations
Ob separate Fläche oder überlappender Teil vom See ist egal, denn eigentlich ist es gar keine gefüllte Fläche, schließt auch Landteile mit ein
Irgendwoher muss “water” kommen, normalerweise als überlappender Teil vom großen See. Oder bei separaten Flächen als eigenes zusätzliches natural-Tag (wobei dann aber keine Landteile mehr Teil der Marina sein dürfen, ansonsten muss das Hafenwasser nochmal als eine weitere, eigene Fläche gezeichnet werden)
Zwei der Bodensee Relationen hatten vor kurzem Fehler, nämlich sich kreuzende Außenlinien. Ist inzwischen behoben. Vielleicht führte das zu Rendering Problemen?
Dass sich MP die Ways “teilen” ist durchaus üblich und absolut ok so. Gerade bei Grenzen wird das zu 100% durchgezogen, an anderen Stellen wird da schon mal geschlampt. Programme haben i.d.R. keine Probleme damit (zu haben).,
Aber hier überlappen sich die Flächen gleicher Art und das ist falsch. Der Zeller See hat glaube ich sogar dreifaches Wasser. Am Rand des Zeller Sees hört also eine Wasserfläche auf und nirgendwo steht, dass dort eine neue anfängt – das darf ein Renderer als Land verstehen. Wenn da Wasser gezeichnet wird, dann ist das Zufall durch eine andere Verarbeitungsreihenfolge oder ein Entgegenkommen der Renderer bei gängigen Fehlern. Wir hatten kürzlich dasselbe Problem beim Tegernsee http://forum.openstreetmap.org/viewtopic.php?id=21693
Lade die Pics zu einem Free-Hoster hoch und verlinke sie hier. Ich mach das mit 
