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.
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.
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.
Habs grad selber gemerkt. 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.
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:
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
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.