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.
Lösung hatte ich hier mal eingereicht, wurde aber nicht übernommen, weil eigentlich niemand freiwillig mit Windows arbeiten will: https://github.com/osmcode/osmium-tool/pull/105
Ich denke mal, das mindestens die Hälfte aller mkgmap Hobby-Anwender Windows benutzen. Das o5m Format ist auch am besten als Eingabe für das zugehörige Programm splitter geeignet. Osmium kann kein o5m schreiben, oder?
Falls osmconvert tatsächlich mal nicht mehr funzt und nicht mehr gewartet würde, dann würde ich vermutlich eher ein Java replacement kodieren für die Funktionen, die man für mkgmap braucht.
Ja, Osmium kann im Moment nur lesend auf o5m zugreifen. Die Frage ist natürlich, ob sich der Aufwand für ein Schreiben überhaupt lohnt. Gibt es dazu Erfahrungswerte, wie sich o5m im Vergleich zu pbf mit dem Splitter schlägt? Ich hatte zuletzt vor vielen Jahren mit splitter gearbeitet und kann mich nicht mehr so recht an die Details erinnern.
Bei grossen Dateien lohnt es sich auf jeden Fall, erst mit osmconvert nach o5m zu wandeln, das kann einigen Minuten sparen. Weltbewegend ist der Unterschied nicht mehr. Splitter muss die Datei einige Male lesen und braucht nicht immer alles, z.B. nur die Wege oder nur die Relationen. Es gibt aber beim pbf Format keine Möglichkeit, direkt zu den Wegen zu springen. Man nudelt jedes mal ales durch und das kostet Zeit.
Splitter könnte auch beim ersten Lesen die Wege und Relationen in temp. Dateien schreiben, dann wäre das Problem gelöst, aber einfacher ist mit dem o5m Format. Da merkt man sich beim ersten Lesen den Offset, an dem es mit Ways losgeht und kann dann beim nächsten Lesen direkt dort hinspringen.
Das wäre super 
Sobald man das PBF einmal durchgenudelt hat, sollte man zumindest die Offsets der jeweiligen Blobs kennen, in denen zum ersten mal Ways oder Relationen auftauchen (Annahme: PBF ist sortiert nach Nodes, Ways, Relations). Ich kenne aber auch keine Implementierung, die diese Information bewusst berücksichtigt, um größere Teile des PBF zu überspringen.
Zufällig entdeckt: https://github.com/peermaps/random-access-osm-pbf bietet die Option, irgendwo mittendrin im PBF einzusteigen und dann ab einem passenden Synchronisationspunkt aus Daten zurückzuliefern. Ob das wirklich wie versprochen funktioniert, müsste man sich mal genauer anschauen.
splitter merkt sich die Blöcke und was drin ist und gibt in der skipBlock() Methode entsprechende Werte zurück. Das ist aber immer noch viel langsamer als die direkte Positioniering.
Der Link ist interessant. Ist halt die Frage, ob man das selber strickt oder ob das in die osmpbf.jar gehört.
Zumindest bei der jetzigen Implementierung von splitter hat die osmpbf.jar die Kontrolle und ruft Funktionen von splitter auf. Da habe ich gar keine Chance, irgendeinen Offset anzugeben.
Habe mich aber auch schon lange nicht mehr damit beschäftigt.
Habe mal einen experimentellen Zweig für splitter angefangen, mit dem man eine osm Datei nach o5m konvertieren kann. Siehe auch
https://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=604
Das binary gibt es unten auf der Download Seite: https://www.mkgmap.org.uk/download/splitter.html
Beispiel:
java -cp dist\splitter.jar uk.me.parabola.splitter.Converter niedersachsen-latest.osm.pbf niedersachsen.o5m
Macht ziemlich genau das, was bei
osmconvert --drop-version --drop-author niedersachsen-latest.osm.pbf -o=niedersachsen.o5m
rauskommt, allerdings nicht besonders optimiert und daher langsamer (vielleicht Faktor 1.5).
Wirft allerdings zusätzlich auch noch alle created_by tags weg, die wurden von splitter schon immer “verschluckt” und auch der timestamp der Datei wird noch ignoriert.
Einen vollstängen Ersatz vom osmconverter will ich da aber eh nicht bauen, vielleicht noch die Ausschneide-Funktionen. Im Prinzip ist das ja in splitter schon drin, aber halt optimiert für das Aufteilen in mehrere (viele) Kacheln.
Eigentlich finde ich Idee interessanter, damit on-the-fly eine temporäre Datei zu schreiben, die dann nach dem ersten Lesen verwendet werden kann.