Naja, der Compile Server steht in der Schweiz, sind auch alle Daten runtergeladen. Europa mit jobs=4 kompilieren Crasht jedoch konsistent. Lasse es gerade mal mit jobs=1 durchlaufen - so kann ich zumindest evtl sehen an welcher .hgt Datei der Crash liegt.
Der Crash war auf jeden Fall nach neuem phyghtmap Download vom Server direkt dann gegessen. Bzw so sicher bin ich nicht, da ich die Indexdateien dann halt lokal am Laptop berechnet hab, und dann auf den server zum berechnen kopiert habe (und überprüft - weil ich hier krassen packet loss hab).
jobs=>1 sollte man derzeit wohl noch als Experimentiell ansehen — zumindest weil man keine vernünftigen Crashlogs bekommt.
Jobs>1 dauert derzeit sogar länger als jobs=1. Macht auch irgendwie keinen Sinn, weil erst die aktuelle .hgt fertig verarbeitet werden muss bevor das Programm weiß, mit welcher ID es dann weitermachen kann.
$ time phyghtmap --area=16:45.7:18.9:48 --jobs=2 --line-cat=500,100 --osm-version=0.6 --start-node-id=300000000 --step=20 --viewfinder-mask=3
<snip>
real 2m17.245s
user 3m58.267s
sys 0m4.964s
$ time phyghtmap --area=16:45.7:18.9:48 --jobs=1 --line-cat=500,100 --osm-version=0.6 --start-node-id=300000000 --step=20 --viewfinder-mask=3
<snap>
real 2m35.576s
user 2m30.325s
sys 0m3.408s
Ich wußte, dass ich etwas verkehrt mache
Mein Intel Atom N450 hat zwar 64 Bit und wird unter Linux mit 2 CPUs angezeigt, ist aber nur HyperThreading
und kein DualCore.
Daher verwundert es nicht, dass er mit jobs=2 zwar schneller (2:15 min zu 2:30 min) als jobs=1 ist, aber dafür auch beide “CPUs” fast je 2 min 100% Last hatten (= knapp 4 min CPU-Zeit).
Interessant. Vieleicht findet sich ja jemand, der die Tests mit richtigen Kernen nachstellt. Bei meinem Versuch mit etwas kleinerem Bereich war das Verhältnis 30:38 sec. bei 1:2 Kernen, also zugunsten der Verwendung von einem Kern, mehrfach getestet.
Phyghtmap wartet, bis eine .hgt fertig ist, bevor ein weiterer Kern die Arbeit fortsetzt. Wie sonst kann es sein, dass die IDs lückenlos (ohne den Bedarf vorher zu berechnen oder eine Sicherheitslücke zu lassen) fortgeschrieben werden? Hyperthreading dagegen arbeitet eher wie ein einzelner Kern, macht diesen jedoch durch Auslagerung von “Rechen”-Aufgaben, soweit dies möglich ist, etwas effektiver. So kommt die Umkehrung zwischen beiden verschiedenen Systemen zustande.
Vielleicht wird ja der Bedarf während der Erstellung auf einem Kern parallel auf dem zweiten Kern vorausberechnet, dann liefe die Erzeugung aber genauso schnell wie wenn man nur einen Kern verwendet und diese Vorausberechnung nicht nötig ist. Effektiv wird das dann erst ab 3 Kernen.
Wenn Du genau hinschaust, gibt es einen Unterschied in der Ausgabe bei “jobs=1” und “jobs=2/3…” nämlich
Computing hgt/SRTM3/N47E018.hgt
…
Computing hgt/SRTM3/N47E017.hgt
etc.
Das schaut mir schon so aus, als würde hier Node/Ways vorrausberechnet.
Jenes kostet etwas Zeit und vermutlich ist deshalb bei Dir dieser “Overhead” größer als der anschließende
“gain” durch die Doppel-CPU.
Vielleicht solltest Du mal einen größeren Ausschnitt nehmen, an dem Deine Kiste mehrere Minuten zu knappern
hat. Vielleicht kehrt sich dann die Sache um
Aha, ich hab’s. Schön auf beide Kerne gleichzeitig verteilen tut er nur, wenn man die 1°-Kacheln als Ergebnis will. Bei --max-nodes-per-tile=0 (alles in eine Datei) wechseln sich die Kerne mehr oder weniger ab.
Hatte jetzt 22 sec. gegenüber den oben erwähnten 38. Aber die Geschwindigkeit ist ja bei der Einmalerstellung nicht so wichtig.
Sowohl bei der “Multi-Ausgabe” als auch “Singe-Datei” sind die Dateien zwar jeweils gleich groß bei jobs=1 und jobs>1,
aber die nodes selbst sind anders sortiert.
Also bei mir lief Europe auf jobs=1 nun problemlos durch (gut 2 Stunden auf i7). jobs=4 crashte… – das runterladen der srtm/viewfinders Dateien dauert aber erheblich länger… zumindest aus phyghtmap heraus, manuell geht es da wenn man parallel downloaded schon deutlcih schneller, aber wohl auch mindestens um die 1-2 Stunden…
Bei den SRTM-Daten konnte mir bisher noch keiner eine Abweichung von mit phyghtmap generierten Daten zeigen. Im Gegensatz zu srtm2osm ist da phyghtmap von Haus aus besser.
Bei den Ferranti-Daten gibt es Behauptungen, das sie um 12m Abweichen. Aber auch da habe ich noch kein Beispiel gesehen.
direkt am Übergang von VIEW zu SRTM bei 48° gibt es einen sichtbaren Versatz in Ost-West-Richtung - gleiche Höhenlinien stoßen dort nicht aneinander. Welche Datenherkunft da die genauere ist interessiert mich nicht so sehr, weil die Genauigkeit über größere Bereiche sowieso schwankt. Eine Korrektur anhand eines Bezugspunktes schafft anderenorts Ungenauigkeiten, und solange die Gipfel innerhalb der höchsten Höhenlinie liegen ist es ok. Und das ist bei den SRTM- UND Viewfinder-Daten der Fall.
Zu den polygon-boundaries: Ich habe zum Testen die polygon-Definitionen aus http://download.geofabrik.de/clipbounds/clipbounds.tgz benutzt. Damit kommt der Parser zurecht, ich weiß aber nicht, was es da draußen noch für Formate gibt. Wie komplex die Polygone sein dürfen, weiß ich nicht, ich vermute aber, dass phyghtmap in der Hinsicht recht anspurchslos sein sollte. Die Routine zur Überprüfung, ob Punkte inner- oder außerhalb des Polygons liegen, kommt aus der matplotlib, führt also keine neue Anhängigkeit ein. Es sei gesagt, das die Verarbeitungszeit mit der Komplexität des Polygons steigt.
Zum pbf-Output: Es wird zusätzlich python-protobuf benötigt. Das gibt es als Paket in allen größeren Linux-Distributionen. Für andere Systeme gibt es die Quellen auf python.org. Ich möchte dazu auf die phyghtmap-Homepage verweisen. phyghtmap läuft jedoch auch ohne python-protobuf, dann eben ohne pbf-Output. Das Erzeugen von pbf-Dateien nimmt je nach Maschine zwei- bis dreimal soviel Zeit in Anspruch wie das Erzeugen von unkomprimiertem OSM XML. Der Speicherbedarf hingegen sinkt dramatisch (etwa ein Viertel von mittels --gzip=9 erzeugtem gegzipptem OSM XML).
irgendwas muss schiefgelaufen sein. Selbst ohne Optionen (oder nur “–help”) und mit installiertem python-protobuf bricht das Programm mit folgender Fehlermeldung ab:
Das Problem ist genau, was die Fehlermeldung sagt, nur dass die vielleicht missverständlich ist. osmconvert kann mit latitude offsets (die Teil der pbf-Spezifikation sind) nicht umgehen (hier ein Auszug aus dem Quelltext von osmconvert):
Ich kann phyghtmap zwar so ändern, dass pbf von osmconvert gelesen werden kann (latitude offset und longitude offset auf 0 setzen und das erste Element der lat bzw. lon Listen im DenseNodes auf den entsprechenden Wert setzen). Das eigentliche Problem ist aber, dass osmconvert die pbf-Spezifikation nur unvollständig implementiert.
Ich werde mich wohl leider erst morgen darum kümmern können und eine Version 1.41 veröffentlichen.
Bis dann,
Adrian
P.S.: Ich hatte nur mit JOSM getestet, und das kann mit latitude und longitude offsets umgehen.
Wenn es darum ging die PBF-Implementierung zu testen, dann wäre osmosis geeigneter.
Ich kann osmconvert leider nicht verwenden, da es nur eine PBF-Datei verarbeiten kann.
Vielleicht liest Markus (der Autor von osmconvert) mit und äußert sich mal …