Und was passiert wenn du sie gar nicht schneidest? Weil bei mir gehts ja auch nicht wenn ich einfach die 17GB Rohdaten als Einzeldatei versuche per splitter>mkgmap zu benutzen. Osmosis läuft sowieso nicht bei mir (bekomme nur Version 0.29 noch zum laufen).
Evtl liegts bei mir ja auch daran, dass ich NICHT osmosis 0.39 benutze. Weil mkgmap splitter gibt die Daten ja auch als pbf aus, und schreibt evtl denselben Fehler wie neue Osmosis Versionen…
Nett wäre übrigens ein vollständig gepatchtes phyghtmap – die patches bekomme ich zumindest nicht automatisch gemerged, und händisch ist nicht wirklich ein Spaß…
Werde mal versuchen matplotlib 0.98 unter opensuse zu installieren.
Meine Patches werde ich mergen sobald ich das points=0 Problem final gelöst habe. Solange würde ich mit der phyghtmap 1.23 + patches weiterarbeiten, ich sehe in 1.24 und neuer noch keinen Vorteil.
da muss noch ein Fehler sein, der bei mir nicht auftritt.
Die Bounding Box bilde ich so ab, wie sie von Osmosis (dort aber meist mehr Nachkommastellen mit 0 aufgefüllt) erzeugt wird, z.B:
Beim “Extrahieren” der Koordinaten aus den Dateinamen läuft wohl was falsch. Wie lautet denn die (fast letzte) Bildschirmausgabe in Zeile “Bereich: …”?
Der Fehler liegt beim Extrahieren aus den Dateinamen. Die IDs stehen ja auch noch so dabei wie in der erstellten Tabelle. Keine Ahnung wie ich den Fehler reproduzieren kann, wenn es bei mir funktioniert. Der Umgang mit den Zeichenketten ist ja nicht von den Kachelgrenzen, also vom Gebiet, abhängig. (Nächster Fallstrick dann aber vielleicht bei negativen Koordinaten).
Kenn mich ja mit dem Garmin-Zeugs nicht aus.
Wenn ich das nehme
$ java -ea -jar ./mkgmap-gmap-mdr-r2161.jar --max-jobs=1 --reduce-point-density=5.4 --transparent --overview-mapname=mapset00 --keep-going --gmapsupp nixkaputt.osm.pbf
Error at line 1, col 1
Bad file format: nixkaputt.osm.pbf
Error parsing file
Exception in thread "main" java.lang.NullPointerException
at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:406)
at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:112)
$ echo $?
1
$
Sehe ich das Richtig - mit mkgmap Version 2161 gehts, aber nicht mit aktueller mkgmap Version? Das wäre für mich schon okay, kannst du die Version rausfinden ab der es nicht mehr geht? Dann könnte man den Fehler besser suchen. Ich werde wohl auch noch mal mit alten Versionen spielen, wenn das bei dir den Ausschlag gegeben hat. Hätte mal gedacht jeder hier arbeitet mit der aktuellsten Version (svn) von je splitter und mkgmap.
Dann ist doch alles Ok, mkgmap-gmap-mdr-r2161.jar ist obsoleted durch mkgmap-r2166 und der Bug ist inzwischen gefixt. Lösch einfach Dein r2161, Du brauchst es nicht mehr.
GRRRRRRRRRRR - ich hab meinen Fehler gefunden. osmprotobuf.jar war bei mir am Server irgendwie kaputtgegangen, bzw hat lokal gefehlt. Sprich alle Fehlermeldungen mit der “1” waren Fehler beim lesen der pbf Dateien wegen osmprotobuf missing/kaputt. Dein Beitrag hat mich drauf gebracht. Sorry für die Confusion… (hat sich nur auf Fehler der letzten Versionen der Skripte bezogen, weil vorher hat ja auch das bearbeiten von direkt als .osm gesplitteten Dateien nicht funktioniert)
Was sagt eigentlich diese Fehlermeldung von osmconvert aus?
openSUSE-121-64-minimal:/home/contourlines # ./osmconvert phyghtmap_result.osm -B=/home/contourlines/bounds/austria.poly -o=austria.osm.pbf
osmconvert Error: way 99729759 has too many refs.
osmconvert Error: way 99935004 has too many refs.
osmconvert Error: way 100140144 has too many refs.
Das hatten wir hier schon. Und außerdem ist das Open Source
osmonvert.c:
has too many refs
=> if(refide>=refidee)
=> int64_t* refidee; // end address of array
=> refidee= refid+global_maxrefs;
=> static int64_t global_maxrefs= 100000;
=> Wenn ein Weg mehr als 100000 Knoten hat, gibt’s Knatsch.
Etwas verwunderlich ist auch Deine “–max-nodes”-Sizing,
zuerst hast Du “250” und jetzt “100000000000”
Ups danke, hab ganz vergessen das anzupassen nachdem ich wieder zu Version 1.23 zurück bin (doch blöd wenn ein Command je nach Version/patch zwei Bedeutungen hat…)
