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