phyghtmap - NASA SRTM -> OSM xml translator

Moin,

es ist richtig, dass man damit tatsächlich keinen Speicherplatz spart, zumindest, wenn man DenseNodes anstelle von Node verwendet, was phyghtmap ja auch tut. Und bei Node hilft es außerdem auch nur dann, wenn der Datenblock komprimiert wird (und die Offsets entsprechend sinnvoll gewählt sind). Ich hatte vorher nicht darüber nachgedacht und insbesondere war mir nicht bewusst, dass die Offsets hinter dem Datenblock stehen und das Parsen/Rausschreiben damit künstlich unperformant wird.

Tatsächlich entfallen auch beim pbf-Schreiben zusätzliche Rechenoperationen, so dass das Schreiben von pbfs ohne Offsets etwas schneller gehen sollte. Dass das pbf-Schreiben mit python trotzdem besonders langsam ist, ist bekannt. In den protobuf-Quellen steht dazu:

Die meiste Zeit geht by phyghtmap wirklich durch die protobuf-Implementation verloren. Auf das Erzeugen des Outputs geht deutlich über die Häfte der Zeit drauf. Vielleicht wäre es sinnvoller, das pbf per Hand zu formatieren, dann würde auch die python-protobuf-Abhängigkeit verschwinden.

Mal schauen,
Adrian

@viw, @kellerma,

nochmal zur Bounding Box…

Bei Osmosis:

(origin ist da zwingend)

Restliche Programme (wie in Spec):

(bei JOSM mit zusätzlichem origin)

Das Problem macht Osmosis schon beim Lesen vom OSM-Format, weil es nur die Bounding Box in der ihm eigenen Form (an-)erkennt - sie fehlt also, wenn die Form wie in der Spec ist, also dann beim Schreiben mit --wx oder --wb. Den Tile-Splitter wiederum stört deren Fehlen im OSM-Format nicht, aber wohl im PBF-Format, weil die Werte einfach auf “0” gesetzt sind. (Wirklich 0? - weiß ich jetzt nicht.) Das Verhalten kann sich aber auch mit der nächsten Splitter-Version geändert haben.

Bisher war der Unterschied nicht störend weil kein Programm die Bounding Box wirklich brauchte und es noch kein PBF-Format gab. Außerdem lässt sie sich ja während der Datenverarbeitung nebenbei ermitteln.

Viele Grüße
Mario

1.41 wovon? osmosis?
Chris

Warum sollte osmosis von 0.40 auf 1.41 springen? :wink:
1.41 von phyghtmap, ist auch Thema des Threads :wink:

Phyghtmap

Es klappt bei mir schon deshalb, weil ich in meinem Merge-Script die osmosis-typische Bounding Box einsetze. :slight_smile:

Warum nicht, Firefox springt ja auch wöchentlich eine Nummer höher… :wink:

Wenn ich
http://lists.openstreetmap.org/pipermail/osmosis-dev/2011-December/001198.html
richtig interpretiere, sollte dass dann mit der 0.41 erledigt sein.

Für osmconvert hab ich die PBF-Schreibprozeduren auch selber von Grund auf neu programmiert, ich verwende die Protobuf-Lib nicht. Aus dem Grund ist osmcovnert auch so schnell - und so unübersichtlich und kann nicht alles. :wink:

Aber vielleicht wär dieser Weg auch für euer Projekt sinnvoll?

Oder sollte man eine neue PBF-Lib in C schreiben, die dann schneller ist?

Mit den srtm1 Daten gibts in den USA noch größere Probleme bei phyghtmap. Hab kein einziges der geofabrik boundaries durchrechnen lassen können. Abbruch meist schon sehr schnell (und i.e. N38W077.hgt hab ich extra ein zweites mal runtergeladen um sicherzugehen dass es korrekt runtergeladen ist).:

Aufruf: phyghtmap --jobs=1 --osm-version=0.6 --step=20 --output-prefix=usne --line-cat=500,100 --srtm=1 --polygon=/home/contourlines/bounds/us-northeast.poly --max-nodes-per-tile=0 --max-nodes-per-way=250 --pbf
(bzw mit --gzip=5 anstelle von --pbf was aber den selben Fehler bringt)
… downloading …
hgt file hgt/SRTM1/N38W075.hgt: 3601 x 3601 points, bbox: (-75.00000, 38.00000, -74.00000, 39.00000)
hgt file hgt/SRTM1/N38W076.hgt: 3601 x 3601 points, bbox: (-76.00000, 38.00000, -75.00000, 39.00000)
hgt file hgt/SRTM1/N38W077.hgt: 3601 x 3601 points, bbox: (-77.00000, 38.00000, -76.00000, 39.00000)
Traceback (most recent call last):
File “/usr/local/bin/phyghtmap”, line 9, in
load_entry_point(‘phyghtmap==1.41’, ‘console_scripts’, ‘phyghtmap’)()
File “/usr/local/lib/python2.7/site-packages/phyghtmap-1.41-py2.7.egg/phyghtmap/main.py”, line 437, in main
timestampString=output.timestampString))
File “/usr/local/lib/python2.7/site-packages/phyghtmap-1.41-py2.7.egg/phyghtmap/main.py”, line 272, in processHgtFile
return ways # needed to complete file later
UnboundLocalError: local variable ‘ways’ referenced before assignment

Das Problem tritt nur auf, wenn in der bounding box des Polygons SRTM-Dateien liegen, die keine Schnittmenge mit dem Polygon selbst haben. Im Prinzip hätte es gereicht, der Variable ways vorher eine leere Liste zuzuweisen, ich checke jetzt aber auch noch, ob eine Quelldatei in der bounding box liegt oder nicht. Damit wird auch der Download nicht benötigter SRTM-Dateien vermieden. Auf der anderen Seite braucht das Checken etwas mehr Zeit.

Ich habe jetzt jedenfalls Version 1.42 veröffentlicht. Die fixt dieses Problem.

Außerdem habe ich das pbf-Formatieren jetzt per Hand implementiert. Das ist deutlich schneller als mit den python-protobuf bindings, aber immer noch langsamer als XML. Positiver Nebeneffekt ist, dass python-protobuf nicht benötigt wird.

Ansonsten ist jetzt mal doch endlich --osm-verion=0.6 default.

Viele Grüße,
Adrian

Tolle Arbeit, Adrian :slight_smile:

Danke schön!

Hi,

mit der 1.42-1 erhalte ich folgenden Fehler:

Traceback (most recent call last):
File “/usr/bin/phyghtmap”, line 5, in
from pkg_resources import load_entry_point
File “/usr/lib/python2.7/dist-packages/pkg_resources.py”, line 2672, in
working_set.require(requires)
File “/usr/lib/python2.7/dist-packages/pkg_resources.py”, line 654, in require
needed = self.resolve(parse_requirements(requirements))
File “/usr/lib/python2.7/dist-packages/pkg_resources.py”, line 552, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: phyghtmap==1.42

Habe im File “/usr/bin/phyghtmap” die 1.42 durch 1.42-1 ersetzt. War wohl nicht ausreichend, Fehler bleibt.

BS: Xubuntu 11.10

M.W. gibt es keine Version “1.42-1”, sie ist nachwievor “1.42”.
“1.42-1” ist die “erste Debian-Paket-release der Softwareversion 1.42”.


$ python
Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>> pkg_resources.require('phyghtmap')
[phyghtmap 1.42 (/usr/lib/python2.6/dist-packages)]
>>> 

Du hast schon eine neuer Python-Version (2.7), dann muesste es bei Dir unter
/usr/lib/python2.7/dist-packages/
ein Verzeichnis “phyghtmap” (und eines “phyghtmap-1.42.egg-info”) geben.

Ich würde die beiden löschen und das Debian-Paket deinstallieren und nochmal installieren.
Falls es dan nicht klappt, evtl. aus dem Source bauen.

Die Verzeichnisse waren nur unter python2.6/dist-packages zu finden. Habe diese nach python2.7/dist-packages kopiert. Bingo.

Danke

Hallo,

ich habe heute Version 1.43 veröffentlicht. Neu ist vor allem die --source-Option, mit der man jetzt die Reihenfolge, in der phyghtmap verchiedene Datenquellen benutzen soll, angeben kann. Außerdem gibt es ein paar bug fixes. Ein bisschen mehr dazu http://katze.tfiu.de/projects/phyghtmap/download.html.

Viele Grüße,
Adrian

Hallo Adrian,

Danke! Aber keiner der 1.43 Links funktioniert im Moment, wohl aber die 1.42 Links.

Thorsten

Sorry, jetzt gehen sie.

Gruß,
Adrian

@panarchos

der im Posting #53 genannte Fehler tritt auch mit der 1.43 auf. Die beiden phyghtmap-Ordner befinden sich nach Installation in /usr/lib/python2.6/dist-packages/ und nicht in /usr/lib/python2.7/dist-packages/

Manuelles Kopieren von 2.6 nach 2.7 ist erforderlich, damit phyghtmap läuft.

Hallo,

ich habe Version 1.44 veröffentlicht (http://katze.tfiu.de/projects/phyghtmap/).

Grüße,
Adrian