Extrakte mit OSMConvert zusammenbauen

Ja! Wissen wollen :wink:

Mmh, was macht aber bei 8 CPUs? (und 8 GPUs :wink:
Oder:
Was ist schneller? Ein lineares osmconvert oder 7 wambacher-threads?

Kann ich in einigen Wochen beantworten (*), wenn ich mich endlich zwischen Intel i7-3770 & Amd fx-8350 entschieden habe - ein 4x2 oder 8-Core wird es auf jeden Fall. Alle einschlägigen Benchmarks kümmern sich um Gamer aber ich suche nen starken Lunix-Rechenknecht zum Rendern und für Postgresql.

Vielen Dank an Markus für sein Statement. Beide Programme haben ihre Stärken und Schwächen und es steht ja jedem frei, “seine” Favoriten zu benutzen. Ich mache das jeweils passend zur aktuellen Aufgabenstellung.

Gruss
walter

*) ich tippe mal auf osmconvert, da ein Spezialist wohl performanter ist als eine “Eier legende Woll-Milch-Sau”

Zwei Nachfragen habe ich noch:

  • wie schaut das Format der “my.poly”-Datei aus, die osmosis eingefüttert werden soll? Die “area.poly”, welche splitter liefert, wird als unbekanntes Format abgelehnt.
  • wie bringe ich osmosis bei, die Kerne meines Rechners ordentlich zu nutzen? Der betreffende Java-Prozess belegt rund 30% CPU, also nur knapp mehr als einen der 4 Kerne.
    Die ursprüngliche Abfrage (mit bounding-box statt bounding-polygon) benötigte auf meinem Rechner 16 Minuten. Die optimierte habe ich noch nicht ausprobiert.

Walter, genau das meine ich. Sogar für die Aufgaben, die beide Programme beherrschen, ist es gut, wenn es mehrere Programme gibt. Denn was macht man, wenn man am Ergebnis zweifelt und einen Programmfehler vermutet? Man nimmt ein anderes Programm und schaut, ob das Ergebnis das Gleiche ist.
Osmosis und osmconvert sind von der Programmierung her grundverschieden, so dass es äußerst unwahrscheinlich ist, dass ein Fehler auf die gleiche Art in beiden Programmen auftritt.

OK, ein Ausflug in die “Röhren”. Normalerweise hast du nur eine Pipe und kannst sie nutzen, um die Ausgabe von einem Programm als Eingabe für ein anderes Programm zu verwenden. Das geht mit dem Pipe-Operator “|”.

Zusätzliche Pipes kannst du dir bauen, indem du Puffer anlegst, so genannte FIFOs. Den Fifos kannst du Namen geben, sie erscheinen dann im Verzeichnis ähnlich wie eine normale Datei. Ich hänge an den Namen “.o5m” an, damit osmconvert später weiß, dass es in die Fifos die Daten im Format o5m schreiben soll. Beispiel:

mkfifo fifo1.o5m fifo2.o5m fifo3.o5m

osmconvert land1.pbf -o=fifo1.o5m & osmconvert land2.pbf -o=fifo2.o5m & osmconvert land3.pbf -o=fifo3.o5m & osmconvert fifo1.o5m fifo2.o5m fifo3.o5m -o=alles.pbf

Das “&” nach einem Linux-Befehl bewirkt, dass dieser in einem eigenen Prozess im Hintergrund abläuft. Nur nach dem letzten Kommando ist kein “&”, das heißt, es läuft im Vordergrund. Alles in allem laufen dann 4 Prozesse parallel. Das nutzt die CPU sicher schön aus, ist aber nicht ganz so geschickt wie bei Osmosis, weil die einzelnen Prozesse ihre Daten nicht im Binärformat sondern im o5m-Format austauschen. Sollte aber trotzdem recht schnell sein, möglicherweise sogar schneller. Aber Geschwindigkeit ist wirklich nicht alles. :slight_smile:

Hier findest du einen sehr guten Artikel über das Thema: http://www.freiesmagazin.de/freiesMagazin-2011-03
(Kapitel “Datenströme…”)

Huch, da hatte ich gedacht, du würdest schon längst ein Polygon für deine Wunschecke verwenden.
hier ist das Format beschrieben: http://wiki.openstreetmap.org/wiki/Osmosis/Polygon_Filter_File_Format und so sieht mein Poly-File aus:


my
1
   11.962802   50.669635
   11.678070   50.544960
   11.704181   50.396182
   11.768836   50.227054
   11.972749   50.121142
   12.227640   50.090041
   12.412902   50.132302
   12.593191   50.287469
   12.598165   50.406485
   12.531022   50.513344
   12.350734   50.592344
   12.114493   50.639680
   11.962802   50.669635
END
END

Das ist aber nur ein willkürlich mit Josm erstelltes Polygon und stellt in etwa eine Fläche um das Dreiländer-Dreieck dar. Kann man in Josm mit dem Poly-Plugin ganz einfach erstellen: Leere Ebene, Polygon malen, als Polygon abspeichern, fertig:

Und für Profis: Wunschgrenze (Relation) laden, in einen Way konvertieren (c für Linien verbinden), als Poly abspeichern, fertig.
Format siehe http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Area_Filtering_Tasks

Ich vermute mal einen IO-Bound (*) kann es aber noch nicht mit 4 oder 8 Cores testen, da ich nur einen klapprigen Athlon 64 2X habe und der ist bei dieser Aktion voll ausgelastet. Hier

kann man den Anstieg der Auslastung bei beiden Cores gut sehen. Was will ich mehr - ausser 'ner besseren Kiste. :wink:

Es gibt in Osmosis aber noch einen weiteren Befehl zum Tunen: Osmosis/Tuning und hier der Befehl –buffer Da ist bestimmt noch was zu holen.

Gruss
walter

*) Nachtrag zum IO-Bound: Wegen der 64-Bit-Problematik verwende ich Osmosis ohne die Clipping-Option idTrackerType. Dann wird als Default idTrackerType=Dynamic genommen und das bedeutet, dass Osmosis beim Clippen temporäre Daten in Temp-Files ablegt obwohl er die Daten spielend im Memory halten könnte. Das verursacht verd… viel IO. Mal sehen ob der Bug in osmosis 0.42 raus ist.


walter@wno-server:~$ ls -lah /tmp/af*
-rw-rw-r-- 1 walter walter  51M Feb 23 22:30 /tmp/afn5169826647196828359.tmp
-rw-rw-r-- 1 walter walter 323M Feb 23 22:36 /tmp/afn642703322552175748.tmp
-rw-rw-r-- 1 walter walter  84M Feb 23 22:31 /tmp/afn8186091037333075132.tmp
-rw-rw-r-- 1 walter walter 367M Feb 23 22:33 /tmp/afn822235863446617160.tmp
-rw-rw-r-- 1 walter walter 6,3M Feb 23 22:35 /tmp/afr2790118068294005220.tmp
-rw-rw-r-- 1 walter walter 1,8M Feb 23 22:31 /tmp/afr4147008938441278370.tmp
-rw-rw-r-- 1 walter walter 3,4M Feb 23 22:36 /tmp/afr7104361024340531822.tmp
-rw-rw-r-- 1 walter walter 1,2M Feb 23 22:30 /tmp/afr8558165384252636479.tmp
-rw-rw-r-- 1 walter walter 139M Feb 23 22:36 /tmp/afw2019786724539200888.tmp
-rw-rw-r-- 1 walter walter  23M Feb 23 22:30 /tmp/afw3870572578763475746.tmp
-rw-rw-r-- 1 walter walter  41M Feb 23 22:31 /tmp/afw430517774483349815.tmp
-rw-rw-r-- 1 walter walter 148M Feb 23 22:35 /tmp/afw5529171820357334263.tmp
walter@wno-server:~$ 

Nachtrag2: ist mit --bounding-box fertig und hat 20 Minuten gebraucht. Allerdings die 2. Methode “Erst clippen, dann mergen”.

Warum eigentlich diese Eile? Die Karten, die ich im Netz hab, werden maximal einmal täglich upgedated, da ist es egal, ob das Update in einer halben Stunde durchläuft oder 3 Stunden braucht. Insofern würde ich das Programm (z.B. Osmosis oder osmconvert) nicht unbedingt nach dessen Laufzeit auswählen - es gibt genügend andere, wahrscheinlich wichtigere Kriterien.

Ich hab trotzdem dein Beispiel mal auf meinem Server durchlaufen lassen. Das ist die Maschine, die die openptmap.org rendert (4 Kerne), also mit Walters Rechner nicht zu vergleichen.

$ ./osmconvert bayern.osm.pbf -o=1.o5m & ./osmconvert thueringen.osm.pbf -o=2.o5m & ./osmconvert sachsen.osm.pbf -o=3.o5m & ./osmconvert czech_republic.osm.pbf -o=4.o5m & time ./osmconvert 1.o5m 2.o5m 3.o5m 4.o5m -o=alles.pbf

Braucht ca. 2 Minuten.

Und als Variante mit Walters Poly-Datei:

$ ./osmconvert bayern.osm.pbf -o=1.o5m & ./osmconvert thueringen.osm.pbf -o=2.o5m & ./osmconvert sachsen.osm.pbf -o=3.o5m & ./osmconvert czech_republic.osm.pbf -o=4.o5m & time ./osmconvert 1.o5m 2.o5m 3.o5m 4.o5m -B=my.poly -o=alles.pbf

Dauert ungefähr 44 Sekunden.

Nö, runtime ist ein extrem wichtiges Auswahlkriterium:
a) Umweltschutz: Waram soll für die gleiche Aufgabe zehnmal soviel Energie verprutzelt werden?
b) Lebenszeit: Wenn Bernhard statt 20 min 2 min vor seinem Compi, ist das besser handlebar für ihn.

named pipes scheint es auch für Windows zu geben, allerdings gibt es wohl in der Defaultkonfig kein “mkfifo”, jenes müsste man sich noch per cygwin aut simile nachinstallieren.

Das Thema mit den multi-pipes wäre noch eine schöne wiki-Ergänzung (hint, hint :wink: )

Da habe ich wohl nen Fehler reingebracht, als ich die Parameter in Walters zweitem Vorschlag anpaßte…
Aber für ein Rechteck, bei dem exakt 4 Koordinaten genügen, ist so ne Datei schon arg aufwändig.
Wer hat sich eigentlich dieses Format ausgedacht? Ein Cobol-Programmierer? Oder Mumps-Programmierer? Ist ja ähnlich antediluvial wie BDT/GDT im Gesundheitswesen…

Marqss’ Variante mit der poly-Datei habe ich an Windows angepaßt (mal mit paralellem Abarbeiten, mal sequentiell mit START /B CMD /C)

ECHO %TIME%
SET OSMCONVERT="C:\Program Files (x86)\OpenStreetMap\OSMConvert\osmconvert.exe"
SET INPUTDIR=E:\Maps\Raw\
CALL %OSMCONVERT% %INPUTDIR%bayern.osm.pbf -o=%INPUTDIR%bayern.o5m
CALL %OSMCONVERT% %INPUTDIR%thueringen.osm.pbf -o=%INPUTDIR%thueringen.o5m
CALL %OSMCONVERT% %INPUTDIR%sachsen.osm.pbf -o=%INPUTDIR%sachsen.o5m
CALL %OSMCONVERT% %INPUTDIR%czech_republic.osm.pbf -o=%INPUTDIR%czech_republic.o5m
CALL %OSMCONVERT%  %INPUTDIR%bayern.o5m %INPUTDIR%thueringen.o5m %INPUTDIR%sachsen.o5m %INPUTDIR%czech_republic.o5m -B=E:\Maps\Development\Ski\areas.poly -o=%INPUTDIR%Mittelgebirge.osm.pbf
ECHO %TIME%

sie endet stets mit:

osmconvert Error: could not get 183500800 bytes of memory

Der letzte Aufruf an OSMConvert nach vorheriger Konvertierung genügt für das Hervorrufen des Fehlers - d.h. Probleme mit Zugriffen auf die konvertierten Dateien sind als Fehlerursache ausgeschlossen.
Lasse ich das Ausschneiden des gewünschten Bereiches weg, tritt kein Fehler auf.
Wenn ich dann mit Osmosis ausschneiden will, kracht Osmosis weg:

SCHWERWIEGEND: Thread for task 1-read-pbf failed
java.lang.OutOfMemoryError: Java heap space

Beide Fehlermeldungen sind eigentlich recht aufschlussreich!
Du hast schlicht einen kleineren Hauptspeicher zur Verfügung als von den Programmen vorausgesetzt oder angenommen wird.
Vielleicht musst du das mergen und zuschneiden doch auch sequentiell abarbeiten. Eventuell ist aber auch dein Polygon zu aufwendig. Interessant wären an dieser stelle auf jeden Fall mal die technischen Daten deines Rechners. 4 GB Ram oder mehr? 32 bit oder 64 bit und wieviel vom den Ram ist eigentlich noch frei und nicht durch andere Programme bereits belegt.

Moin Moin,

ne, das ist für Leute gedacht, die einen Thread richtig und vollständig lesen können :wink:

#!/bin/bash

# OSMembrane auto-generated pipeline for osmosis
# Name: 
# Date: Fri Feb 22 19:32:01 CET 2013
# Comment:
#
...

und

ok, hier einige Links:

Wenn es das Teil nicht gäbe, hätte ich nie was mit Named Pipes gemacht :wink:

Das Teil ist ziemlich alt und wird leider nicht mehr gepflegt. Es hat sogar (mindestens) 2 Bugs, mit denen ich ganz gut klarkomme:

  • wenn man einen --tee-change machen will (ja, sowas gibt es), generiert er das Kommando change-tee; das muss man dann halt im Script ändern.
  • wenn man Verbindungen zwischen den Boxes löscht und neu erstellen will, gibt es schon mal nen Runtime-Fehler. Da weiss anscheinend irgend ein Pointer nicht mehr, wohin er zeigen soll ;).
    Lösung: Abspeichern und neu Laden, dann gehts weiter.

Gruss
walter

wegen Java: wer osmosis benutzt, hat eh Java installiert. Und wenn das nicht von Oracle ist, gibt es auch keine Security-Leaks.

p.s. Die Bildchen hab ich nicht gemalt - das sind Screenshots. Alles klar?

Hatte und hab kein Problem.

Ubuntu, 2GB Memory, keinerlei Java-Optionen bzgl Memory: rennt

Poste doch bitte mal den aktuellen Script.

Gruss
walter

8 GB RAM unter Windows 7 (64bit). Und fast alles davon verfügbar.

Guten Morgen ihr! :slight_smile:

Ja, wirklich schade, dass OSMembrane zurzeit nicht gepflegt wird. Ich hoffe, es findet sich wieder jemand, der sich um das Programm kümmert.
Aber zu diesem Bug: Soweit ich weiß, wird Osmosis recht gut gepflegt, dort könnte man bestimmt sehr leicht einbauen, dass “change-tee” als inoffizielles Synonym für “tee-change” akzeptiert wird!

Klingt beides wirklich so, als hätte dein Windows ein Problem mit der Speicherverwaltung. :frowning: Der letzte Schritt mit dem Grenzpolygon sollte eigentlich nicht mehr als 1 oder 2 GB RAM brauchen.

Stimmt, wär sicher hilfreich. Als Linux-Anfänger hatte ich von den tollen Möglichkeiten auch keine Ahnung, bis ich dann mal durch Zufall drauf gestoßen bin. Muss mal schauen, wo man das am besten einbaut…

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

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:

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!

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.

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