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

Marqqs · 2011-11-23T12:02:25.000Z

Ja, ich hab auch an “REM” und an “#” gedacht, mich dann aber trotzdem für "// " entschieden. Ich denk, es ist wirklich nicht so wichtig. Gegen “rem” sprach, dass es auch der Name einer Datei sein kann - oder der Name eines Tags (für osmfilter). “#” erinnert an die Linux-Shell und ist bei Windows unüblich - soweit ich weiß. “//” ist ein C-Kommentarzeichen (ab C99, glaub ich), C++ hatte es schon vorher eingeführt. Es ist damit plattformübergreifend und politisch korrekt. Aber jetzt wirds fast schon philosophisch.

quasilotte:

Kann es sein das mit der aktuelle 05N nur eine bestimmte Anzahl an Zeichen aus der --parameter-file= gelesen werden?
Wenn ich mich nicht verzählt habe sind es immer 80 Zeichen!

Den Fehler konnte ich leider nicht reproduzieren. Ich hab meine Parameterdatei grad auf 784 Bytes aufgeblasen, es gab keine Probleme. Intern beschränkt ist die Größe der Parameter-Datei tatsächlich, allerdings auf 1 MB.

quasilotte · 2011-11-23T17:05:42.000Z

Jepp An der Größe liegt es nicht!

Aber irgendwie scheint es das CR LF - Windows Problem zu sein .

Wenn ich Zeile für Zeile in die Filter-Datei schreibe gibts nee Fehlermeldung und es werden die ersten 80 Zeichen des Strings(Mit Filter-Datei inhalt) ausgegeben.

ala:
G:\PBF\ausschnitt.pbf
–complex-ways
–drop-version
–drop-author
–emulate-osmosis
–out-pbf
-b=6.731,48.822,8.738,49.938

Wenn ich immer eine Zeile dazwischen lasse geht es :

G:\PBF\ausschnitt.pbf

–complex-ways

–drop-version

–drop-author

–emulate-osmosis

–out-pbf

-b=6.731,48.822,8.738,49.938

Bei osmfilter hab ich damit keine Probleme ???

–keep=
building=
crossing_ref=puffin
historic=memorial
historic=monument
historic=castle
historic=fort
…
geht wunderbar

geht eigentlich in osmconvert -o=test.pbf in der Filter-Datei
da komm immer bei mir

could not opening ouput file : _

Extrakt schreiben geht nur wie vorher mit > test.pbf bzw. direkt in den osmconvert Aufruf

Marqqs · 2011-11-23T20:16:04.000Z

quasilotte:

ala:
G:\PBF\ausschnitt.pbf
–complex-ways
–drop-version
–drop-author
–emulate-osmosis
–out-pbf
-b=6.731,48.822,8.738,49.938

Wenn ich immer eine Zeile dazwischen lasse geht es :

G:\PBF\ausschnitt.pbf

–complex-ways

–drop-version

–drop-author

–emulate-osmosis

–out-pbf

-b=6.731,48.822,8.738,49.938
(…)
Extrakt schreiben geht nur wie vorher mit > test.pbf bzw. direkt in den osmconvert Aufruf

Ich glaub, so langsam versteh ich, was du meinst.

Zwischen den einzelnen Parametern MUSS eine Leerzeile sein. Dann gehts. Das ist bei osmfilter aber auch nicht anders: Innerhalb einer --keep-Option braucht man keine Leerzeilen. Beispiel:

--keep=
railway=station
highway=primary

Das ist EIN Parameter, er wird automatisch zusammengesetzt zu (sinngemäß):

--keep="railway=station highway=primary"

Wenn du zwischen “–complex-ways” und “–drop-version” keine Leerzeile einfügst, werden diese beiden Angaben zusammengehängt zu “–complex-ways --drop-version”. Damit kann das Programm nichts anfangen.

Das mit den “genau 80 Zeichen” liegt nur an der Protokollausgabe, die du mit “-v” einschaltest. Von den einzelnen protokollierten Parametern werden immer nur die ersten 80 Zeichen ausgegeben. Fürs Protokoll reicht das auch, denn Parameter überschreiten diese Länge normalerweise nicht.

Zum “> test.pbf”:
Das ist kein Parameter, sondern die Anweisung ans Betriebssystem, ausgegebene Daten in eine Datei umzulenken. Das Programm bekommt davon gar nichts mit. Schreibt man “> test.pbf” trotzdem in eine Parameter-Datei kann das Programm damit nichts anfangen. Anders ist das bei “-o=test.pbf”.

Sorry, klingt jetzt vielleicht alles etwas verwirrend…

kellerma · 2011-11-23T20:35:47.000Z

Marqqs:

Zum “> test.pbf”:
Das ist kein Parameter, sondern die Anweisung ans Betriebssystem, ausgegebene Daten in eine Datei umzulenken. Das Programm bekommt davon gar nichts mit. Schreibt man “> test.pbf” trotzdem in eine Parameter-Datei kann das Programm damit nichts anfangen. Anders ist das bei “-o=test.pbf”.

Hier irrt der MEISTER

Vgl.
$ osmconvert mittelfranken.osm.pbf -o=test.pbf

mit
$ cat param.txt
mittelfranken.osm.pbf

-o=test.pbf

$ osmconvert --parameter-file=param.txt 
Speicherzugriffsfehler

Marqqs · 2011-11-23T21:12:22.000Z

kellerma:

Hier irrt der MEISTER

Vgl.
$ osmconvert mittelfranken.osm.pbf -o=test.pbf

mit
$ cat param.txt
mittelfranken.osm.pbf
-o=test.pbf

$ osmconvert --parameter-file=param.txt 
Speicherzugriffsfehler

Ui, ein Bug, ein Bug!
Danke für den Tipp, hab ihn erlegt (0.5P).

quasilotte · 2011-11-23T22:20:55.000Z

Danke

@ kellerma

jo genau das meinte ich.

@ Marqqs

Jetzt komm ich so langsam hinter die ganze Syntax - schon verzweifelt weil bei osmfilter es mit den Regeln auch nicht immer so rund lief!

laufkaefer · 2011-11-27T09:52:26.000Z

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?

viw · 2011-11-27T10:25:05.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?

Ich glaube nicht. Aber es gibt keine Lösung für das Problem. Wenn du eine hast, ist sie sicher willkommen.

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.