Welches Ergebnis stimmt denn?
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? 
Jo.
Wenn Du mit dem Vergleich der Dateien nicht weiterkommst, dann kann ich das gerne machen.
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?
Ich vergleich mal bei mir die Variante von RoHyman mit der 0.8.8p
Hast Deine Version mit dem Source Version 0.8.11 gebaut?
Jep, gebaut mit zlib 1.2.11, osmconvert 0.8.11 und GCC 9.2.0 von nuwen.
Hast Du noch die hotmail-email?
Jo
Man, gmail nervt, jetzt hat es aber wohl endlich geklappt.
Zweimal mit Paßwort eingepackt hat es nun hoffentlich funktioniert…
Ja, ist angekommen. Ich habe mal die Ausgaben für die Optionen
-b=8.39,52.8,8.5,53 --complete-ways
verglichen.
Soweit ich das sehe, sind alle Daten, die in der 0.8.8p Variante mehr drin sind, komplett überflüssig. Es scheint aber nichts zu fehlen.
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:
E:\CreateIMG>osmconvert_088.exe --drop-version "OSM-Data\germany+jordan.o5m" -o="OSM-Data\germany_.o5m" -B=germany.poly -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 49261 dependencies.
Interrelational hierarchy 2: 231 dependencies.
Interrelational hierarchy 3: 2 dependencies.
Interrelational hierarchy 4: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 3 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>osmconvert_088.exe -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 662 dependencies.
Interrelational hierarchy 2: 63 dependencies.
Interrelational hierarchy 3: 7 dependencies.
Interrelational hierarchy 4: 1 dependencies.
Interrelational hierarchy 5: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 4 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>
Hier die Dateien:
02.05.2021 15:54 9.008.195 extract.o5m
02.05.2021 15:50 5.837.020.484 germany_.o5m
02.05.2021 02:42 5.881.000.652 germany+jordan.o5m
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! 
Tja, wäre schön, wenn man auf der Wiki Seite die fehlerhafte Version durch eine neuere ersetzen würde.
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:
E:\CreateIMG>osmconvert64-0.8.8p.exe --hash-memory=3000 --drop-version "OSM-Data\germany+jordan.o5m" -o="OSM-Data\germany_.o5m" -B=germany.poly -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 13896 dependencies.
Interrelational hierarchy 2: 72 dependencies.
Interrelational hierarchy 3: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 2 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>
02.05.2021 17:04 5.003.327.237 germany_.o5m
02.05.2021 02:42 5.881.000.652 germany+jordan.o5m
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.
Ah, ich hatte gedacht, dass die Konvertierung zu unsigned den Unterschied ausmacht.
hash__max[o]= x*(1024u*1024u);
Hängt aber vielleicht vom Compiler ab.
Mit den max. 4000 für einen Datentyp ist dann wohl auch bald eine größere Änderung nötig. Viel mehr als
--hash-memory=4000-400-40
geht dann nicht.
Hmmm, habe selber zwar nicht die Kenntnisse zum Kompilieren des Quellcodes etc,
aber laut https://wiki.openstreetmap.org/wiki/Osmconvert#Source gibt es ja
den Quellcode auch auf gitlab: https://gitlab.com/osm-c-tools/osmctools
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?
Du kannst hier nachlesen, warum das eher keine gute Idee ist: https://lists.openstreetmap.org/pipermail/dev/2021-February/031084.html
Ich sehe das wie Flo, der Code ist in seiner veröffentlichten Form leider kaum bis gar nicht wartbar.
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?
Gibt es eigentlich irgendeinen mir vielleicht unbekannten Grund, warum man für sowas nicht einfach osmium tool verwendet?
Ich habe irgendwann mal versucht, ein Windows Binary zu finden und bin gescheitert.