Gelöst&Howto: osmconvert "verliert" ways beim schneiden von srtm-daten

Du meinst wahrscheinlich meine Patch, also “Thorsten” und nicht “Thomas” :wink:

Keine Ahnung warum der phyghtmap Author meine Patches geflissentlich ignoriert. Ich (und wohl auch andere) habe ihn mehrmals drauf aufmerksam gemacht.
Werde sehen das ich die Patches heute anpasse und meine --max-nodes Option in --max-way-nodes umbennen.

Thorsten

Hmm, wollte mal 1.25 ausprobieren – allerdings läuft das bei mir (wie auch 1.24) weder unter Win noch Opensuse (ohne patches - sourcecode selber kompiliert per python setup.py install) …
hat noch jemand das Problem??
Traceback (most recent call last):
File “C:\Program Files\python_2.7.2\Scripts\phyghtmap-script.py”, line 9, in
load_entry_point(‘phyghtmap==1.25’, ‘console_scripts’, ‘phyghtmap’)()
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.25-py2.7.egg\phyghtmap\main.py”, line 177, in main
processHgtFile(hgtDataFileName, opts)
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.25-py2.7.egg\phyghtmap\main.py”, line 130, in processHgtFile
elevations)
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.25-py2.7.egg\phyghtmap\osmUtil.py”, line 97, in writeXML
contourList = contourData.trace(elevation, points=0)
TypeError: ‘points’ is an invalid keyword argument for this function

dazu finde ich folgenden recht ähnlichen Bug:
http://code.google.com/p/dicompyler/issues/detail?id=39

— läuft etwa auf Windows wie Opensuse 11.4 die kaputte matplotlib??

Vom Programmautor habe ich folgende Rückantwort erhalten (Auszug):

“Ich werde mich demnächst mal der Sache mit der Einzeldatei annehmen.”

Gruß Klaus

Nop fragen.

Waere immer gnaz schoen, wenn Du Deine komplette Befehlszeile mit angeben wuerdest.
Dann muesten wir nicht immer soviel raten :wink:

1.25 laueft auf debian.
Abstuerze gibt z.B. dann, wenn man --max-nodes=250 (mit der THORSTENschen Intention )
absetzt.

Komplett:
c:\contourlines>“C:\Program Files\python_2.7.2\Scripts\phyghtmap.exe” --jobs=1 --osm-version=0.6 --area=5.56214:45.24627:16.68790:48.65879 --step=20 --output-prefix=alps --line-cat=500,100 --viewfinder-mask=1
found existing file hgt\VIEW1\N45E005.hgt.
found existing file hgt\VIEW1\N45E006.hgt.

hgt file hgt\VIEW1\N45E005.hgt: 3601 x 3601 points, bbox: (5, 45, 6, 46)
Traceback (most recent call last):
File “C:\Program Files\python_2.7.2\Scripts\phyghtmap-script.py”, line 9, in
load_entry_point(‘phyghtmap==1.24’, ‘console_scripts’, ‘phyghtmap’)()
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.24-py2.7.egg\phyghtmap\main.py”, line 172, in main
processHgtFile(hgtDataFileName, opts)
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.24-py2.7.egg\phyghtmap\main.py”, line 125, in processHgtFile
elevations)
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.24-py2.7.egg\phyghtmap\osmUtil.py”, line 97, in writeXML
contourList = contourData.trace(elevation, points=0)
TypeError: ‘points’ is an invalid keyword argument for this function

Passiert nicht bei phyghtmap Aufruf ohne commands (also ohne echte Konvertierung) - aber sonst immer

Die Kanaren laufen bei mir auf Fehler, genauer:
$ process_phyghtmap_data.pl lon*

process_phyghtmap_data - Process phyghtmap Data, Release 0.1.0 (2011/12/27)

Error: Input file lon-17.00_-16.00lat27.00_28.00_srtm3.osm probably not a phyghtmap data file.

$ cat lon-17.00_-16.00lat27.00_28.00_srtm3.osm

<?xml version="1.0" encoding="utf-8"?> $

Nach weg-moven geht’s:
$ osmconvert --out-statistics phyghtmap_result.osm
lon min: -18.1616667
lon max: -12.0000000
lat min: 27.0000000
lat max: 29.4183333
nodes: 2022693
ways: 47457
relations: 0
node id min: 10000000
node id max: 12070148
way id min: 10000154
way id max: 12070149
keyval pairs max: 3
noderefs max: 10299
$

Mit Höhenlinien wirken die Kanarischen Inseln m.E. gleich viel “plastischer”:

Das (Beta-)Utility kommt wohl mit leeren Dateien nicht klar - schaue ich mir mal an.

Klaus

Hallo,

sollte man den Thread über phygthmap langsam abrennen oder einen neuen aufmachen?

Ich bin mit dem Author jetzt in Kontakt und dabei, meine Patches upstream rein zu bekommen. Er ist von dem plötzlichen Intresse, Feedback und Patches etwas erschlagen :wink:

Zu phygthmap und Problemen auf openSUSE: Ich werde es auf Arbeit versuchen mal nachzuvollziehen und dann mit den Verantwortlichen ein Buero weiter reden :smiley:

Thorsten

extremecarver, der alte Batzi ! :slight_smile:

Hab’ meinem armen kleinen Netbook jetzt die volle 17 GB gegeben :wink:


$ time phyghtmap --jobs=1 --osm-version=0.6 --area=5.56214:45.24627:16.68790:48.65879 --step=20 --output-prefix=alps --line-cat=500,100 --viewfinder-mask=1
<snip>
real    195m31.245s
user    184m14.111s
sys     4m41.218s

So far, so good!


$ time process_phyghtmap_data.pl alps*
<snip>
writing XML header ...
copying nodes from alps_lon5.56_6.00lat45.25_45.43_view1.osm (10000000) ...
copying nodes from alps_lon11.00_12.00lat46.00_46.06_view1.osm (100019256) ...

Böse Vorahnung, hier wird doch nicht nach 8 Stellen gewrappt?!


copying nodes from alps_lon14.00_15.00lat47.88_48.00_view1.osm (202686253) ...
copying nodes from alps_lon15.00_16.00lat47.00_47.12_view1.osm (203562848) ...
copying nodes from alps_lon7.00_8.00lat45.34_45.43_view1.osm (20376286) ...
copying nodes from alps_lon15.00_16.00lat47.12_47.25_view1.osm (204035536) ...
copying nodes from alps_lon15.00_16.00lat47.25_47.38_view1.osm (204728919) ...

Oh weh!


$ time osmconvert --out-statistics phyghtmap_result.osm 
osmconvert Warning: wrong sequence at node 106634514
osmconvert Warning: next object is node 10644806
^C

Und Abbruch :wink:

@kellerma

Kannst ja nochmal das Script auf meiner Seite versuchen, hab’s mal angepasst wegen der Sortierung und Anzeige der Reihenfolge.

Grüße
Mario

Hallo Mario,

yep, bei meinen Mini-Example
phyghtmap -a 10.98:48.98:11.02:49.02 --osm-version=0.6
schaut es jetzt besser aus :slight_smile:

Dein “altes” war heute der “Perl-Fraktion” überlegen, denn
$ osmconvert --out-statistics topo.osm
lon min: 5.5616667
lon max: 16.6883333
lat min: 45.2458333
lat max: 48.6591667
nodes: 206545448
ways: 878219
relations: 0
node id min: 10000000
node id max: 217423665
way id min: 10000004
way id max: 217423666
keyval pairs max: 3
noderefs max: 52003

es ist durchgelaufen :slight_smile:

Einerseits ist das gut, andererseits weiß ich jetzt natürlich nicht, warum es damals bei extremecarver nicht geklappt hat.
Mmmh, …

sehr schön dass die patches dann wohl innerhalb der nächsten Wochen integriert werden. Mir ist heute leider beim upgraden auf opensuse 12.1 der Server böse abgeschmiert - daher bin ich seitdem zu nichts mehr gekommen. Hab noch immer nicht wieder alles am laufen da sich die Backups nicht alle fehlerfrei einspielen ließen…

Auf opensuse 12.1 bekomme ich phyghtmap >=1.24 aber genausowenig zum laufen (selber Fehler) wie unter Windows 7 x64 oder opensuse 11.4 (und das opensuse 12.1 ist grad frisch aufgesetzt, da kann es nicht an irgendwelchen alten Sachen liegen…) -

Und evtl liegt bei mir der Fehler auch daran dass das bash skript mit phyghtmap 1.23 inkompatibel ist ??? – 1.24 oder 1.25 bekomme ich ja leider nicht zum laufen. Wenn ich die Daten direkt an mkgmap ohne sortieren usw geschickt hab- hat es ja bei mir immer funktioniert.

@kellerma,

ich habe heute erst eine neue Version eingestellt, die ich meinte.

Der Versuch von vor paar Tagen lief mit kleinen Dateien, die zu schnell erzeugt waren (gleicher Zeitstempel). Das kann auch bei großen Gebieten mit nur sehr wenigen Höhenlinien in einer Kachel oder bei sehr schmalen Kacheln mit x.9- bzw. x.1-Grad-Grenzen passieren, weswegen ich jetzt statt der Erstellungs-Zeit die erste vorkommende Node-ID zum Sortieren auswerte. Das dauert aber zusätzliche Sekunden (bis zur halben Minute für Mitteleuropa). Was ich jetzt besser finde: Er werden nicht die geschriebenen Dateien ausgegeben, sondern zur Kontrolle der Reihenfolge die erste Node- bzw. Way-ID der aktuell übertragenen Datei.

Grüße
Mario

Hi,

das wäre möglich. Ich weiß nicht, ab genau welcher Version Phyghtmap direkt in OSM-0.6 schreiben kann. Da hatte ich im Script nachgebessert (Header: osm version auf 0.6) - ließe sich aber mühelos wieder einfügen. Ich kopiere es aus der History hier hin.

Ach ja: Nicht vergessen, den Schalter “–versions-Tag=1” bei Phyghtmap mit reinzunehmen. Oder eben doch gleich den Splitter auf die topo.osm ansetzen, aber dabei version 0.5 lassen:
bei “cat $onefile | head -n 2 | sed ‘s/=“0.5”/=“0.6”/’ > topo.osm” den sed-Befehl aus der Pipe nehmen.

#/bin/sh
cd maketopo
onefile=$( ls lonlat.osm | head -n 1 )
cat $onefile | head -n 2 | sed ‘s/=“0.5”/=“0.6”/’ > topo.osm
bounds="lon([0-9.])_([0-9.])lat([0-9.])_([0-9.])."
minlon=$( ls lon
lat*.osm | sed “s/$bounds/\1/” | sort -n | head -n 1 )
maxlon=$( ls lonlat.osm | sed “s/$bounds/\2/” | sort -n | tail -n 1 )
minlat=$( ls lonlat.osm | sed “s/$bounds/\3/” | sort -n | head -n 1 )
maxlat=$( ls lonlat.osm | sed “s/$bounds/\4/” | sort -n | tail -n 1 )
echo “<bound box="$minlat,$minlon,$maxlat,$maxlon" origin="SRTM3-VIEW3"/>” >> topo.osm
for file in lonlat.osm ; do
echo “Nodes $file => topo.osm”
cat $file | grep ‘^<node id=’ >> topo.osm
done
for file in lonlat.osm ; do
echo “Ways $file => topo.osm”
cat $file | grep ‘^<way id=’ >> topo.osm
done
cat $onefile | tail -n 1 >> topo.osm
echo -n “Enter-Taste”
read REPLY

Nein osm-0.6 kann phyghtmap schön seit 1.21 schreiben und benutze ich auch… - dein neuestes bash will bei mir gar nicht (läuft dafür aber innerhalb von 3min durch):
openSUSE-121-64-minimal:/home/contourlines # bash merge_osm_user.sh
Erstelle nach ID sortierbare Datei-Liste…\n
Nodes ab 34342532 => topo.osm

Ways ab 34342550 => topo.osm

Eck-Koordinaten: alps_45.25,alps_10.00,alps_46.00,alps_11.00\n
Enter-Taste

Dann fertig und topo.osm mit 391.4MB erstellt (anstelle 17GB). Scheint evtl auch irgendwie an den Daten zu ersticken?? Ausserdem passen die Koordinaten nicht überein!
(phyghtmap command weiterhin “phyghtmap --area=5.5:45.2:16.7:48.7–jobs=1 --max-nodes=250 --osm-version=0.6 --start-node-id=10000000 --step=20 --output-prefix=alps --line-cat=500,100 --viewfinder-mask=1” — ist halt Version 1.23 samt patches von kukuk ---- werde morgen mal ohne patches von kukuk das ganze durchlaufen lassen, dann halt leider auch ohne max-nodes=250)

Edit: Mir scheint eher so, dass dein neuestes bash bei mir einfach nur das erste Tile einliest und wieder ausgibt - die größe stimmt überein. Keine Ahnung was da falschläuft…

Phyghtmap 1.25-1 schmiert bei deiner Befehlszeile bei mir auch ab. Nach Entfernen von --max-nodes=250 läufts. Da muss der Fehler liegen. Ist 250 zu klein? Explizit 1000000 angegeben - läuft.

Nein. --max-nodes hab ich sogar 1000000000 angegeben bzw auch komplett weggelassen. Fehler bleibt immer identisch. Habs ja mit 1.24 genauso probiert (ungepatcht) – das akzeptiert ja nicht einmal max-nodes…

Ich sehe oben an den Ausgaben mit “\n”, was eine extra Leerzeile ausgeben müsste, dass etwas bei der Interpretation nicht stimmt. Ich gehe davon aus, dass sich meine Dash etwas anders als bei Dir verhält. (Script vielleicht auf Bash umgestellt?) Gerade bei den Kleinigkeiten gibt es da doch paar Unterschiede. Vielleicht sollte ich es auch mit der Bash versuchen, die sollte bei jedem Linux drauf sein.

ups, versuche es gerade mit “sh merge_osm_user.sh” anstelle bash merge… muss sagen dass ich alle skripte (bis auf perl) zum mergen bisher mit bash aufgerufen hab, weil ich davon ausging dass es mehr kann wie sh… mal schauen was jetzt passiert (Daten hab ich jetzt mal mit ungepatchter 1.23 erstellt).

… selbes Problem auch unter Opensuse sh - siehe Output:
openSUSE-121-64-minimal:/home/contourlines # bash merge_osm_user.sh
Erstelle nach ID sortierbare Datei-Liste…\n
Nodes ab 34410538 => topo.osm

Ways ab 34410556 => topo.osm

Eck-Koordinaten: kaputt_45.25,kaputt_10.00,kaputt_45.62,kaputt_11.00\n
Enter-Taste
openSUSE-121-64-minimal:/home/contourlines # sh merge_osm_user.sh
Erstelle nach ID sortierbare Datei-Liste…\n
Nodes ab 34410538 => topo.osm

Ways ab 34410556 => topo.osm

Eck-Koordinaten: kaputt_45.25,kaputt_10.00,kaputt_45.62,kaputt_11.00\n
Enter-Taste
openSUSE-121-64-minimal:/home/contourlines #