You are not logged in.

#1 2012-01-22 20:49:48

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,241
Website

phyghtmap - NASA SRTM -> OSM xml translator

Zur Info: Das Programm "phyghtmap" zur Erstellung von Höhenlinien ist in der Version 1.30 erschienen.

Link: http://katze.tfiu.de/projects/phyghtmap/index.html

Ich möchte mich an dieser Stelle ausdrücklich beim Programmautor für die vielen Erweiterungen bedanken.

Gruß Klaus

Offline

#2 2012-01-22 21:03:34

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

toc-rox wrote:

Ich möchte mich an dieser Stelle ausdrücklich beim Programmautor für die vielen Erweiterungen bedanken.

Und bei Meister Ku(c)ku(c)k erst wink

EDIT:
Ah, die "single file" Option gibt's jetzt auch via "--max-nodes-per-tile=0". Cool!

Last edited by kellerma (2012-01-22 21:15:13)

Offline

#3 2012-01-22 21:58:03

kukuk
Member
Registered: 2011-09-13
Posts: 225
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

Ich bin baff, das sieht ja so aus als wenn ich alle meine Patches jetzt droppen kann big_smile

Ich werde mir es morgen mal näher ansehen.

Thorsten

Offline

#4 2012-01-26 03:59:18

extremecarver
Member
Registered: 2008-09-18
Posts: 404
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

Funtioniert "--max-nodes-per-tile=0" als wirkliches Einzelfile - oder als ein Tile per SRTM/Viewfinders Tile?

Wenn ja, dann wäre jetzt nur noch cool, wenn man direkt boundary tiles anstelle Koordinaten, und pbf anstelle einfachem osm output wählen könnte....
vor allem da osmconvert nur mit sehr gering detaillierten boundary files klarkommt. Hat evtl jemand ein boundary file welches osmconvert für Norwegen oder Schweden akzeptiert???

Last edited by extremecarver (2012-01-26 04:01:35)


OSM Maps for Mtbikers and Hikers, OSM Karten fuer Mtbiker und Wanderer --> http://openmtbmap.org
OSM Maps for racing and casual cycling - für Rennradfahrer und Freizeitradfahrer --> http://www.velomap.org

Offline

#5 2012-01-26 10:03:12

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

extremecarver wrote:

Funtioniert "--max-nodes-per-tile=0" als wirkliches Einzelfile - oder als ein Tile per SRTM/Viewfinders Tile?

Wenn ja, dann wäre jetzt nur noch cool, wenn man direkt boundary tiles anstelle Koordinaten, und pbf anstelle einfachem osm output wählen könnte....
vor allem da osmconvert nur mit sehr gering detaillierten boundary files klarkommt. Hat evtl jemand ein boundary file welches osmconvert für Norwegen oder Schweden akzeptiert???


Soweit ich das sehen konnte, ja, nur ein einziges file.
Wichtig ist, das jetzt alle files richtig sortiert vorliegen und das, glaube ich, war auch ein showstopper fuer
osmconvert fürs Polygonausschneiden. Dessen Grenze fuer polys liegt bei 40000 (?) nodes, dies sollte selbst fuer skandinavien machbar sein wink

Last edited by kellerma (2012-01-26 12:34:07)

Offline

#6 2012-01-26 13:44:49

extremecarver
Member
Registered: 2008-09-18
Posts: 404
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

Ja, aber wo gibt es Polys unter 4000 Nodes? Die welche geofabrik verwendet haben deutlich mehr (400KB)....
Und über Europa reden wir da noch gar nicht....


OSM Maps for Mtbikers and Hikers, OSM Karten fuer Mtbiker und Wanderer --> http://openmtbmap.org
OSM Maps for racing and casual cycling - für Rennradfahrer und Freizeitradfahrer --> http://www.velomap.org

Offline

#7 2012-01-26 13:55:24

laufkaefer
Member
Registered: 2009-09-25
Posts: 91

Re: phyghtmap - NASA SRTM -> OSM xml translator

kellerma wrote:

Wichtig ist, das jetzt alle files richtig sortiert vorliegen und das, glaube ich, war auch ein showstopper fuer
osmconvert fürs Polygonausschneiden.

nee, osmconvert schneidet auch unsortierte daten.

Offline

#8 2012-01-26 20:10:56

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

extremecarver wrote:

Ja, aber wo gibt es Polys unter 4000 Nodes? Die welche geofabrik verwendet haben deutlich mehr (400KB)....
Und über Europa reden wir da noch gar nicht....

Ich schneide (für mich smile ) aus mittelfranken.osm.pbf die Städte aus, Nürnberg als größte mit Stadtgrenze admin_level=6 hat ca. 5000 Punkte und
die Grenze von osmconvert liegt ja bei 40 000, geht also noch.

http://downloads.cloudmade.com/europe/n … orway.poly
$ wc -l norway.poly
74862 norway.poly

Ok, hier bin ich bei Dir, aber

http://download.geofabrik.de/clipbounds/clipbounds.tgz :
europe.poly   21 points
europe/norway.poly    ca. 130 points
europe/sweden.poly   ca. 150 points

http://downloads.cloudmade.com/europe/europe.poly   ca. 75 points
http://downloads.cloudmade.com/europe/w … rland.poly   ca. 1520 points

Last edited by kellerma (2012-01-26 20:17:14)

Offline

#9 2012-01-27 00:14:36

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

Ergänzung:

Das hört sich auch ganz interessant an:
https://oegeo.wordpress.com/2011/11/05/tutorial-poly/
so dass
    * komplexes Admin_level-Polygon aus planet/europe
    * anschließend Vereinfachung per qgis+plugin
    * benutzen fürs auschneiden mit osmconvert
gangbar ist (?)

Die dort erwähnten world_borders sollten sich per
    $ python ogr2poly.py TM_WORLD_BORDERS-0.3.shp
direkt verwenden lassen bis auf
    56525 TM_WORLD_BORDERS-0.3_023.poly

Die aus den shapes genierten Polys von
    http://www.gadm.org
müssten wohl auch vereinfacht werden:
    231004 NOR_adm0_0.poly

Last edited by kellerma (2012-01-27 00:51:11)

Offline

#10 2012-01-27 14:44:44

extremecarver
Member
Registered: 2008-09-18
Posts: 404
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

okay, da scheinen meine alten Polys von Geofabrik veraltet. Da waren Schweden wie Norwegen, oder auch Europa deutlich über 50.000 Punkte....

Last edited by extremecarver (2012-01-27 14:45:43)


OSM Maps for Mtbikers and Hikers, OSM Karten fuer Mtbiker und Wanderer --> http://openmtbmap.org
OSM Maps for racing and casual cycling - für Rennradfahrer und Freizeitradfahrer --> http://www.velomap.org

Offline

#11 2012-01-28 04:28:05

extremecarver
Member
Registered: 2008-09-18
Posts: 404
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

Edit: hat sich erledigt. Beim kopieren des phyghtmap Ordners war eine Datei kaputtgegangen, dann zig Fehlermeldungen. Bin derzeit in China und Internet kommt einem hier noch vor wie in der Steinzeit. Pings über 500ms nach Europa/USA wenn alles gut geht....

Last edited by extremecarver (2012-01-28 07:05:10)


OSM Maps for Mtbikers and Hikers, OSM Karten fuer Mtbiker und Wanderer --> http://openmtbmap.org
OSM Maps for racing and casual cycling - für Rennradfahrer und Freizeitradfahrer --> http://www.velomap.org

Offline

#12 2012-01-28 08:26:12

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

extremecarver wrote:

Edit: hat sich erledigt. Beim kopieren des phyghtmap Ordners war eine Datei kaputtgegangen, dann zig Fehlermeldungen. Bin derzeit in China und Internet kommt einem hier noch vor wie in der Steinzeit. Pings über 500ms nach Europa/USA wenn alles gut geht....

Da muss man nicht in China sein, das geht auch in good ol' germany:
$ host www.viewfinderpanoramas.org
www.viewfinderpanoramas.org has address 178.239.164.129
;; connection timed out; no servers could be reached
$

Deine - jetzt gelöschte - Fehlermeldung via getaddrinfo ist das gleiche,
evtl. in /etc/hosts reinschreiben aut simile.

Offline

#13 2012-01-28 15:31:41

extremecarver
Member
Registered: 2008-09-18
Posts: 404
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

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.


OSM Maps for Mtbikers and Hikers, OSM Karten fuer Mtbiker und Wanderer --> http://openmtbmap.org
OSM Maps for racing and casual cycling - für Rennradfahrer und Freizeitradfahrer --> http://www.velomap.org

Offline

#14 2012-01-28 16:57:05

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

Habe festgestellt, dass meine (aelteren) Index-Dateien teilweise defekt sind.
Derzeit habe ich (fuer Europa):
hgtIndex_3.txt  md5sum: 988be9eeb1475841bacfa13b6e6ec8c2 ; 224745 Byte
viewfinderHgtIndex_1.txt  md5sum: 0d919f3d161c885fa8d663b61b28b638  ; 2584 Byte
viewfinderHgtIndex_3.txt  md5sum: 71360f280735c047f51e16fd91876b4d  ; 55331 Byte

Offline

#15 2012-01-28 19:35:50

Garmin-User
Member
Registered: 2009-10-01
Posts: 645

Re: phyghtmap - NASA SRTM -> OSM xml translator

extremecarver wrote:

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.

Grüße
Mario

Offline

#16 2012-01-28 20:07:59

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

Garmin-User wrote:

Jobs>1 dauert derzeit sogar länger als jobs=1.

So so.

$ 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 wink

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).

Last edited by kellerma (2012-01-28 20:42:54)

Offline

#17 2012-01-28 22:33:30

Garmin-User
Member
Registered: 2009-10-01
Posts: 645

Re: phyghtmap - NASA SRTM -> OSM xml translator

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.

Grüße
Mario

Offline

#18 2012-01-28 23:03:55

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

Garmin-User wrote:

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?

Mmmh,

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 wink

Offline

#19 2012-01-28 23:22:25

Garmin-User
Member
Registered: 2009-10-01
Posts: 645

Re: phyghtmap - NASA SRTM -> OSM xml translator

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. smile Aber die Geschwindigkeit ist ja bei der Einmalerstellung nicht so wichtig.

Grüße
Mario

Offline

#20 2012-01-28 23:54:22

kellerma
Member
Registered: 2010-07-18
Posts: 1,623

Re: phyghtmap - NASA SRTM -> OSM xml translator

Garmin-User wrote:

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.

Ja, das klingt plausibel. Und wenn man sich die CPU-Zeiten (jetzt für eine einzige Ausgabedatei) anschaut, dürfte das stimmen:

$ 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 --max-nodes-per-tile=0
real    2m56.006s
user    2m54.927s
sys     0m4.888s

$ 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 --max-nodes-per-tile=0
real    2m26.956s
user    2m23.909s
sys     0m2.740s

=> SingleFile SingleCore, MultipleFile MultipleCore wink

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.

Offline

#21 2012-01-29 03:42:28

extremecarver
Member
Registered: 2008-09-18
Posts: 404
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

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...


OSM Maps for Mtbikers and Hikers, OSM Karten fuer Mtbiker und Wanderer --> http://openmtbmap.org
OSM Maps for racing and casual cycling - für Rennradfahrer und Freizeitradfahrer --> http://www.velomap.org

Offline

#22 2012-01-30 09:51:02

toc-rox
Member
From: Münster
Registered: 2011-07-20
Posts: 2,241
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

Bezüglich der Korrekturparameter (--corrx, --corry) würden mich folgende Punkte interessieren:
- Welches wären geeignete Korrekturfaktoren für Deutschland ?
- Welches wären geeignete Korrekturfaktoren für die Alpen ?
- Ist die Anwendung der Korrekturparameter auch bei Mischung von SRTM- und Ferranti-Daten sinnvoll ?

Gruß Klaus

Offline

#23 2012-01-30 09:53:27

kukuk
Member
Registered: 2011-09-13
Posts: 225
Website

Re: phyghtmap - NASA SRTM -> OSM xml translator

Hallo,

toc-rox wrote:

Bezüglich der Korrekturparameter (--corrx, --corry) würden mich folgende Punkte interessieren:
- Welches wären geeignete Korrekturfaktoren für Deutschland ?
- Welches wären geeignete Korrekturfaktoren für die Alpen ?
- Ist die Anwendung der Korrekturparameter auch bei Mischung von SRTM- und Ferranti-Daten sinnvoll ?

Gruß Klaus

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.

Thorsten

Offline

#24 2012-01-30 14:44:15

Garmin-User
Member
Registered: 2009-10-01
Posts: 645

Re: phyghtmap - NASA SRTM -> OSM xml translator

kukuk wrote:

Bei den Ferranti-Daten gibt es Behauptungen, das sie um 12m Abweichen. Aber auch da habe ich noch kein Beispiel gesehen.

Hallo Thorsten,

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.

Grüße
Mario

Offline

#25 2012-02-02 23:23:31

panarchos
Member
Registered: 2012-02-02
Posts: 9

Re: phyghtmap - NASA SRTM -> OSM xml translator

extremecarver wrote:

Wenn ja, dann wäre jetzt nur noch cool, wenn man direkt boundary tiles anstelle Koordinaten, und pbf anstelle einfachem osm output wählen könnte....

Ich habe das eingebaut.  Es gibt jetzt Version 1.40 (http://katze.tfiu.de/projects/phyghtmap).

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).

Viele Grüße,
        Adrian

Last edited by panarchos (2012-02-02 23:25:06)

Offline

Board footer

Powered by FluxBB