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

Communities Deutschland (Germany)
132

Hallo Klaus,

sehr schön, geht ab wie eine Rakete :slight_smile:

Der Loop bei meinen skript war sehr “clever”, richtig reingeswappt.
Daher umgeschwenkt auf


osmconvert lon*.osm --drop-nodes --out-o5m > w.o5m 2> /dev/null
osmconvert lon*.osm --drop-ways --out-o5m > n.o5m 2> /dev/null
osmconvert n.o5m w.o5m > all.osm

Braucht aber immer noch 2x so lang wie Deine perl-Variante.

133

Tja, das hat er leider uns nicht mitgeteilt, der liebe, gute extremecarver :wink:

Wir können aus seinen posts nur vermuten, dass es etwas in der Art


$ phyghtmap --area=5.5:45.2:16.7:48.7 --gzip --jobs=1 --max-nodes=250 --osm-version=0.6 --start-node-id=10000000 --step=20 --viewfinder-mask=1

war.
Meinem armen, kleinen Netbook (1/12 RAM von extremecarvers Kiste) wollt’ ich die 18 GB (oder so) nicht antun und hab’ mich so auf die Hochalpen beschränkt:


phyghtmap --area=6:44:9:47 --jobs=1 --osm-version=0.6 --step=20 --viewfinder-mask=1

Das Perl-Skript von Klaus bzw. das Shell-Skript von Mario generieren (gleichschnell :slight_smile: aus den 103 osm-Dateien
jeweils ein ca. 6 GB große osm-file. Die Sortierung hab’ ich geprüft wie folgt:
osmconvert --out-statistics phyghtmap_result.osm
bzw.
osmconvert --out-statistics topo.osm
In beiden Fällen gab es keine “wrong order/wrong sequence”-Warnung. Dann für beide Fälle
problemlos jeweils ein pbf generiert ( 5.8 GB → 148 MB !) und aus jenen per “omsconvert -B=geneve.poly …”
Genf extrahiert ohne Fehlermeldung und dieses kurz in JOSM angeschaut.
splitter/mkgmap wurde nicht gestestet, da nicht der Garmin-Fraktion angehörend :wink:

Denke nicht, dass von 6 GB auf 18 GB sich etwas grundsätzlich ändert, so vermute ich den Fehler woanders.

Debian 6, phyghtmap 1.24 (ohne patches)

EDIT:
Nett wäre es, wenn phyghtmap einen Parameter “–single-file” hätte, bei welchem es eine Art “phyghtmap_result.osm”
generieren würde, indem es 2 temporäre Dateien mit nur ways resp. nur nodes benutzt und jene am Schluß konkateniert.
Dann bräuchte man keine “merge-scripte” mehr und osmconvert könnte das “singe-file” sehr platzsparend nach
pbf konvertieren, da sich in diesem Format die Höhendaten extrem gut packen lassen, besser als mit gzip.

134

Über diese Aussage bin ich immer wieder gestolpert. Experimentieren ergab, wenn man unsortierte Daten verwendet,
braucht osmconvert 10x so lang beim pbf-Erstellen als mit richtig sortierten Dateien => stets sortierte Daten für osmconvert benutzen.

osmconvert kann aus unsortierten Daten Polygone schneiden und die unsortierten Daten auch in andere Formate konvertieren,
bei “mergen” geht’s jedoch schief:
Seien a.osm, b.osm, c.osm unsortiert, so ist
osmconvert a.osm b.osm c.osm > d.osm
fehlerhaft, denn es fehlen nodes.
=> stets sortierte Daten für osmconvert benutzen.

135

Ja, das sehe ich genauso und hatte letzte Woche (05.01.) den Programmautor diesbezüglich angeschrieben.

…
Wäre es möglich nur eine (große) Ergebnisdatei statt vieler kleiner zu erzeugen ?
Würde dies eine Qualitätssteigerung, z.B. an den Kachelgrenzen, darstellen?
…

Ich stelle das Ergebnis einer Rückantwort dann hier ein.

Klaus

PS: Dass das Perl-Skript genauso performant ist, wie Marios Shell-Skript wundert mich allerdings - aber gut.

136

$ phyghtmap --area=5.5:45.2:16.7:48.7 --gzip --jobs=1 --max-nodes=250 --osm-version=0.6 --start-node-id=20000000 --step=20 --viewfinder-mask=1

jip, ähnlich. Poste das Korrekte Morgen. Hab zusätzlich noch eine srtm3 Datei durch eine viewfinders3 ausgetauscht. Denke aber nicht dass es daran liegt. Meine phyghtmap hat die patches von kukuk - sowie eine Änderung wo ich die node Zahl von 100.000 auf 100.000.000 hochgesetzt - sonst ident. Poste Morgen nochmal meine komplette Toolchain inkl. Sources.

137

Der Wert für “–start-node-id=20000000” ist zu klein, es sei denn deine Patches modifizieren intern den Wert.
Besser (weil kollisionsfrei zu OSM-IDs) wäre das: --start-node-id=2000000000

Klaus

Mein vollständiger Aufruf:
phyghtmap --step=25 --osm-version=0.6 --jobs=1 --area=-19:27:-12:30 --line-cat=500,250 --viewfinder-mask=3 --start-node-id=2000000000

138

Ich habe nicht vor die Daten zu mergen - daher sollte die start-node-id ziemlich egal sein.

Hier ist mein phyghtmap Aufruf:
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 --max-nodes=250 --gzip

– Daten passen zum Alpenextrakt von Geofabrik. Platzbedarf ungepackt 17GB. RAM braucht man nicht so viel. osmconvert war nach umbearbeitung eigentlich recht schnell.

139

Hallo,

ab und an nutze ich in JOSM den Hill-Layer von Nop’s Reit- und Wanderkarte [1], kombiniert mit einem OSM Mapnik Hintergrund [2]. Wenn ich für das gleiche Gebiet Höhenlinien mit phyghtmap erzeuge, liegen diese etwa 50m Richtung NW versetzt. Die Umrisse der Höhenlinien sehen dagegen auf den ersten Blick gleich aus. Beide Höhenlinien stammen wohl aus der gleichen Quelle.

Wodurch entstehen diese Abweichungen?

Getestet mit phyghtmap 1.25 im Gebiet 6.7793889,49.3146251,6.7921776,49.3199614, Schrittweite 10.

Gruß,
mmd

[1] tms:http://www.wanderreitkarte.de/hills/{zoom}/{x}/{y}.png
[2] tms:http://tile.openstreetmap.org/{zoom}/{x}/{y}.png

140

In Version 1.25 ist ein neuer Parameter enthalten: --max-nodes
Allerdings nicht im Sinne von Thomas Patch fuer ways, sondern die Gesamtzahl der nodes pro tile.

Nicht verwirren lassen :wink:

141

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

142

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

143

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

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

Gruß Klaus

144

Nop fragen.

145

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.

146

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

147

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
$

148

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

149

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

150

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:

151

@kellerma

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

Grüße
Mario