Das liegt nicht (nur) an der unsortierten SRTM-Datei,
die Speicherverwaltung ist nicht i. O.:
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?
Jede Warnung oder Fehlermeldung wird je Meldungstyp nur maximal dreimal ausgegeben (Flood-Protection).
Das muss also nichts heißen. Fehler ist Fehler…
Zur Speicherverwaltung:
Kommt die Meldung “corrupted unsorted chunks” nur unter Windows? Ich hab sie noch nie erhalten.
ich krieg auch noch ne andere fehlermeldung (nur linux):
*** glibc detected *** /home/micha/srtm/osmconvert32: double free or corruption (out): 0xd2b70008 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xf7632bc2]
/lib/i386-linux-gnu/libc.so.6(+0x6f862)[0xf7633862]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xf763694d]
/home/micha/srtm/osmconvert32[0x805b18f]
/lib/i386-linux-gnu/libc.so.6(+0x32981)[0xf75f6981]
======= Memory map: ========
08048000-0806c000 r-xp 00000000 07:00 7022 /home/micha/srtm/osmconvert32
0806c000-0806d000 r–p 00023000 07:00 7022 /home/micha/srtm/osmconvert32
0806d000-0806f000 rw-p 00024000 07:00 7022 /home/micha/srtm/osmconvert32
0806f000-157d4000 rw-p 00000000 00:00 0
15c3f000-15c60000 rw-p 00000000 00:00 0 [heap]
d2b70000-ec6c1000 rw-p 00000000 00:00 0
f7400000-f7421000 rw-p 00000000 00:00 0
f7421000-f7500000 —p 00000000 00:00 0
f75a4000-f75c0000 r-xp 00000000 07:00 9340 /lib/i386-linux-gnu/libgcc_s.so.1
f75c0000-f75c1000 r–p 0001b000 07:00 9340 /lib/i386-linux-gnu/libgcc_s.so.1
f75c1000-f75c2000 rw-p 0001c000 07:00 9340 /lib/i386-linux-gnu/libgcc_s.so.1
f75c2000-f75c4000 rw-p 00000000 00:00 0
f75c4000-f773a000 r-xp 00000000 07:00 9344 /lib/i386-linux-gnu/libc-2.13.so
f773a000-f773c000 r–p 00176000 07:00 9344 /lib/i386-linux-gnu/libc-2.13.so
f773c000-f773d000 rw-p 00178000 07:00 9344 /lib/i386-linux-gnu/libc-2.13.so
f773d000-f7740000 rw-p 00000000 00:00 0
f7740000-f7753000 r-xp 00000000 07:00 9387 /lib/i386-linux-gnu/libz.so.1.2.3.4
f7753000-f7754000 r–p 00012000 07:00 9387 /lib/i386-linux-gnu/libz.so.1.2.3.4
f7754000-f7755000 rw-p 00013000 07:00 9387 /lib/i386-linux-gnu/libz.so.1.2.3.4
f7764000-f7766000 rw-p 00000000 00:00 0
f7766000-f7767000 r-xp 00000000 00:00 0 [vdso]
f7767000-f7785000 r-xp 00000000 07:00 9341 /lib/i386-linux-gnu/ld-2.13.so
f7785000-f7786000 r–p 0001d000 07:00 9341 /lib/i386-linux-gnu/ld-2.13.so
f7786000-f7787000 rw-p 0001e000 07:00 9341 /lib/i386-linux-gnu/ld-2.13.so
ff983000-ff9a4000 rw-p 00000000 00:00 0 [stack]
Aborted
Bei mir geht:
$ osmconvert Lat49Lon11Lat50Lon12.osm --fake-version > a.osm
$ osmconvert a.osm --fake-author > b.osm
$ osmosis-0.39/bin/osmosis --read-xml b.osm --s --wx c.osm
$ ./osmconvert c.osm --out-statistics
timestamp min: 1970-01-01T00:00:01Z
timestamp max: 1970-01-01T00:00:01Z
lon min: 11.0004166
lon max: 12.0004166
lat min: 49.0004166
lat max: 50.0004166
nodes: 309576
ways: 5839
relations: 0
node id min: 1000000000
node id max: 1000309575
way id min: 1000000000
way id max: 1000005838
keyval pairs max: 3
noderefs max: 21385
*** glibc detected *** ./osmconvert: free(): corrupted unsorted chunks: 0x0000000017110120 ***
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:
nemiver ./osmconvert ........(parameter)........
Benutze nur Linux 
$ /osmconvert c.osm --out-statistics --max-refs=8
*** glibc detected *** ./osmconvert: free(): invalid next size (fast): 0x0000000016e26fd0 ***
$ ./osmconvert c.osm --out-statistics --max-refs=80
*** glibc detected *** ./osmconvert: free(): corrupted unsorted chunks: 0x0000000017419120 ***
$ ./osmconvert c.osm --out-statistics --max-refs=8000
Speicherzugriffsfehler
$ ./osmconvert c.osm --out-statistics --max-refs=80000
*** glibc detected *** ./osmconvert: free(): corrupted unsorted chunks: 0x0000000017cdf120 ***
$ ./osmconvert c.osm --out-statistics --max-refs=800000
timestamp min: 1970-01-01T00:00:01Z
timestamp max: 1970-01-01T00:00:01Z
lon min: 11.0004166
lon max: 12.0004166
lat min: 49.0004166
lat max: 50.0004166
nodes: 309576
ways: 5839
relations: 0
node id min: 1000000000
node id max: 1000309575
way id min: 1000000000
way id max: 1000005838
keyval pairs max: 3
noderefs max: 21385
$ echo $?
0
$
$ gdb ./osmconvertd
(gdb) run c.osm --out-statistics --max-refs=80
Starting program: /home/user/osmconvertd c.osm --out-statistics --max-refs=80
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. 
Vielen Dank für die neue Version! Funktionokelt 
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.
Mmmh, dann haette mein unsortiertes Nürnberg (von gestern, post#18, osmconvert 0.5P) gar nicht funktionieren dürfen.
Tatsächlich ist der Unterschied zum heutigen, osmconvert 0.5U, aus durch osmosis sortiertem Frankenland
ausgeschnittenem Nürnberg eher gering [1]:
Vielleicht kann micha die “Sortiererei durch osmosis” - bei genügend großem “–max-refs=” - weglassen.
Bin gespannt
[1] Zum besseren Vergleichen ersteres “nachsortiert”
es scheint vorwärts zu gehen
oberste karte: die, mit der der thread startete
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.
Supi
Was sagt “–out-statistics”?
Bist Du schon per
noderefs max: 800000
“am Anschlag”?
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.
ach so, nächste tests:
-
noch mehr max-ref
-
größerer overlap
-
beides zusammen
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.
Könntest Du trotzdem mal “–out-statistics” drüber laufen lassen.
Mich würde interessieren, wo jetzt die
noderefs max:
liegen.
Danke.
Vielleicht bei 102000, das könnte Markus noch als Default hinnehmen
Dann bräuchten wir nur jemanden, der den “SRTM-planet” hat
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.