mkgmap: Zu hohe max-nodes ergeben Fehler

Zuerst mein Resultat: Die Splitter/mkgmap Kombination mit max-nodes=3000000 ergeben etwa 50% leere “tiles” und die resultieredne Datei ist weniger als halb so gross als sie sein sollte. Die Karte hat viele leere Rechtecke. Mit max-nodes=2000000 fallen noch 8 von 86 tiles aus, mit max-nodes=1500000 keine mehr.

Details: Ich habe mit untenstehender Batchdatei die Datei germany.osm.pbf, am 7.12. von Geofabrik heruntergeladen, mit Splitter (Version r200) sowie mkgmap (Version 2384) auf einem Rechner mit Java 64 Bit(Version 7 Update 9) bearbeitet und dabei den Parameter max-nodes verändert. Dabei entstehen in Splitter xxx.osm.pbf Dateien (die scheinen in Ordnung zu sein) und dann in mkgmap zuerst xxy.img Dateien. Dabei werden, bei max-nodes=3000000 etwa die Hälfte der über 100 xxy.img Dateien mit 0 Byte Grösse abgespeichert, obwohl die Beobachtung des Rechenfortschritts anzeigt, daß auch diese Teile zwischen 10 s und 30 s zur Berechnung benötigen. Irgendeine Fehlermeldung erfolgt nicht. Die resultierende Gesamtkarte ist dann nur ca 550 MB gross und zeigt in Basemap einen entsprechenden Fleckenteppich. Einen Zusammenhang zwischen der Grösse der xxx.osm.pbf Dateien und der der entsprechenden xxy.img Dateien konnte ich nicht erkennen, ebenso keinen Zusamenhang mit dem Rechenfortgang oder mit der Position auf der Karte…
max-nodes auf 2000000 gesetzt ergibt folgendes: 8 von 86 der xxy.img Dateien haben 0 Bytes Grösse, die Gesamtdatei ist ca 1,3 GB gross. Die hier leeren Bereiche der karte waren alle in der Version mit 3000000 max-nodes auch schon leer.
max-nodes=1500000 ergibt keine leeren Dateien mehr, die resultierende Gesamtdatei ist ca 1,5 GB gross. Die Rechenzeit ist dabei kaum grösser als bei max-nodes=2000000.
Da ich noch Anfänger bin, kann es durchaus sein, daß der Fehler an mir liegt. Ich kann mir aber nicht vorstellen, woran das liegen könnte. Ich habe eher den Eindruck mkgmap müsste eine Fehlermeldung absetzen, wenn trotz intensiver Rechenarbeit nur 0 Bytes grosse Dateien ausgegeben werden.
Die Batch Datei:
*prompt $p $t$g
echo Vorbereiten:meinTyp kopieren als meinTypxxxx.typ und darin FID ändern(xxxx= FID)
echo Param1=Kartenosm Param2=Kartenname Param 3 = 4 stellige FID *

java -Xmx3000m -jar q:\prog_r200\splitter.jar --overlap=6000 --output-dir=Q:\erg1\ –max-nodes=1500000 --mapid=6%3001 %1

java -ea -Xmx3000m -jar q:\prog_2384\mkgmap.jar --preserve-element-order --remove-short-arcs --precomp-sea=q:\sea\ –gmapsupp --draw-priority=25 --route --style-file=q:\stile\meinStil --family-id=%3 --family-name=Karte --mapname=%3 --description=%2 q:\erg1*.osm.pbf q:\stile\meinTyp%3.TYP

copy gmapsupp.img Q:\karten\Karte_%2.img

Was wolltest du uns mit deinem Post jetzt sagen ?

Gruß Klaus

PS: Zu mkgmap und Splitter gibt es eine Mailingliste. Kennst du die ?

Ich weiß nicht ob das an max-node liegt.

Ich selbst hatte mit mkgmap 2383 und 2179 den kommischen effekt das er mir nur ein Teil den vom splitter erzeugten auschnitte in IMG’s umgesetzt hatt.

Bin wieder zurück auf version 2038 da wurden alle Auschnitte wieder ordentlich zu IMG konvertiert …

Sorry mit den Mailinslisten: Da ward ich lieber bis es wieder wech ist (wird wohl noch andere geben) und bleibt solange bei der 2038.

  1. auf “http://www.mkgmap.org.uk/page/tile-splitter” steht unter max-nodes: the default (=1600000) is fairly conservative". wenn mein Verdacht stimmt, liegt das default eher an der Grenze.
  2. Man könnte in mkgmap eine Fehlermeldung einbauen. Vielleicht ist es auch einem mkgmap Programmierer möglich, die Grenze hinauszuschieben.
  3. Vielleicht bin auch ich auf dem Holzweg und jemand weist mich auf meinen Fehler hin.

Nein. Wo finde ich die, was soll der Inhalt solcher Mails sein, an wen gehen die Mails, was geschieht dann damit?

Was für ein Verdacht?
Dein Style bestimmt welche und damit auch wieviel Daten mkgmap in die kompilierten Maps (.img) übernimmt. Bei den kompilierten Maps gibt es bestimmte Maximalgrößen für Daten. Dies ist kein einfacher Parameter sondern setzt sich aus mehreren Regeln zusammen. Wenn Dein Style jetzt sehr viele Daten benutzt, dann kann es auch bei max-nodes=1600000 zu Problemen kommen. Ich habe Dein Beispiel nachgestellt und bei mir wurde mit dem Default-Style von mkgmap nur ein Tile bei max-nodes=3000000 nicht erstellt. Von daher denke ich ist die Aussage “fairly conservative” nicht so falsch.

Bei mir kommt eine Fehlermeldung auf Standard-Error:
Overflow of the NET1. The tile (germany\20121122\tiles\63240011.osm.pbf) must be split so that there are fewer roads in it

Die Tile-Größe kann nicht so einfach verändert werden. Wenn es überhaupt geht, müssten wir mkgmap-Developer noch genaueren Einblick in das Garmin-Format haben. Und den haben wir nicht…

Nee, Du suchst nur ein Problem, wo es keines gibt. Es gibt eine maximale Datenmenge und abhängig von Deinem Style kannst Du daher auch nur eine begrenzte Anzahl --max-nodes verwenden.

http://www.mkgmap.org.uk/maillist

WanMil

@Wanmil: Danke, hab wieder was gelernt. ( Also aus dem Style File unnötigen Kleinkram herauswerfen). Ich bin ja hier recht neu dabei. Es ist schon interessant, was so eine Community heute zustande bringt. (Ich hab mein erstes Progrämmchen vor 50 Jahren auf einer Zuse Z-22 geschrieben, da ging sowas nicht)

You’re welcome!

Style Files zu bereinigen ist natürlich keine schlechte Idee. Allerdings hört sich das für mich so an, als wenn Du unbedingt einen großen --max-nodes Wert erreichen möchtest. Kannst Du erklären warum?
Normalerweise sollte es kein Problem sein, wenn ein paar mehr Tiles erzeugt werden, da der --max-nodes Wert nicht das absolute Maximum erreicht.

WanMil

Eigentlich eine Spielerei. Aber ich lerne ein Programm auch dadurch kennen, daß ich versuche, an seine Grenzen zu gehen. So verstehe ich jetzt, warum manchmal einzelne Teile einer Karte nicht oder nur unvollständig dargestellt worden sind ohne daß (unter Windows) irgendeine Fehlermeldung oder Warnung auf eine Grenze hinweist.
Aber noch eine Frage:

Das klingt nach einem anderen Betriebssystem als Windows. Kann man unter Windows solche Fehlermeldungen auch anzeigen? Wenn nicht, wäre es gut, wenn die mkgmap Entwickler nach Abfrage des Betriebssystems stderr auf die Windows Ausgabe umleiten könnten.

Ich würde sagen, 1.6 Mio ist hart an der Grenze. Die meisten Kartenbauer nutzen weit kleinere Werte.

Wie WanMil schon sagte, hängt es primär davon ab, was man so für einen Style nutzt. Wenn du die eine eigene CityNavigator-Karte machst und dabei recht viel landuse und einiges von den POI weg schmeißt, dann kannst du einen höheren max-nodes nutzen als wenn du eine recht bunte Karte mit vielen POI erstellst.

Wenn man die Schnitte über mehrere Monate beibehalten will, sollte man auch eher einen kleineren Wert setzen, damit genug Spielraum nach oben ist.

stderr gibt’s auf allen Betriebssystemen. Wenn Du mkgmap von der DOS shell startest, wird es direkt dort ausgegeben.

Falls Du immer noch keine Fehlermeldung findest, kannst Du in Deinem Batchfile die Ausgaben von mkgmap in ein Logfile umleiten:


java -ea -Xmx3000m -jar q:\prog_2384\mkgmap.jar --preserve-element-order --remove-short-arcs    --precomp-sea=q:\sea\ --gmapsupp --draw-priority=25 --route --style-file=q:\stile\meinStil --family-id=%3 --family-name=Karte --mapname=%3  --description=%2 q:\erg1\*.osm.pbf q:\stile\meinTyp%3.TYP >mkgmap.log 2>&1

Wenn Du im mkgmap.log nach Ausführung immer noch keine Fehlermeldung findest, dann mußt Du einmal Deinen kompletten Style posten oder irgendwo zum Download uploaden. Ansonsten kann man Dein Problem nicht 100%ig nachstellen.

WanMil

Zu den Fehlermeldungen: Ich habe einen Test von gestern wiederholt und jetzt finde ich (auch ohne Umleitung) die Fehlermeldungen. Entweder ist mein laptop heute besser aufgelegt wie gestern, oder ich habe gestern unter windows die Teile Ausgaben zu interessiert verfolgt und dabei die Fehlermeldungen der Dos Shell übersehen. Ich versuche, mich zu bessern.

Jip, je nach Land muss ich auf 600.000 runter… Mein Style ist aber auch sehr detailliert…
Frankreich braucht beim splitter 202 allerdigns noch 2.600.000 Nodes, damit die GPS Devices nicht crashen… Mit dem neuen Splitter, ist es besser - aber die problem branch ist noch nicht wirklich stable im Vergleich zu 202. Auch braucht mkgmap für die Splits von 249 etwa deutlich mehr Memory…

Der mkgmap output in Dos klappt problemlos (wobei zig Warnungen zu Infos degradiert werden sollten - das ist aber unter Linux nicht besser).