Gelöst&Howto: osmconvert "verliert" ways beim schneiden von srtm-daten

Muss aber recht viele nodes haben, der Weg :wink:
Mit einem perl-script generierten osm trat ein Fehler auf bei mehr als einhunderttausend nodes pro weg.

EDIT:
Mmh, wie
http://trac.navit-project.org/ticket/234#comment:2
zeigt, scheint es doch ways zu geben, die in die Zehntausende (Hunderttausende?) gehen.

Ihr habt Recht! Danke für die Geduld. Es gibt tatsächlich eine Obergrenze für die Anzahl der noderefs: 100.000.

Ich hätte nie gedacht, dass es Wege gibt, die mehr Knoten haben. Hatte das sogar beim Planet getestet und war mir dann sicher, dass es keine Probleme gibt. Das Dumme nur: Die Warnung, die das Programm beim Überschreiten hätte ausgeben sollen, wurde nicht ausgegeben, weil ich statt “>=” einfach nur “>” geschrieben hatte. Sorry.

Die Konstante für die maximale Anzahl steht bei 0.5P in Zeile 8255: oo__refM
Die Warnung, die nicht kommt, steht in Zeile 8993: WARNv(“way %“PRIi64” has too many noderefs.”,id)

Ich werd die Sache weiter untersuchen und den Code anpassen.

Euch beiden danke für die Mithilfe!

Markus

Sooo, Version 0.5Q ist oben.
Das Maximum hab ich mal auf 400.000 erhöht. Gebraucht wird das aber bei normalen OSM-Daten nicht. Die neue, erweiterte Statistik zeigt:

$ time ./osmconvert planet-111012.osm.pbf --out-statistics
timestamp min: 2005-05-01T14:56:35Z
timestamp max: 2011-10-12T00:11:00Z
lon min: -180.0000000
lon max: 180.0000000
lat min: -90.0000000
lat max: 90.0000000
nodes: 1228438199
ways: 110885901
relations: 1129925
node id min: 1
node id max: 1463272201
way id min: 35
way id max: 132984869
relation id min: 11
relation id max: 1786401
keyval pairs max: 337
noderefs max: 2000
relrefs max: 7865

real 10m33.786s
user 6m54.680s
sys 0m8.980s

(Nicht wundern, hatte kein aktuelles Planet-File zur Hand und hab deswegen das vom Oktober 2011 genommen.)

@laufkaefer:
Probier bitte mal, ob dir die 400.000 für dein Shape-File reichen. Falls sie nicht reichen, gibt osmconvert jetzt eine entsprechende Fehlermeldung aus. Du kannst in diesem Fall die Konstante oo__refM auf eine Million erhöhen und die Statistik noch einmal starten. Vielleicht kommen wir so langsam auf die benötigte Anzahl an Noderefs.

ha, sehr schön.

ich habe grad bei noch einem test (der ja inzwischen nichts mehr beweist) eine kleinigkeit festgestellt: wenn ich ein osm file schneide und das osm ist in irgendeiner (oder allen) richtungen kleiner als das poly, dann verwendet osmconvert die min/max-werte aus dem poly für , die dann natürlich zu klein/groß sind. der mkgmap splitter läuft an der stelle gegen die wand. womit er aber klarkommt, ist gar kein - dann sucht er sich die min/max-werte nämlich selber. ich hab mich grad damit beholfen, einfach per hand zu löschen, besser wäre natürlich, die korrekten werte entweder direkt aus den osm-daten zu holen oder zumindest eine option in der art --omit-bounds-tag zu haben, die das tag unterdrückt.

micha

0.5Q stürzt ab unter windows, wenn ich --out-statistics verwende. ich teste das morgen mal unter linux.

micha

Habs grad selber gemerkt. :frowning: Beim Übersetzen für Windows gibts Probleme mit dem riesigen noderef-Feld. Ich werd den Speicher auf eine andere Art anfordern müssen, dazu muss ich das Programm aber ein bisschen umbauen. Für die Zwischenzeit hab ich die Version 0.5R hochgeladen, die zwar noch die erweiterte Statistik drin hat, aber die Anzahl der noderefs wieder auf 100.000 beschränkt. Wenn du unter Linux Experimente machst, kannst du diese Anzahl ja selber erhöhen, das sollte klappen.

Version 0.5T:

Es gibt ab sofort die Option “–max-refs=”, mit der man die maximale Anzahl der Objekt-Referenzen einstellen kann. Klappt auch mit der Windows-Version. Beispiel:

--max-refs=800000

Klappt nicht mit der Linux-Version :frowning:

Zuminderst versteh’s ich nicht:
Nehmen wir als Beispiel “mein”
Lat49Lon11Lat50Lon12.osm
Hat
noderefs max: 21385

Da denk ich doch, 80000 (achtzig-tsd) müsste genügen, statt der 800000 (achthunderttsd).
Tut’s aber nicht, zuminderst nicht richtig:


user@host:~$ ./osmconvert Lat49Lon11Lat50Lon12.osm --out-statistics --max-refs=80000
osmconvert Warning: wrong sequence at way 1000000000
osmconvert Warning: next object is node 1000000012
osmconvert Warning: wrong sequence at way 1000000001
osmconvert Warning: next object is node 1000000024
osmconvert Warning: wrong sequence at way 1000000002
osmconvert Warning: next object is node 1000000028
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(): invalid next size (normal): 0x000000001771b800 ***
======= Backtrace: =========
/lib/libc.so.6(+0x71ad6)[0x7f7c0128dad6]
/lib/libc.so.6(cfree+0x6c)[0x7f7c0129284c]
./osmconvert[0x4053af]
/lib/libc.so.6(+0x365e2)[0x7f7c012525e2]
/lib/libc.so.6(+0x36635)[0x7f7c01252635]
/lib/libc.so.6(__libc_start_main+0x104)[0x7f7c0123ac54]
./osmconvert[0x401689]
======= Memory map: ========
00400000-0042b000 r-xp 00000000 fe:01 5668911                            /home/user/osmconvert
0062a000-0062c000 rw-p 0002a000 fe:01 5668911                            /home/user/osmconvert
0062c000-15e20000 rw-p 00000000 00:00 0 
17702000-17750000 rw-p 00000000 00:00 0                                  [heap]
7f7bfc000000-7f7bfc021000 rw-p 00000000 00:00 0 
7f7bfc021000-7f7c00000000 ---p 00000000 00:00 0 
7f7c01006000-7f7c0101c000 r-xp 00000000 fe:01 11706371                   /lib/libgcc_s.so.1
7f7c0101c000-7f7c0121b000 ---p 00016000 fe:01 11706371                   /lib/libgcc_s.so.1
7f7c0121b000-7f7c0121c000 rw-p 00015000 fe:01 11706371                   /lib/libgcc_s.so.1
7f7c0121c000-7f7c01374000 r-xp 00000000 fe:01 11706379                   /lib/libc-2.11.2.so
7f7c01374000-7f7c01573000 ---p 00158000 fe:01 11706379                   /lib/libc-2.11.2.so
7f7c01573000-7f7c01577000 r--p 00157000 fe:01 11706379                   /lib/libc-2.11.2.so
7f7c01577000-7f7c01578000 rw-p 0015b000 fe:01 11706379                   /lib/libc-2.11.2.so
7f7c01578000-7f7c0157d000 rw-p 00000000 00:00 0 
7f7c0157d000-7f7c01594000 r-xp 00000000 fe:01 13199548                   /usr/lib/libz.so.1.2.3.4
7f7c01594000-7f7c01793000 ---p 00017000 fe:01 13199548                   /usr/lib/libz.so.1.2.3.4
7f7c01793000-7f7c01794000 rw-p 00016000 fe:01 13199548                   /usr/lib/libz.so.1.2.3.4
7f7c01794000-7f7c017b2000 r-xp 00000000 fe:01 11706391                   /lib/ld-2.11.2.so
7f7c018ec000-7f7c0198c000 rw-p 00000000 00:00 0 
7f7c019ad000-7f7c019ae000 rw-p 00000000 00:00 0 
7f7c019af000-7f7c019b1000 rw-p 00000000 00:00 0 
7f7c019b1000-7f7c019b2000 r--p 0001d000 fe:01 11706391                   /lib/ld-2.11.2.so
7f7c019b2000-7f7c019b3000 rw-p 0001e000 fe:01 11706391                   /lib/ld-2.11.2.so
7f7c019b3000-7f7c019b4000 rw-p 00000000 00:00 0 
7fffcc65b000-7fffcc67f000 rw-p 00000000 00:00 0                          [stack]
7fffcc76a000-7fffcc76b000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Abgebrochen
user@host:~$

Das heißt, das Programm stürzt beim Schreiben der Statistik ab…?

Sorgen bereitet mir vor allem das hier:

Demnach ist die Eingangsdatei unsortiert und kann von osmconvert sowieso nicht geschnitten werden.

die linux-fehlermeldung muss ich leider bestätigen.

das unsortierte beschränkt sich auf diese 6 zeilen, egel wir groß die ausgangsdaten sind.

ansonsten noch ein paar test und fakten:

  • alle nodes bleiben erhalten (stichpunktartig mit texteditor kontrolliert, --out-statistics bestätigt das, auch node-id-min/max sind identisch)

  • out-statistics liefert nur 3 wege mit “too many refs”, es sind definitiv mehr

  • ca. 98.000 wege sind verloren worden (das hatte ich gestern noch anders, allerdings liefert srtm2osm osm 0.5, heute habe ich mit 0.6 gearbeitet - im 0.6er strang kompilierte garmin files sind jedoch auf’s byte identisch mit per 0.5 generierten - hat --out-statistics event. ein problem mit 0.5?), way-id-min/max sind jedoch identisch

  • die verlorenen wege sind komplett weg (gestern sah es noch so aus, als wäre der weg an sich da und nur die noderefs fehlen, beim heutigen test fehlte sowohl das way-tag und damit natürlich die noderefs)

ich werde die ausgangsdaten jetzt mal per osmosis sortieren, mal sehen, was das bringt

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 :wink:

$ /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. :slight_smile: Danke für eure Geduld!

Version 0.5U ist oben.

Natürlich löst das nicht das Problem mit der unsortierten Datei. :frowning:

Vielen Dank für die neue Version! Funktionokelt :slight_smile:

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.