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.