Ich mache aus den Ergebnisse danach mit mkgmap Garmin-Images, wobei ich interessanterweise nichts Fehlendes bemerke.
Das irritiert mich ja so. Ich mache jede Nacht kumulative Updates mit osmconvert und befürchte, irgendwelche Daten zu verlieren, wenn ich nicht 0.8.8p verwende. Andererseits bläst sich der Datensatz immer mehr auf. Außerdem hätte ich gerne eine funktionierende neuere Version als 0.8.8.
BTW: Bist Du der Gerd aus der Mkgmap-Development-Mailliste?
Ich würde Dir die Dateien gerne zur Verfügung stellen, habe aber nur eine 2Mbit-Leitung mit ~400kbit Upload, das dauert eine Ewigkeit.
Alternativ kannst Du das Kompilat aus dem älteren Post verwenden (http://www.muenchen-surf.de/rohyman/osmconvert/osmconvert64_lfs.exe), welches exakt die gleichen Ergebnisse liefert, wie mein eigenes Kompilat oder ich schicke Dir mein Kompilat (libz statisch gelinkt, ~613k) direkt zu?
Danke für den Test und danke, daß Du mir den Quellcode der Version 0.8.8 geschickt hast.
Ich habe eine osmconvert 0.8.8 mit meinem Rezept gebaut und nun schau Dir das Ergebnis an:
Also exakt die gleichen Ergebnisse wie Version 0.8.8p!
Dann scheint die Änderung der Ergebnisse an den Änderungen des Quelltextes von osmconvert von Version 0.8.8 zu Version 0.8.11 liegen und nicht an der Art der Kompilation!
Also ich stelle mein Executable gerne zur Verfügung!
Ich finde übrigens nur eine Stelle im Quelltest, die einen so gravierenden Unterschied im Ergebnis produzieren könnte: Bei der Initialisierung der Hashtabelle wird in Version 0.8.11 doppelt soviel Speicher zugewiesen wie in Version 0.8.8. Dazu der Hinweis vom Author:
Jup, daran liegt es!
Wenn ich die Verion 0.8.8p mit --hash-memory=3000 zusätzlich starte, bekomme ich die gleichen Ergebnisse wie mit meinem Kompilat ohne die Hash-Größe anzugeben:
Ich hoffe, damit sind die größten Geheimnisse gelöst.
Bedeutet im Gegenzug auch: Man kann die 0.8.8p von der Wiki-Seite weiterhin verwenden, man muß nur zusätzlich (Z. B. mit --hash-memory=3000) den Hash-Speicher vergrößern, dann sind keine überflüssigen Relationen mehr im Ergebnis.
Wenn das dortige Repository inzwischen eher inaktiv ist, würde dann ein Klonen des Projekts auf gitlab oder auf github sinnvoll sein, wo man dann vielleicht die neuere Dokumentation und die anstehenden Änderungen am Quellcode von osmconvert gebündelt darstellen und bearbeiten kann?
Also für eine Vergrößerung der Hashcode-Table halte ich mich schon für fähig, auch wenn dazu vermutlich komplett auf 64-bit-Indizes (eventuell auch auf 64-bit-Hashcodes) umgestiegen werden muß. Allerdings ist der Quellcode - sagen wir mal - “historisch” gewachsen, mit entsprechendem Wildwuchs - leider. Das kann man dem Autor aber nicht vorwerfen, da er es hauptsächlich für seinen Eigenbedarf entwickelt hat und es wohl eher zufällig in der Öffentlichkeit gelandet ist. Nichtsdestotrotz ist es ein handliches Tool, auf das ich nicht mehr verzichten möchte.
Übrigens: Die Änderung von 10241024 zu 1024u1024u führt nur zu einer Verdoppelung der maximal möglichen Hashcodegröße von 2^31-1 zu 2^32-1. Funktioniert auch ohne die Änderung, da das Vorzeichen bei Typkonvertierungen in C einfach ignoriert wird → Integer overflow.
Man kann wohl langsam aber sicher auf einen Support on 32-bit Systemen verzichten, falls das ein Hindernis ist. Man könnte aber evtl. auch short* oder int* anstelle von char* verwenden, um die Elemente um Hash zu adressieren?