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?
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.
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.
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.