ja, die eingangsdatei ist komplett unsortiert. der mkgmap splitter hat eine option (–mixed), um mit unsortierten daten zu arbeiten, aber die batch, wo das mit drinsteht, hab ich schon seit ewigkeiten nicht mehr offen gehabt - deswegen war mir’s entfleucht.
osmosis schmiert mit beim sortieren der großen datei überigens ab, aml sehen, ob ich das noch hinkriege. oder gibt’s noch ein anderes tool zum sortieren?
Hat einer von euch beiden eine Datei für mich, mit der ich die Fehlersituation nachstellen könnte?
Oder, falls ihr wollt: unter Linux mit der Option -g übersetzen und schauen, wo der Programm aus der Kurve fliegt. Eventuell mit dem grafischen Debugger Nemiver:
Program received signal SIGABRT, Aborted.
0x00007ffff7899165 in *__GI_raise (sig=) at …/nptl/sysdeps/unix/sysv/linux/raise.c:64
64 …/nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden.
in …/nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt #0 0x00007ffff7899165 in *__GI_raise (sig=) at …/nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff789bf70 in *__GI_abort () at abort.c:92 #2 0x00007ffff78cf27b in __libc_message (do_abort=, fmt=)
at …/sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff78d8ad6 in malloc_printerr (action=3, str=0x7ffff798faf0 “free(): corrupted unsorted chunks”, ptr=)
at malloc.c:6267 #4 0x00007ffff78dd84c in *__GI___libc_free (mem=) at malloc.c:3739 #5 0x00007ffff7bd2492 in inflateEnd (strm=0x15e1d010) at inflate.c:1247 #6 0x00007ffff7bcb218 in destroy (s=0x15e1d010) at gzio.c:401 #7 0x00000000004038c4 in read_close () at osmconvert.c:1599 #8 0x0000000000414455 in oo__closeall () at osmconvert.c:8084 #9 0x000000000041452e in oo__end () at osmconvert.c:8112 #10 0x00007ffff789d5e2 in __run_exit_handlers (status=0, listp=0x7ffff7bc24a8, run_list_atexit=true) at exit.c:78 #11 0x00007ffff789d635 in *__GI_exit (status=3344) at exit.c:100 #12 0x00007ffff7885c54 in __libc_start_main (main=, argc=, ubp_av=,
init=, fini=, rtld_fini=, stack_end=0x7fffffffe1d8) at libc-start.c:260 #13 0x0000000000401629 in _start ()
(gdb)
Erwischt!
In Zeile 8343 wird für das Feld ‘refrole’ nur ein viertel des Platzes angefordert, der benötigt wird (bei 64-Bit-Rechnern nur ein achtel). Wenn man also “–max-refs=” hoch genug schraubt, klappt alles ohne Fehler. Aber das ist ja nicht Sinn der Sache. Danke für eure Geduld!
Version 0.5U ist oben.
Natürlich löst das nicht das Problem mit der unsortierten Datei.
Wie in post #35 geschrieben, gehts mit Hilfe von osmosis; sogar in 2 steps:
osmconvert Lat49Lon11Lat50Lon12.osm --fake-version > a.osm
osmosis-0.39/bin/osmosis --read-xml a.osm enableDateParsing=no --s --wx b.osm
Große Dateien hab’ ich mangels Daten nicht getestet.
mittlere: eben gemacht mit 0.5U und max-ref=800000
untere: ohne osmconvert erzeugt
fehlende linien auf den ersten blick nur noch an der nordkante, viell. lässt sich das durch noch mehr maxrefs verbessern, oder aber ich muss mit mehr overlap schneiden (momentan werden am nordende einfach 0,5 grad entfernt, eigentlich, weil srtm2osm an den kanten viele artefakte produziert, die ich wegschneiden will, am ende kann ich hier 2 fliegen mit einer klappe schlagen.
die sortierung der daten hat mit an sicherheit grenzender wahrscheinlichkeit keinen einfluss auf’s ergebnis. da ich mit osmosis nicht sortieren kann, habe ich mal einen umweg genommen:
die srtm2osm-daten sind schon nach id sortiert, nicht aber nach type (nodes und ways durcheinander). ich habe mit osmconvert und --drop-nodes bzw. --drop-ways mal nodes und ways in 2 dateien separiert, diese dateien per kommandozeile (mit copy) zusammengefügt und per text-editor an der “klebestelle” das schließende/öffende entfernt, um wieder gültiges xml herzustellen.
dann habe ich über die so sortierte gesamtdatei mal den ganzen prozess drüberlaufen lassen und auf’s byte genau dieselben ergebnisse erhalten wie bei unsortierten ausgangsdaten.
noderef-max bei 2.000.000 bringt keinen unterschied im vergleich zu 800.000 - hatte ich ehrlich gesagt auch nicht erwartet, weil die fehlermeldungen auch bei 800.000 schon verschwunden waren
Hallo,
wundert mich, dass es mit unsortierten Daten klappt. Aber ich will mich ja nicht beschweren.
Die fehlenden Linien am Rand könnten einen anderen Grund haben: Viele Programme akzeptieren es nicht, wenn ein Way eine Noderef enthält, zu der es keinen Node in der Datei gibt (z.B. weil dieser Node knapp außerhalb des Gebiets liegt). Dafür gibts zwei mögliche Lösungswege, von denen der erste vermutlich schneller ist:
Die betreffenden Noderefs mit --drop-broken-refs entfernen.
Die betreffenden Nodes mit --complete-ways trotzdem aufnehmen.
Inwieweit diese Optionen mit unsortierten Daten klarkommen, weiß ich allerdings nicht.
sämtliche test sind mit --complete-ways durchgeführt - die funktion ist doch genau der grund, weswegen ich osmconvert verwenden will. mit osmosis krieg ich das weder unter win noch unter lin zum laufen, und ohne complete-ways gibt’s bei höhenlinien an den schnittkanten immer hunderte artefakte.
Macht es einen Unterschied ob der Weg nun 100.000 Refs hat oder zwei Wege mit 50.000 Refs existieren? Bei Höhenlinien wohl eher nicht oder? Dann kann man vielleicht auch einfacher das Programm srtm2osm anpassen oder diese Wege in OSMconvert teilen. Da sich die Höhenlinien nicht mehr verändern sollten braucht man hier auch nicht auf die Referenzen bezüglich von Updates achten.
srtm2osm.exe wird schon lange nicht mehr weiterentwickelt.
Im kern ist schon seit 3 Jahren “tot”.
Wenn, würde mensch wahrscheinlich ein komplett neues proggie entwickeln.
Eines, dass nicht so eine restriktive Lizenz hat und auch CGIAR und andere “SRTM-Derivate” beherrscht.