Extrakte mit OSMConvert zusammenbauen

Communities Deutschland (Germany)
21

Hi ich werd hier wohl etwas offtopic - aber das Wort Speicherverwaltung hat nee Frage ausgelößt:

Im wiki steht für

–complex-ways und --complete-ways
*
Bei dieser wie auch bei der nachfolgend beschriebenen Option gilt für 32-Bit-Windows eine Größenbeschränkung für die Eingabedatei: Da die Datei mehrfach gelesen werden muss – es wird in der Datei “gesprungen” – darf ihre Größe 2 GiB nicht überschreiten.** Für 64-Bit Windows sowie für 32- und 64-Bit-Linux gilt diese Einschränkung nicht.**
Ebenfalls für diese und die nachfolgende Option wird empfohlen, als Eingabeformat .o5m zu verwenden, da .pbf-Dateien in der Regel intern komprimiert sind und deswegen deutlich länger benötigen um (mehrfach) eingelesen zu werden.
*

Beim Ausführen von:
osmconvert.exe --complex-ways --drop-version --drop-author --emulate-osmosis -b=8.7,49.75,9.75,50.5 G:\OSM\europe.osm.pbf -o=G:\OSM\Test.pbf

bekomme ich allerdings immer noch den Üblichen Fehler das nicht in Dateien gehüpft werden kann die größer wie 2GiB sind.

Stimmt die Aussage im Wiki oder ist beim compilieren was zu beachten oder gilt das nicht für pbf…?

System Win7 64-Bit mit 16GB
Compiliert: C:\mingw64\bin\gcc.exe osmconvert07P.c -lz -O3 -o osmconvert.exe

und auch

C:\mingw64\bin\gcc.exe osmconvert07P.c -m64 -lz -O3 -o osmconvert.exe
kein Unterschied

22

quasilotte:

Hier muss ich auch passen. Vielleicht ist die zlib nicht auf dem neuesten Stand oder liegt nur in der 32-Bit-Version vor? Mit -v oder -v=2 sollte osmconvert die Versionsnummer der zlib ausgeben - wenn ich mich jetzt recht erinnere.

Erledigt. :slight_smile:

23
24

Danke leider ist es nicht die zlib = Version 1.2.7
auch hab ich den gcc neu aufgespielt Version 4.7.2

Jetzt weis ich auch nicht mehr weiter!!!

Wenn jemand eine osmconvert hat die mit Win 7 auch grosse PBF verarbeiten kann mit --complex-ways und --complete-ways bitte bei mir Melden!

25

kellerma: Bitte nicht übertreiben. :slight_smile:

Helfen kann ich zwar auch nicht, aber wenn du noch probieren magst, ob es tatsächlich irgendwas mit der zlib zu tun hat, könntest du versuchsweise die Konstante read_GZ ändern und danach neu compilieren:

#define read_GZ 3  // determines which read procedure set will be used;
  // ==0: use open();  ==1: use fopen();
  // ==2: use gzopen() (accept gzip compressed input files);
  // ==3: use gzopen() with increased gzip buffer;

Normal steht read_GZ auf 3, aber wenn du keine gezippten Dateien liest, kannst du es auch mal mit dem Wert 0 oder 1 versuchen. Wahrscheinlich läuft das Programm dann sogar 1 oder 2 % schneller.

26

Mit

read_GZ 0

funkioniert der Zugriff mit --complex-ways auf die europe.osm.pbf
alle anderen Werte (1,2,und 3) ergeben sich Fehlermeldungen.
Leider ergibt sich da kein Zeilicher Vorteil (Wie erhoft!)

Auschneiden dauert dabei ca. 5:10min
Wie bisher mit Vorauschnitt (=+ 2 Grad drumrum [Ergibt o5m-Dateien die noch gut unter 2GiB sind!]) dauert 2:30 + 30 sek das Ausschneiden aus dem Ausschnitt mit --complex-ways
Bin also mit Vorausschnitt deutlich schneller.

Allerdings ist der Auschnitt verschieden groß - was ich Hauptsächlich auf Ways und Nodes zurückzuführen ist die Über Realtionen noch in den Randbreich des Ausschnitts gehören.
Habe allerdings noch keine Auswirkungen auf den Kernbereich festgestellt!

Noch der Statistik halber:
mit complex-ways direkt: 10763263 nodes, 1688143 ways and 22252 relations
mit Vorausschnitt dann compex-ways: 10736353 nodes, 1687917 ways and 22252 relations