Zum Perl-Skript (mit ungeplantem Betatest):
An den 8-stelligen IDs liegt es nicht - vielmehr werden String und keine Ganzzahlen sortiert.
Ich werde dies, zusammen mit dem Defekt der leeren Dateien, in Kürze mal korrigieren.
Wahrscheinlich sind die Daten für den Hill-Layer mit Srtm2Osm erzeugt worden ohne x/y Korrektur. Srtm2Osm hat einen 50m Versatz. Irgendwo hier im Forum gab es mal in einem Thread ein paar Koordinaten, wo man die Abweichung sehr schön sehen konnte. Die phyghtmap Daten sind eigentlich ziemlich genau. Es gibt Leute, die behaupten die viewfinderpath Daten hätten 12m Versatz, aber ich habe noch kein Beispiel gesehen.
Leider nein… bin mir nicht sicher ob dash richtig funktioniert. Ja osmconvert zeigt keine Fehler mehr an. Splitter läuft auch ohne Probleme durch. Aber mkgmap verweigert mal wieder den Dienst (egal ob ich jetzt die gesplitteten Daten oder die von osmconvert rausgegebenen Daten, oder die Daten die nur durch das Skript gelaufen sind nehme):
openSUSE-121-64-minimal:/home/contourlines # java -ea -jar -Xmx6000M mkgmap.jar --max-jobs=1 --reduce-point-density=5.4 --transparent --overview-mapname=mapset00 --keep-going --gmapsupp kaputt.osm.pbf
Error at line 1, col 1
Bad file format: kaputt.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:413)
at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:112)
BTW wenn ich die Alpendaten von 1.23 mit kukuk’s patches für osmconvert nach dem dash merge_osm.sh verwende, dann läuft osmconvert nicht korrekt durch, sondern gibt folgende Fehlermeldung:
./osmconvert topo.osm -o=alps_user.osm.pbf
osmconvert Error: way 140118426 has too many refs.
osmconvert Error: way 140297241 has too many refs.
osmconvert Error: way 140519102 has too many refs.
kommt daher, das phyghtmap mit den letzten Änderungen nur noch mit matplotlib < 1.0.0 funktioniert. Debian benutzt noch immer 0.98 in stable, daher funktionert es dort, während openSUSE schon lange 1.0.1 bzw. 1.1.0 verwendet.
Kann jemand mir eine einzelne Kachel mit phyghtmap 1.24 oder 1.25 und matplotlib < 1.0.0 zukommen lassen, sowie die verwendete Kommandozeile? Und bitte von einem ungepatchten phyghtmap. Dann kann ich das mal bei mir Vergleichen.
Das gleiche habe ich, wenn ich die SRTM Daten mit osmosis 0.40.1 ausschneide. Wenn ich osmosis 0.39 verwende, funktioniert es. Gab es da Änderungen in osmpbf? Jedes Javatool kommt ja leider mit seiner eigenen Kopie
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
$