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…

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

Hallo,

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

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

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

Hallo,

irgendwas muss schiefgelaufen sein. Selbst ohne Optionen (oder nur “–help”) und mit installiertem python-protobuf bricht das Programm mit folgender Fehlermeldung ab:

Viele Grüße
Mario

Das geht bei mir noch, dafür osmconvert nicht mehr :wink:

Auf was für einem System tritt der Fehler auf, und welche python-protobuf-Version ist installiert?

Ich kann den Fehler leider nicht reproduzieren.

Viele Grüße,
Adrian

Das Problem ist genau, was die Fehlermeldung sagt, nur dass die vielleicht missverständlich ist. osmconvert kann mit latitude offsets (die Teil der pbf-Spezifikation sind) nicht umgehen (hier ein Auszug aus dem Quelltext von osmconvert):

Ich kann phyghtmap zwar so ändern, dass pbf von osmconvert gelesen werden kann (latitude offset und longitude offset auf 0 setzen und das erste Element der lat bzw. lon Listen im DenseNodes auf den entsprechenden Wert setzen). Das eigentliche Problem ist aber, dass osmconvert die pbf-Spezifikation nur unvollständig implementiert.

Ich werde mich wohl leider erst morgen darum kümmern können und eine Version 1.41 veröffentlichen.

Bis dann,
Adrian

P.S.: Ich hatte nur mit JOSM getestet, und das kann mit latitude und longitude offsets umgehen.

Hallo Adrian,

ich nutze Ubuntu 10.04, Phyghtmap ist über das angebotene *.deb installiert.

Die Paketverwaltung sagt bei python-protobuf, es wäre die Version 2.2.0a-0.1ubuntu1. Müsste also das Paket sein, das Ubuntu von Haus aus mitbringt.

Viele Grüße
Mario

Frage: Wofür soll das denn gut sein ?

Wenn es darum ging die PBF-Implementierung zu testen, dann wäre osmosis geeigneter.
Ich kann osmconvert leider nicht verwenden, da es nur eine PBF-Datei verarbeiten kann.
Vielleicht liest Markus (der Autor von osmconvert) mit und äußert sich mal …

Klaus

Debian 6 (squeeze) hat (in etwa) die Versionsnummern des ein Jahr älteren Ubuntu 10.04 (lucid);
in diesem Fall ist es mal weiter, nämlich bei 2.3.0.

Du könntest - nur so zum Spass :wink: - mal das 2.3.0 von Ubuntu 10.10 (maverick) ausprobiern:
https://launchpad.net/ubuntu/maverick/amd64/python-protobuf/2.3.0-2ubuntu1

Och, da lernt man zuweilen interesante Dinge kennen, wie - ähm - latitude offsets und so
:wink:

osmconvert gibt einen error aus, tatsächlich wird aber die Datei noch geschrieben.
Nur bin ich mir jetzt nicht mehr sicher, ob dieses Ergebnis “noch korrekt” ist.

Anders bei der “Statistik”, da geht dann halt gar nix mehr:

Hallo!

Richtig, osmconvert beherrscht nicht alle PBF-“Dialekte”. Für solche Spezialitäten würde ich besser Osmosis verwenden. Bei osmconvert wurde auf alle verzichtet, was üblicherweise nicht genutzt wird oder die Datenumwandlung bremsen könnte. Dazu gehören z.B. die Fähigkeit unkomprimierte PBFs zu schreiben sowie das Anwenden von Koordinaten-Offsets.

Zwar sind solche Offsets für das PBF-Format spezifiziert, aber die Spezifikation ist derart ungünstig geschrieben, dass diese Offsets immer erst nach den jeweiligen Datenblocks in der Datei stehen. Das heißt, man kriegt zuerst einen mittelgroßen Haufen an Daten und erst hinterher gesagt, “ätsch, die Koordinaten gelten so gar nicht, sie müssen noch verschoben werden”. :wink: Zu diesem Zeitpunkt hat osmconvert die Daten aber schon rausgeschrieben.

Ich hab vor einiger Zeit schon einmal überlegt, das Programm so zu ergänzen, dass es mit Offsets umgehen kann, hab den Gedanken aber wieder verworfen, weil das keiner gebraucht hat. Auch heute ist mir der Sinn solcher Offsets nicht klar, weil Koordinaten im PBF-Format sowieso nur als Deltas abgespeichert werden, man spart also durch die Offsets gar keinen Speicherplatz. Das Einzige, was man erreicht, ist langsameres Schreiben und langsameres Lesen.

Vielleicht irr ich mich aber auch? Wofür braucht ihr solche Offsets auf Datenblock-Ebene?

Schöne Grüße
Markus

Hallo,

nun verwende ich python-protobuf 2.3.0-4ubuntu2, welches eigentlich für natty ist. Damit funktioniert’s.

Allerdings sollte nicht schon beim Start von Phyghtmap ein installiertes (und aktuelles) python-protobuf vorausgesetzt werden, wenn man es nicht braucht. PBF schreiben geht - wie von Adrian schon erwähnt - recht langsam und ist nur was für PCs mit wenig Speicherplatz. Mir hilft das Format schon deshalb nicht, weil ich zwei Bereiche mit unterschiedlichen Parametern erstelle, dafür 3 Durchläufe brauche und anschließend per Script mergen möchte. Zudem ist die Bounding-Box beim XML-Format nicht osmosis-tauglich (Phyghtmap macht es korrekt nach Spec).

Viele Grüße
Mario

Nicht korrekt.
“python-protobuf” ist optional.
Wenn ich kein python-protobuf installiert habe kommt
$ phyghtmap --area=8.59:49.34:8.78:49.45 --jobs=1 --osm-version=0.6 --step=20 --pbf
phyghtmap: error: no such option: --pbf
Jedoch funktioniert weiterhin ein
$ phyghtmap --area=8.59:49.34:8.78:49.45 --jobs=1 --osm-version=0.6 --step=20

Du hattest das Pech, dass bei Deiner Distri eine zu alte Version dabei war.

? Bezieht sich das jetzt auf “osmconvert”, oder was?
Versteh’ den Zusammenhang nicht.

Okay, dann sollte python-protobuf beim Start gänzlich ignoriert werden, egal ob installiert, nicht installiert oder veraltet und phyghtmap nicht schon beim Hilferuf :wink: abschmieren.

Nein. Osmconvert, Phyghtmap und auch JOSM lesen/schreiben die Bounding-Box so wie in der OSM-XML-Spezifikation. Nur Osmosis verwendet eine abweichende Variante und ignoriert die Vorgabe. Folgeprogramme wie der Tile-Splitter machen dann beim Auswerten der PBF Probleme.

Wenn Du osmconvert mit dem Schalter
–emulate-osmosis
benutzt, klappt es dann?

Das Problem ist doch nicht das pbf von osmconvert, sondern das pbfvon osmosis, welches nicht weiterverarbeitet werden kann, weil es sich nicht an die Spezifikation hält.

Ich hab’ das anders verstanden :wink:

Wenn ich den output von phyghtmap durch
osmconvert --emulate-osmosis schleuße,
(oder Alternativ Adrian baut diese Option auch noch in sein phyghtmap mit ein :wink:
dann wird anschließend osmosis das erzeugte osm (oder auch pbf) richtig interpretieren
und nach seiner Abarbeitung einen Output erzeugen, welcher von tile-splitter verstanden wird.

Ansonsten könnte ja osmosis nie für den tile-splitter verwendet werden, oder?
(oder muß man dann osmconvert zum pbf-schreiben hinter osmosis nachscheußen?)

EDIT
1.41 ist da :slight_smile:
changes some internal representation of longitudes and latitudes in pbf output. This was needed because osmconvert can’t handle longitude and latitude offsets.