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”
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:
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.
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.
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.
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 )
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…
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.
Wenn es das Teil nicht gäbe, hätte ich nie was mit Named Pipes gemacht
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?
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. 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.
*
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.
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.
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