Osmconverter ausschneiden funktioniert nicht

Ich würde Dir die Dateien gerne zur Verfügung stellen, habe aber nur eine 2Mbit-Leitung mit ~400kbit Upload, das dauert eine Ewigkeit. :confused:
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… :wink:

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! :open_mouth:
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! :smiley:

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.