osmconvert: --complete-ways und --all-to-nodes

quasilotte · 2011-11-27T10:27:15.000Z

laufkaefer:

ich kann mit --complex-ways immer noch keine großen dateien schneiden, weder mit vkw.bplaced.net/osm/osmconvert64.exe noch mit einer frisch selbst kompilierten (could not rewind…)

da der thread ja seit ein paar tagen eingeschlafen scheint: habe nur ich das problem?

Nein !

Das mit der 2GB ist noch so !
Leider ist im Windows Bereich nicht so schnell mit einer Besserung zu rechnen!

Man muß mit einem Vorausschnitt aus der großen datei leben (ohne --complex-ways bzw. --copmplete-ways) und dann daraus dann das extrakt mit --complex-ways bzw. --copmplete-ways erstellen.

Als ausreichen empfinde ich es den Vorausschnitt 2 Grad größer in allen Richtungen zu wählen als benötigt bzw. einen großen Bereich zu wählen der sein Gebiet komplett abdeckt.

Beispiel : aus der europe.osm.pbf die bbox von Germany ausschneiten (am besten Gleich da --drop-version --drop-author mitgeben) daraus kann man dann seine --complex-ways bzw. --copmplete-ways -Auschnitte erstellen ohne jedesmal aus der europe.osm.pbf ausschneiden zu müssen!

Zeitlich ist garnicht soviel Unterschied ob dierekt aus der europe.osm.pbf oder europe.osm.pbf>Vorausschnitt>Ausschnitt.
Die Zeit die man beim Vorausschnitt benötigt wird zum Teil durch die nun kleinere Datei ausgegelichen die ja schneller geht!

laufkaefer · 2011-11-27T11:31:23.000Z

auch bei win 64bit? dann sollten wir die wiki korrigieren.

laufkaefer · 2011-11-28T10:41:10.000Z

und das problem liegt daran, dass zlib unter windows keine großen dateien bewältigen kann? dann am ende das: zlib-1.2.5-win32-largefile.patch

https://build.opensuse.org/package/files?package=mingw32-zlib&project=home%3Amkbosmans%3Amingw32

kellerma · 2011-11-28T19:02:58.000Z

laufkaefer:

und das problem liegt daran, dass zlib unter windows keine großen dateien bewältigen kann? dann am ende das: zlib-1.2.5-win32-largefile.patch

https://build.opensuse.org/package/files?package=mingw32-zlib&project=home%3Amkbosmans%3Amingw32

Im git
https://github.com/madler/zlib/tree/develop
sollte es enthalten sein:
Include zconf.h for windows large file support. (1. Oct)
nicht aber im 1.2.5.1-Tarball

viw · 2011-11-28T22:50:08.000Z

kellerma:

laufkaefer:

und das problem liegt daran, dass zlib unter windows keine großen dateien bewältigen kann? dann am ende das: zlib-1.2.5-win32-largefile.patch

https://build.opensuse.org/package/files?package=mingw32-zlib&project=home%3Amkbosmans%3Amingw32

Im git
https://github.com/madler/zlib/tree/develop
sollte es enthalten sein:
Include zconf.h for windows large file support. (1. Oct)
nicht aber im 1.2.5.1-Tarball

Für die 64 bit Version habe ich eine bereits fertig übersetzte zlib Version genommen. Wenn jemand mir sagt, wie ich die sourcen übersetzen kann, dann mache ich auch das gerne.

kellerma · 2011-11-29T16:52:57.000Z

viw:

Für die 64 bit Version habe ich eine bereits fertig übersetzte zlib Version genommen. Wenn jemand mir sagt, wie ich die sourcen übersetzen kann, dann mache ich auch das gerne.

git clone git://github.com/madler/zlib.git
cd zlib
cp win32/Makefile.gcc .
make -fMakefile.gcc

oder so ähnlich

Marqqs · 2011-11-29T17:42:12.000Z

@kellerma
Ich hab gesehen, du hast die Download-and-Compile-Links derart ergänzt, dass der Optimierer des Compilers eingeschaltet wird. Gute Idee, danke!
Ich hab bisher meistens mit -O3 übersetzt, du empfiehlst aber -O2. Ist das in dem Fall besser?

viw · 2011-11-29T17:49:30.000Z

Marqqs:

@kellerma
Ich hab gesehen, du hast die Download-and-Compile-Links derart ergänzt, dass der Optimierer des Compilers eingeschaltet wird. Gute Idee, danke!
Ich hab bisher meistens mit -O3 übersetzt, du empfiehlst aber -O2. Ist das in dem Fall besser?

Also in meinen Testst konnte ich keine weiteren Verbesserungen erzielen. Als das übersetzen in 64 bit mit -O3. alle anderen Optionen wie vorreservieren von Speicher usw. hatten keine Auswirkungen. Das parallelisieren ist leider dann beim linken gescheitert.

viw · 2011-11-29T18:04:59.000Z

kellerma:

viw:

Für die 64 bit Version habe ich eine bereits fertig übersetzte zlib Version genommen. Wenn jemand mir sagt, wie ich die sourcen übersetzen kann, dann mache ich auch das gerne.

git clone git://github.com/madler/zlib.git
cd zlib
cp win32/Makefile.gcc .
make -fMakefile.gcc

oder so ähnlich

nachdem installieren von gnumake funktioniert sogar die letzte Zeile unter Windows. Jetzt ist aber osmconvert noch nicht übersetzt.
Wie also jetzt weiter vorgehen?
Sorry ich bin was complieren angeht einfach blutiger Anfänger.

kellerma · 2011-11-29T18:43:55.000Z

Marqqs:

@kellerma
Ich hab gesehen, du hast die Download-and-Compile-Links derart ergänzt, dass der Optimierer des Compilers eingeschaltet wird. Gute Idee, danke!
Ich hab bisher meistens mit -O3 übersetzt, du empfiehlst aber -O2. Ist das in dem Fall besser?

Oh, das musst Du jemanden fragen, der sich mit dem Zeugs auskennt, auf keinen Fall mich

Meine Wenigkeit konnte zwischen
-O2 -march=native
und
-O3
(im Gegensatz zu
-O0
)
keine großen Unterschiede feststellen, außer dass es mit -O3
3 Sekunden länger zum kompilieren braucht

Kann gut sein, wenn man europe oder den planet nimmt, dann Unterschiede feststellbar sind.
Doch unsereins begnügt sich mit
{oberpfalz,mittelfranken}.osm.pbf

kellerma · 2011-11-29T19:30:34.000Z

viw:

kellerma:

git clone git://github.com/madler/zlib.git
cd zlib
cp win32/Makefile.gcc .
make -fMakefile.gcc

oder so ähnlich

nachdem installieren von gnumake funktioniert sogar die letzte Zeile unter Windows. Jetzt ist aber osmconvert noch nicht übersetzt.
Wie also jetzt weiter vorgehen?
Sorry ich bin was complieren angeht einfach blutiger Anfänger.

Oh, das musst Du jemanden fragen, der sich mit dem Zeugs auskennt, auf keinen Fall mich

laufkaefer · 2011-11-30T12:55:37.000Z

mit dem kompilieren kann ich leider auch nicht weiterhelfen, ich habe aber einen relativ einfachen workaround gefunden: http://www.ubuntu.com/download/ubuntu/windows-installer

mit wubi kann man recht einfach (z.b. ohne die festplatte partitionieren müssen oder ähnliche spässe) neben win ein linux aufsetzen und dann den schnitt großer dateien von linux aus erledigen. ich selber nutze xubuntu, ntfs-platten werden sofort mit lese-/schreibrechten eingebunden, allerdings ohne exec-rechte. um osmconvert also ausführen zu können, muss man entweder die rechte noch setzen, oder aber osmconvert aus userland laufen lassen und die ntfs-platte nur für die daten nutzen.

viw · 2011-11-30T12:59:48.000Z

laufkaefer:

mit dem kompilieren kann ich leider auch nicht weiterhelfen, ich habe aber einen relativ einfachen workaround gefunden: http://www.ubuntu.com/download/ubuntu/windows-installer

mit wubi kann man recht einfach (z.b. ohne die festplatte partitionieren müssen oder ähnliche spässe) neben win ein linux aufsetzen und dann den schnitt großer dateien von linux aus erledigen. ich selber nutze xubuntu, ntfs-platten werden sofort mit lese-/schreibrechten eingebunden, allerdings ohne exec-rechte. um osmconvert also ausführen zu können, muss man entweder die rechte noch setzen, oder aber osmconvert aus userland laufen lassen und die ntfs-platte nur für die daten nutzen.

Man muss nichtmal Wubi nehmen. Ich habe zum Beispiel meinen rendering Server in einer VM laufen. virtualbox.org und dort schuftet ein Ubuntu Server drin. Ist auch einfach per Browser erreichbar.

ajoessen · 2011-11-30T13:04:58.000Z

laufkaefer:

mit wubi kann man recht einfach (z.b. ohne die festplatte partitionieren müssen oder ähnliche spässe) neben win ein linux aufsetzen und dann den schnitt großer dateien von linux aus erledigen.

Ja, hatte ich auch mal gedacht. Leider nur bis zum nächsten Software Update. Dabei wurde nämlich der ubuntu-Bootloader aktualisiert, und danach konnte ich weder mit Windows noch mit Ubuntu hochfahren.
Mit “grub-rescue>” konnte ich in dem Moment wenig anfangen

Dann doch lieber zwei getrennte Rechner.

Gruß,
ajoessen

kellerma · 2011-12-04T06:22:47.000Z

viw:

kellerma:

viw:

Für die 64 bit Version habe ich eine bereits fertig übersetzte zlib Version genommen. Wenn jemand mir sagt, wie ich die sourcen übersetzen kann, dann mache ich auch das gerne.

git clone git://github.com/madler/zlib.git
cd zlib
cp win32/Makefile.gcc .
make -fMakefile.gcc

oder so ähnlich

nachdem installieren von gnumake funktioniert sogar die letzte Zeile unter Windows. Jetzt ist aber osmconvert noch nicht übersetzt.
Wie also jetzt weiter vorgehen?
Sorry ich bin was complieren angeht einfach blutiger Anfänger.

Die nun erzeugten zconf.h, zlib.h, sowie zlib1.dll, libz.a & libzdll.a an die entsprechenden Stellen kopieren (überbügeln), welche Du mal mit Deinem

quasilotte:

Such mal nach
zlib-1.2.5-bin-x64.zip
die Ordner kopierst du in mingw Ordner x86_64-w64-mingw32

erhalten hast. Ggf. rebooten.

PA94 · 2011-12-04T22:09:25.000Z

Hallo,

laufkaefer:

und das problem liegt daran, dass zlib unter windows keine großen dateien bewältigen kann? dann am ende das: zlib-1.2.5-win32-largefile.patch

Ich hab mal die mit dem o.a. Patch versehene zlib-1.2.5 mit MinGW compiliert: Das Ergebnis kann man unter

http://www.datafilehost.com/download-a056a69e.html

downloaden.
Danach die Datei “libz.a” nach “c:\mingw\lib” und die Datei “zlib.h” nach “c:\mingw\include” kopieren (und dabei jeweils die alte Version überschreiben, wer will kann auch die alte Version nach “…_old” umbenennen).
Nach einer Neukompilation von osmconvert sollte (ich hab’s nicht probiert mangels pbf-File welches groß genug ist ) der “rewind-Bug” (ich nenn den hiermit offiziell so!) beseitigt sein.

@Marqqs:
Wenn Du magst, kannst Du ja mal eine neue Version mit der gepatchten zlib zur Verfügung stellen

@quasilotte:
Wenn die neue Version von Marqqs da ist, könntest Du sie bitte testen und das Ergebnis hier posten? Danke!

Schöne Grüße

PA94

quasilotte · 2011-12-05T16:39:48.000Z

PA94:

Hallo,

laufkaefer:

und das problem liegt daran, dass zlib unter windows keine großen dateien bewältigen kann? dann am ende das: zlib-1.2.5-win32-largefile.patch

Ich hab mal die mit dem o.a. Patch versehene zlib-1.2.5 mit MinGW compiliert: Das Ergebnis kann man unter

http://www.datafilehost.com/download-a056a69e.html

downloaden.
Danach die Datei “libz.a” nach “c:\mingw\lib” und die Datei “zlib.h” nach “c:\mingw\include” kopieren (und dabei jeweils die alte Version überschreiben, wer will kann auch die alte Version nach “…_old” umbenennen).
Nach einer Neukompilation von osmconvert sollte (ich hab’s nicht probiert mangels pbf-File welches groß genug ist ) der “rewind-Bug” (ich nenn den hiermit offiziell so!) beseitigt sein.

@Marqqs:
Wenn Du magst, kannst Du ja mal eine neue Version mit der gepatchten zlib zur Verfügung stellen

@quasilotte:
Wenn die neue Version von Marqqs da ist, könntest Du sie bitte testen und das Ergebnis hier posten? Danke!

Schöne Grüße

PA94

Bei mir kommt die Meldung das die ld.exe skipping inkompatibel zur libz.a ist wenn searching -lz verwende !

Verwendung nur der gepatchten zlib.h behebt das Problem nicht !

kellerma · 2011-12-05T17:01:00.000Z

quasilotte:

Bei mir kommt die Meldung das die ld.exe skipping inkompatibel zur libz.a ist wenn searching -lz verwende !

Verwendung nur der gepatchten zlib.h behebt das Problem nicht !

Du, Euer Windows-Zeugs ist recht kompliziert

Du kannst ja noch mal wie ich oben in post 151 beschrieben zlib selbst kompilieren versuchen,
dann könnte - vielleicht - der link editor passen

PA94 · 2011-12-05T22:28:54.000Z

Hallo,

quasilotte:

Bei mir kommt die Meldung das die ld.exe skipping inkompatibel zur libz.a ist wenn searching -lz verwende !

Das verstehe ich nicht!
Es wäre hilfreicher gewesen, wenn Du die genaue Ausgabe des Compilers/Linkers gepostet hättest…

quasilotte:

Verwendung nur der gepatchten zlib.h behebt das Problem nicht !

Ja, das ist auch nicht weiter verwunderlich

Aber wenn der Prophet (oder heisst es nach der neuen Rechtschreibung Profet???) nicht zum Berg kommt…

Also hier die Anleitung wie Du selbst die gepatchte Version bauen kannst:

zlib-1.2.5 http://zlib.net/zlib125.zip runterladen und im Verzeichnis c:\xyz (oder ein Verzeichnis Deiner Wahl) speichern.
Patch https://api.opensuse.org/public/source/home:mkbosmans:mingw32/mingw32-zlib/zlib-1.2.5-win32-largefile.patch runterladen und auch im Verzeichnis c:\xyz speichern.
Dos-Box öffnen und folgende Zeilen eingeben (jede Zeile für sich, jeweils mit RETURN-Taste abschliessen):


cd c:\xyz
patch -b -p 0 -i zlib-1.2.5-win32-largefile.patch
cd zlib-1.2.5
make -f win32/Makefile.gcc

Nun solltest Du im Verzeichnis c:\xyz\zlib-1.2.5 unter anderem die beiden Dateien “zlib.h” und “libz.a” haben.

Die Datei “libz.a” nach “c:\mingw\lib” und die Datei “zlib.h” nach “c:\mingw\include” kopieren (evtl. alte Dateien vorher als “…_old” backuppen).
osmconvert neu compilieren.

HTH

PA94

quasilotte · 2011-12-07T05:59:31.000Z

PA94:

Hallo,

Aber wenn der Prophet (oder heisst es nach der neuen Rechtschreibung Profet???) nicht zum Berg kommt…

Also hier die Anleitung wie Du selbst die gepatchte Version bauen kannst:

zlib-1.2.5 http://zlib.net/zlib125.zip runterladen und im Verzeichnis c:\xyz (oder ein Verzeichnis Deiner Wahl) speichern.

Patch https://api.opensuse.org/public/source/home:mkbosmans:mingw32/mingw32-zlib/zlib-1.2.5-win32-largefile.patch runterladen und auch im Verzeichnis c:\xyz speichern.

Dos-Box öffnen und folgende Zeilen eingeben (jede Zeile für sich, jeweils mit RETURN-Taste abschliessen):
cd c:\xyz
patch -b -p 0 -i zlib-1.2.5-win32-largefile.patch
cd zlib-1.2.5
make -f win32/Makefile.gcc
Nun solltest Du im Verzeichnis c:\xyz\zlib-1.2.5 unter anderem die beiden Dateien “zlib.h” und “libz.a” haben.

Die Datei “libz.a” nach “c:\mingw\lib” und die Datei “zlib.h” nach “c:\mingw\include” kopieren (evtl. alte Dateien vorher als “…_old” backuppen).

osmconvert neu compilieren.

HTH

PA94

Ich hab den patch eingespielt (patch ist meinem System unbekannt deshalb musste ich dies manuell machen [sind ja nur ein paar Änderungen!]).

make -f win32/Makefile.gcc

lief Fehlerlos durch und auch das konvertieren der osmconvert war problemlos.

Leider bleibt bei mir trotzdem die übliche Meldung bei der europe.osm.pbf .

Für mich ist dieses Thema durch - ist sowieso für mich nur ein Schönheitsfehler da Maperitive ja eh nur in sinnvoller Zeit Dateien verarbeitet die deutlich unter der 2GB Grenze liegen und größere bereich schneid ich eh nur ohne --complete-ways/complex-ways.

Wenn ein Anderer es schafft >2GB Dateien damit zu schneiden darf er es ruhig bekannt geben, allerdings geh ich davon aus da dies Thema hier schon einige Tage ungelößt ist, entweder es geht nicht oder es verwendet keiner Windows + große Dateien !! wobei ich vermute ersteres!!!