Fehler in sea.zip?

ich erzeuge meine Karten seit langem mit mkgmap und unter anderem der Option precomp-sea=q:\sea\sea.zip.
Ich habe heute eine neue Version von sea.zip heruntergeladen und eine kleine Karte erzeugt, welche etwas Land und etwas See vom Bodensee (Überlingenr See / Überlingen) beinhaltet. Ergebnis: Auch das Land ist unter Wasser.
Ich habe dann eine alte Version von sea.zip (6.9.2015) verwendet, (sonst nichts geändert!) da unterbleibt die Überschwemmung. Und ich habe (mit der aktuellen Version) den Ausschnitt etwas verschoben, so dass nichts mehr vom Bodensee drauf ist, da ist auch alles OK.

Hallo,

könnte daran liegen, dass die sea-Tiles innerhalb der Zip-Datei nochmals im Unterverzeichnis “sea” liegen.

Grüße
Mario

Sorry, ich übersah: “Und ich habe (mit der aktuellen Version) den Ausschnitt etwas verschoben, so dass nichts mehr vom Bodensee drauf ist, da ist auch alles OK.”

Noch ein Edit: Da spielt eher ein “Multipolygon über Kachelgrenzen” eine Rolle, welches mit der sea-Erzeugung nichts zu tun hat. Es sei denn, jemand hat irgend ein natural=coastline im Binnenland getaggt.

Der Bodensee sollte in sea.zip nicht auftauchen. Schick mal ein paar mehr Details, insbesondere die mkgmap Optionen und wie Du den “Ausschnitt” erzeugst.

edit: Und da wir schon von uralten Daten sprechen: Nenne bitte auch die Versionen der beteiligten Programme bzw. stelle siche, dass sie aktuell sind.

Die osm Datei erzeuge ich als kleine Testdatei indem ich den entsprechenden Ausschnitt in josm aufrufe und als osm Datei speichere

die mkgmap optionen sind in einem txt File wie folgt:


echo on
FID_ %3
cd …\erg2
java -ea -Xmx8000m -jar q:\mkgmap-r4255\mkgmap.jar --read-config=q:\a2%4.txt --family-id=%3 --mapname=%3000 --description=%2 q:\erg1*.osm.pbf q:\stile%3.txt

del q:\stile%3.txt


Rendern zu ich das mit folgender Batchdatei:


echo off
Echo Param1: .osm oder .osm.pbf File ohne Extensions
Echo Param 2 Dateiname
Echo Param3: FID
pause
setlocal
prompt $p $t$g
del /Q Q:\erg1*.*
del /Q Q:\erg2*.*

if exist q:\osm_Daten%1.osm set name=%1.osm
if exist q:\osm_Daten%1.osm.pbf set name=%1.osm.pbf

if exist q:\Polygone%1.poly goto Mit

java -Xmx8000m -jar q:\splitter-r591\splitter.jar --precomp-sea=q:\sea\sea.zip --max-threads=auto --output-dir=Q:\erg1\ –max-nodes=1000000 --mapid=6%3001 --overlap=0 q:\osm_Daten%name%
goto Teil2
:Mit
java -Xmx8000m -jar q:\splitter-r591\splitter.jar --precomp-sea=q:\sea\sea.zip --polygon-file=Q:\Polygone%1.poly --max-threads=auto --output-dir=Q:\erg1\ –max-nodes=1000000 --mapid=6%3001 --overlap=0 q:\osm_Daten%name%

:Teil2
call q:\a2\kern.bat %name% %2 %3 config

copy gmapsupp.img Q:\karten%2.img
rem copy osmmap.img Q:\karten\Uebersicht_%2.img
cd …\a2
endlocal

beep


wobei das Unterprogramm kern.bat wie folgt ist:


echo on
FID_ %3
cd …\erg2
java -ea -Xmx8000m -jar q:\mkgmap-r4255\mkgmap.jar --read-config=q:\a2%4.txt --family-id=%3 --mapname=%3000 --description=%2 q:\erg1*.osm.pbf q:\stile%3.txt

del q:\stile%3.txt


Das FID_ ist ein selbst geschriebenens Pacal Programm mit dem ich die FID abändere.
Das mkgmap ist von heute, das sea.zip ebenfalls.
Mit allem anderen arbeite ich schon seit ein paar Jahren erfolgreich, zuletzt habe ich z.B. am 20.November DACH von geofabrik geladen und gerendert. Da bleibt der Bodensee in seinen Grenzen.

Es fällt mir schwer, den Fehler woanders zu suchen als in sea.zip oder mkgmap von heute

Ist denn in der Eingabedatei, die JOSM speichert, der komplette Bodensee drin? Wenn nicht, dann muß mkgmap wahrscheinlich raten und das Ergebnis ist schwer vorhersehbar. Die sea.zip sollte da vollkommen egal sein, weil der Bodensee eben keine Küstenlinie ist bzw. nicht sein sollte. Was steht inder Datei, die in --read-config=q:\a2%4.txt aufgerufen wird?
Wenn das nicht weiter hilft, lade bitte mal die Eingabedatei bei http://files.mkgmap.org.uk/ hoch, gezipt oder so.

Gerd

Die Eingabedatei habe ich mit dem Vermerk “für GerdP” hochgeladen. Es ist nur ein ganz kleiner Ausschnitt. Das %4.txt verweist auf die Konfigurationsdatei:


echo off
Echo Param1: .osm oder .osm.pbf File ohne Extensions
Echo Param 2 Dateiname
Echo Param3: FID
pause
setlocal
prompt $p $t$g
del /Q Q:\erg1*.*
del /Q Q:\erg2*.*

if exist q:\osm_Daten%1.osm set name=%1.osm
if exist q:\osm_Daten%1.osm.pbf set name=%1.osm.pbf

if exist q:\Polygone%1.poly goto Mit

java -Xmx8000m -jar q:\splitter-r591\splitter.jar --precomp-sea=q:\sea\sea.zip --max-threads=auto --output-dir=Q:\erg1\ –max-nodes=1000000 --mapid=6%3001 --overlap=0 q:\osm_Daten%name%
goto Teil2
:Mit
java -Xmx8000m -jar q:\splitter-r591\splitter.jar --precomp-sea=q:\sea\sea.zip --polygon-file=Q:\Polygone%1.poly --max-threads=auto --output-dir=Q:\erg1\ –max-nodes=1000000 --mapid=6%3001 --overlap=0 q:\osm_Daten%name%

:Teil2
call q:\a2\kern.bat %name% %2 %3 config

copy gmapsupp.img Q:\karten%2.img
rem copy osmmap.img Q:\karten\Uebersicht_%2.img
cd …\a2
endlocal

beep


Warum mkgmap bei einem kleinen Ausschnitt raten muss, verstehe ich nicht.
Und ich habe es mal mit dem vorherigen mkgmap 4244 versucht, derselbe Fehler.
Es scheint also alleine an sea.zip zu liegen.
Warum mein recht komplexer Aufbau: Ich habe mit diesen Dateien mit möglichst geringen Änderungen auch Höhenlinien und Skipisten gerendert.
Ich gehe jetzt schlafen, zwischenzeitlich schon mal vielen Dank für Deine Bemühungen, vielleicht sehe ich morgen ausgeschlafen etwas klarer.

Die Multipolygone zum Bodensee / Überlinger See sind in der Tat unvollständig. Die Datei, die Du hier zeigst, ist eine Batch-Datei. Damit könnte mkgmap gar nichts anfangen, kann also nicht die richtige sein. In der gesuchten Datei müssten mkgmap Parameter wie route oder index stehe. Wenn ich die Skripte richtig verstehe, hast Du eine config.txt.

Warum kommt es bei unvollständigen Multipolygonen zu solchen Effekten? Weil mkgmap raten muss, wo die fehlenden Wege verlaufen.
Im vorliegenden Fall hätte ich allerdings keine Probleme erwartet, das werde ich mir noch mal genauer anschauen. Vermutlich, weil die untere rechte Ecke Deines Ausschnitts im Bodensee liegt. Ich meine, dass es gut funktioniert, wenn ein MP nur zu einer Seite hin offen ist.
Ist aber eher unwichtig. Dein Skript zeigt ja, dass Du normalerweise mit größeren Extrakten umgehst und dann splitter verwendest. Damit werden diese Probleme dann schon im Vorfeld vermieden. Wenn Du aber Daten in JOSM runterlädst, dann soltest Du zumindest sicher stellen, dass die MP vollständig sind.
Falls Du auch diesen kleinen Ausschnitt auch mit splitter mit den oben gezeigten Optionen verarbeitest, dann hat der Inhalt von sea.zip einen Effekt auf die Berechnung der Kacheln, je nachdem, wie die Datei in Q:\Polygone aussieht. Möglicherweise liegt dadurch die bounding box anders.

Gerd

edit: Habe gerade mal ausprobiert, was mkgmap mit der ueb.osm macht. Da treten wie erwartet keine Probleme auf, der Bodensee läuft nicht aus. Dein Problem dürfte also die Verwendung von splitter in Kombination mit *.poly sein.

Um Fehler in meiner *.osm Datei auszuschliessen, habe ich heute die von Geofabrik geladene Datei des Regierungsbezirks Tübingen verwendet.
Ergebnis: mit dem sea.zip aus 2015: alles i.O
mit dem sea.zip von gestern: alles unter Wasser
ein Poly file des Gebiets ist übrigens nicht geladen.
Ich gebe es jetzt auf und arbeite vorerst mit dem alten sea.zip weiter. Für einen Urgrossvater wird es zu anstrengend.

Doch noch ein Nachtrag: beim Aufräumen des Computers habe ich eine neue Datei sea.zip geladen. Mit der funktioniert es.
Die gestrige sea.zip hatte 189293 kB, die heutige 209 486 kB.
Ich vermute jetzt: Beim gestrigen Download der sea.zip ist was schief gelaufen und ich habe mit einer beschädigten sea.zip gearbeitet.