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!
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.
BTW: Bist Du der Gerd aus der Mkgmap-Development-Mailliste?
BTW: Bist Du der Gerd aus der Mkgmap-Development-Mailliste?
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.
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?
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…
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:
“To speed-up the process, the program uses some main memory for a\n”
“hash table. By default, it uses 1800 MB for storing a flag for every\n”
“possible node, 180 for the way flags, and 20 relation flags.\n”
“Every byte holds the flags for 8 ID numbers, i.e., in 1800 MB the\n”
“program can store 14400 million flags. As there are less than 7400\n”
“million IDs for nodes at present (Mar 2020), 925 MB would suffice.\n”
(…)
“Because we are taking hashes, it is not necessary to provide all the\n”
“suggested memory; the program will operate with less hash memory too.\n”
“But, in this case, the border filter will be less effective, i.e.,\n”
“some ways and some relations will be left in the output file although\n”
“they should have been excluded.\n”
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?
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.