Osmconverter ausschneiden funktioniert nicht

hab die an https://forum.openstreetmap.org/misc.php?email=12530 geschickt. Ist deine Foren-Mail.

Ich möchte nochmal das Thema zum Erzeugen einer voll funktionierenden osmconvert64.exe für Windows64 aufgreifen
Ich hatte das gleiche Problem mit der Alps-latest.osm.pbf (2,532 GB) unter Windows10 64-Bit
beim Ausschnitt erzeugen mit Option --complete-multipolygons
Fehlermeldung : Osmconvert Error could not rewind file

oder Ergebnisdatei nur 205 Bytes groß bei kleinerer Eingangsdatei: italy-nord-est-latest.osm.pbf (486,8 MB)
beim Ausschnitt erzeugen mit Option --complete-multipolygons
Grund für --complete-multipolygons: z.B. Gardasee Nord ergibt ohne die Option weissen See wenn der abgeschnitten
wird oder auch andere weisse Flächen/Gebirge beim Kartenerzeugen wenn Polygone nicht geschlossen sind.

Die auf der Osmconvert-Wiki Seite verlinkte Version “binary for Windows 64 bit (see Limitations)” funktioniert also in vielen Fällen nicht.
----- weitere Tests von mir ---------
Die auf der Osmconvert-Wiki Seite verlinkte Version “binary for Windows 32 bit” funktioniert überhaupt nicht mit Windows10 64-bit. 16GB Memory
Die auf der Osmconvert-Wiki Seite verlinkte Version “binary for Windows 32 bit” funktioniert überhaupt nicht mit Windows7 32-bit. 4GB Memory
osmconvert Error: PBF write: not enough memory
Source Dateien Alps-latest.osm.pbf(2,532 GB) und alps_tirol_obb_mid.pbf(132 MB) mit und ohne Option --complete-multipolygons

Unter Linux64 funktioniert die auf der Osmconvert-Wiki Seite verlinkte 64-bit Linux Version einwandfrei.
Unter Linux64 und Linux32 funktioniert die auf der Osmconvert-Wiki Seite verlinkte 32-bit Linux Version einwandfrei.

Lange Inet-Recherchen zu diesem Thema ergaben folgenden Sachverhalt:
Unter Linux64 erfolgt die Source-File Compilierung von osmconvert.h + zlib automatisch mit voller 64-Bit Unterstützung auch für File-Adressvektoren
Für Windows egal ob 32-Bit oder 64-Bit werden bei der Compilierung automatisch immer 32-Bit für File-Adressvektoren benutzt (aktuelle zlib für Windows)
(-> Limit 2,147 GB bei 512Bytes/Sector Festplattenformatierung), 64-Bit File-Adressvektoren erfordern spezielle Maßnahmen.

Die Angaben dazu auf der Osmconvert-Wiki Seite zum LargeFileSupport sind durchaus richtig aber leider nicht selbsterklärend zum selbst compilieren des Source-Codes.

Daher hier eine Kurzanleitung wie ich unter Linux64 mit dem Cross-compiler System MinGW-w64 erfolgreich ein voll funktionierendes Windows Executable erzeugt habe.
(viele der Compiler-Optionen stammen aus langem Ausprobieren mit Inet-Recherchen)

Alle Meine Compile-Versuche wurden mit folgendem Linux-System gemacht (da ich unter Windows keinen Compiler eingerichtet habe):
Compile System : Ubuntu 18.04 bionic (x86-64)

komplett Installation von MinGW-w64 (Version 5.0.3-1)
(Cross-compiler für Windows z.B. gcc-mingw-w64 ver.7.3.0-11 ) ;
z.B. mit Synaptic-Paketverwaltung nach mingw suchen → alles installieren!

Download zlib sourcecode von https://sourceforge.net/projects/libpng/files/zlib/1.2.11/ :

https://sourceforge.net/projects/libpng/files/zlib/1.2.11/zlib-1.2.11.tar.gz/download
entpacken in neues Verzeichnis z.B. zlib1211

Download osmconvert sourcecode von http://m.m.i24.cc/osmconvert.c
kopieren auch ins Verzeichnis zlib1211

Command-Shell in Verzeichnis zlib1211 öffnen

Dort folgende Komandos ausführen (ohne die Kommentare → !):

→ sorgt für z_off64_t = __int64 in der config Datei zconf.h.in

sed -i "s,define z_off64_t off64_t,define z_off64_t __int64," zconf.h.in

→ sorgt für z_off64_t = __int64 in der config Datei zconf.h.in

sed -i "s,define z_off64_t z_off_t,define z_off64_t __int64," zconf.h.in

→ versetzt Verzeichnis in Ursprungszustand für Neukompilierung

make distclean

→ versetzt Verzeichnis in Ursprungszustand für Neukompilierung

make clean -f win32/Makefile.gcc

→ konfiguriert zum Compilieren für Windows64

CHOST=x86_64-w64-mingw32 ./configure  --static

→ compiliert zlib neu für Windows64 mit 64-Bit File-Adressing

make -f win32/Makefile.gcc CC=x86_64-w64-mingw32-gcc RC=x86_64-w64-mingw32-windres IMPLIB=libz.dll.a CFLAGS="-O2 -s -pipe -D_LFS64_LARGEFILE=1 -D_LARGEFILE64_SOURCE=1 --param=ssp-buffer-size=4"

→ compiliert osmconvert für Windows64 mit neuer zlib und Optimierung-Stufe (-O2) und ohne Debugging Symbols (-s)

x86_64-w64-mingw32-gcc osmconvert.c -static ./libz.a -O2 -s -o osmconvert64_lfs.exe

→ erzeugt wird folgendes Windows Executable: osmconvert64_lfs.exe
DOS/Windows-Programmdatei (application/x-ms-dos-executable) 222,2 kB (222208 Bytes)
http://www.muenchen-surf.de/rohyman/osmconvert/osmconvert64_lfs.exe

Es wäre super wenn jemand das File mit seinen osmconvert Optionen testen könnte und bei Erfolg ins Osmconvert-Wiki verlinkt.

Eine funktionierende Version für Windows32 mit LargeFileSupport oder für die problematischen Optionen --complete-multipolygons etc. ist mir bisher nicht gelungen

Ob die auf der Osmconvert-Wiki Seite (binary for Windows 64 bit (with large file support)) verlinkte Version
https://yadi.sk/d/Vnwc4kut3LCBFm → osmconvert64-0.8.8p.exe vertrauenswürdig ist weiss ich auch nicht, Virenscan ist nicht alles!
Wie kann es sein daß ein nicht OSM registrierter User einen Link auf externe Dateien auf der Osmconvert-Wiki Seite erzeugt?
Auf jeden Fall ist die dort verlinkte osmconvert64-0.8.8p.exe wesentlich grösser : 312,0 kB (311997 Bytes)
und erzeugt auch immer grössere Ergebnisdateien als meine bei gleichen osmconvert Optionen???
Ich habe auf jeden Fall keine Compileroption gefunden die eine gleiche Dateigrösse erzeugt.

Hallo zusammen,

ich möchte dieses Thema einmal aufwärmen und dabei auch gleich die Frage im letzten Post einigermaßen beantworten.

Ich habe auf Windows 10 mingw von nuwen (https://nuwen.net/mingw.html) und ein msys installiert.
Damit habe ich eine eigene zlib mit 64-bit Filesupport und 64-bit Fileoffset kompiliert und damit ein eigenes osmconvert64 gebaut.

Nun habe ich vier Versionen gegeneinander antreten lassen:

osmconvert64-0.8.8p - das legendäre Kompilat seltsamer Herkunft
osmconvert_mingw - mein eigenes Kompilat
osmconvert64_lfs - das Kompilat aus dem obigen Post
osmconvert64 - das fehlerhafte 64-bit-Kompilat aus dem Wiki

Hier das Ergebnis:

E:\CreateIMG>osmconvert64-0.8.8p -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>osmconvert_mingw -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract_mingw.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 41 dependencies.
Interrelational hierarchy 2: 1 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>osmconvert64_lfs -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract_lfs.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 41 dependencies.
Interrelational hierarchy 2: 1 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>osmconvert64 -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract_64.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
osmconvert Warning: unexpected end of input file: OSM-Data\germany+jordan.o5m

E:\CreateIMG>

Schon in der Ausgabe der unterschiedlichen Kompilate kann man sehen, daß da unter der Haube etwas anders läuft. Das legendäre Kompilat ist deutlich “redseliger”.

Hier die erzeugten Ausgabedateien:

02.05.2021  12:52         9.008.195 extract.o5m
02.05.2021  12:56         2.467.191 extract_mingw.o5m
02.05.2021  13:00         2.467.191 extract_lfs.o5m
02.05.2021  13:02                35 extract_64.o5m
02.05.2021  02:42     5.881.000.652 germany+jordan.o5m

Interessanterweise funktionieren sowohl mein eigenes, als auch das Kompilat aus dem vorigen Post anscheinend einwandfrei und erzeugen auch exakt das gleiche Ergebnis. Leider sind ihre Ergebnisse aber deutlich kleiner als das Ergebnis des legendären Kompilats. Was macht diese 0.8.8p-Version anders?

Außerdem kann man auch gut das Scheitern der fehlerhaften 64-bit-Version von der Wiki-Seite sehen.

Hat sonst noch Jemand eine Idee oder weiß irgendwelche “geheimen” Zutaten, die ich eventuell vergessen habe?

Weitere interessante Beobachtung:
Ich schneide aus einem großen Datensatz einen identischen Ausschnitt, einmal mit meinem Kompilat und einmal mit mit der 0.8.8p-Version.

E:\CreateIMG>osmconvert_mingw.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: 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>osmconvert64-0.8.8p.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>

Mit ziemlich unterschiedlichen Ergebnissen, das Ergebnis von 0.8.8p ist wesentlich größer:

02.05.2021  13:44     5.003.327.237 germany.o5m
02.05.2021  13:49     5.837.020.484 germany_.o5m
02.05.2021  02:42     5.881.000.652 germany+jordan.o5m

Speziell die “Interrelational hierarchy”-Ausgabe ist deutlich anders, eine ganze Ebene mehr! :expressionless:

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. :expressionless:

BTW: Bist Du der Gerd aus der Mkgmap-Development-Mailliste? :wink:

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