Wer schon immer mal einfach seine GPS-Daten auf einer GoogleMap veröffentlichen wollte, der wird mit gpx2gm.py das machen können.

Mich hat geärgert, daß es so mühsam ist seine GPS-Tracks zu veröffentlichen. Man muß Sie erst via gpsbabel einlesen und dann kann man das zwar mit einem webdienst umwandlen lassen in eine GoogleMap, aber da muß man dann jede Menge Handarbeit anlegen, bis die so aussieht, wie man das gerne hätte.

gpx2gm.py ist zwar noch lange nicht am Ziel meiner Wünsche, aber die wichtigste Fähigkeit beherrscht es ganz ordentlich.

gpx2gm.py

Das Programm liest eine gpx-Datei ein und wandelt alle Trackpunkte in eine GoogleMap-Polylinie um. Es unterscheidet noch nicht zwischen einzelnen Tracks innerhalb einer Datei, das kann man als Vorteil sehen, wenn man kleinere Unterbrechungen im Empfang hatte, oder als Nachteil , wenn das alles gar nicht zusammen betrachtet werden soll - das ist so eine Sache an der es noch zu arbeiten gilt.

Was es kann (für mittlere Breitengrade), ist aber das nötige Zoomlevel anhand der gewünschten Kartengröße in Pixeln zu wählen und so dafür Sorge zu tragen, daß man da kein lästiges rumprobieren hat.

Einzige Vorraussetzung ist, daß man die Tracks vom Gerät im XML Format als .gpx-Datei vorliegen hat.

Wer es ausprobieren möchte:
auf der Befehlszeile python gpx2gm.py pfad/zur/datei.gpx
eingeben.

In der Programm-Datei sind alle Variablen ausführlich kommentiert, so daß man sich einigermaßen schnell zurecht finden sollte. Für die Zukunft ist hier eine Vereinfachung angedacht. Bevor man aber eine solche Karte veröffentlichen kann, muß man sich von Google eine kostenlosen API-Key zuteilen lassen.

Teil drei sollte sich eigentlich bereits vorgestern damit beschäftigen, wie das Hochladen von Daten (Wegpunkten, Routen, 'tracks') klappt. Es funktionierte wider Erwarten nur halbwegs. Ich vermutete zunächst etwas in der Bedienung von gpsbabel übersehen zu haben, weshalb immer nur ein Wegpunkt hochgeladen wurde, anstatt alle vorgegebenen auf einmal.

Aber das war es nicht, also mal die allzu bekannte Suchmaschine genutzt und siehe da: der Treiber für Garmin (garmin_gps) wird auf gpsbabel ein reibungsloses Funktionieren treffenderweise als "depressingly uncommon situation" beschrieben. Also blieb mir nur über die angebotenen Lösungswege auf Gentoo Linux anzuwenden

Als erstes nutze ich die Gelegenheit den unweise fest in den Kernel kompilierten Treiber zu entfernen, was mir die mühsamen Umwege erspart den Treiber davor zu bewahren überhaupt geladen zu werden. Ich halte es auch für die sauberere Lösung das Ding direkt zu entfernen, da es nachweislich nicht korrekt arbeitet.

Im wesentlichen reichte es dann unter:
/etc/udev/rules.d/ die Datei 51-garmin.rules anzulegen. In diese Datei kommt folgende Zeile:
SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", GROUP="plugdev", MODE="660"

Nun konnte ich mittels QGIS eine neue .gpx-Datei anlegen und mit lustigen Wegpunkten befüllen. Auch Routen ließen sich problemlos erzeugen und als normaler Nutzer ohne root-Rechte mit folgendem Befehl auf das GPS-Gerät hochladen:
gpsbabel -r -i gpx -f test.gpx -o garmin -F "usb:"

Nun endlich kann ich in Vorbereitung für Hattuscha die wesentlichen Strukturen vorab auf das Gerät laden. Übrigens Routen und 'tracks' eignen sich hervorragend, um Gebäudeumrisse nach zuzeichnen.

Und wieder ein Problem gelöst :)

Nachdem der erste kleine Spaziergang durch den Wienburgpark erfolgreich aufgezeichnet war, mit etwas Mühe dem GPS-Gerät entlockt und in eine shp-Datei mittels gpx2shp verwandelt war, wollte ich doch nun den wirren Linien und Punkten ein wenig Boden geben und lud mir zu dem Zwecke gleich mal ein ETM+ Satellitenbild¹ herunter.

Eine GrassGIS-Location für Münster mit UTM (32U) für das Satellitenbild angelegt und noch eine für die GPS-Daten in LatLong; rasch die Daten importiert und dann mittels v.proj alles zu der UTM-Zone konvertiert.

Eine leichte Abweichung hatte ich erwartet, aber etliche Kilometer in Nordost- bzw. Südwestrichtung kamen mir dann doch seltsam vor. Dann wäre der Spaziergang nämlich in der Nähe der Rieselfelder anstatt im Park verlaufen. Eine Überprüfung ergab eine Überraschung. Die GPS Daten waren trotz der Konvertierung GPS->gpx-Datei->shp-Datei (zumindest die Punkte der Spur ('Track' im GPS-Jargon) ließen sich nicht via gps-babel importieren, das Modul v.in.gpsbabel brach ab.) konsistent und zeigten völlig korrekte UTM-Werte an, wenn ich der UTM-Berechnung des Gerätes trauen darf.

Vermutlich war die als 'orthorectified' deklarierte ETM+-Datei unsauber georeferenziert worden. Das ist vergleichsweise ärgerlich, denn Rasterdaten zu georeferenzieren ist mit GrassGIS freundlich formuliert: 'mühsam'.

Quelle für das zugrunde liegende Satellitenbild ist: Global Land Cover Facility, http://www.landcover.org. Erstellt mit GrassGIS 6.2.1 & QuantumGIS 0.8.1

Und hier schließlich die Route in rot und die einzelnen Messpunkte in grün bis leicht bräunlich, je nach Höhe über NN.

_________________________

Heute ist es eingetroffen, mein neues Spielzeug. Ein GPS-Handgerät. Gleich nach dem Auspacken hastig zwei Batterien hineingetan und andächtig zugeschaut, wie die GPS-Satelliten vom Gerät erkannt wurden, bis es der Meinung war, daß es sich in Münster befinden muß. Erkennbar an den Koordinaten.

Bereits die ersten Tests zeigten, wie einfach sich die Daten via QuantumGIS auslesen lassen. Ich hatte befürchtet zunächst mit gpsbabel die Kommandozeile quälen zu müssen.

Ein kleiner Bummel durch die Stadt zeigte recht bald die Grenzen des Empfangs auf, in den Gassen und Straßen und am Prinzipalmarkt unter den Arkaden, brach der Empfang zeitweilig zusammen, dennoch konnte ich bereits einigermaßen die Route erkennen, leider reichte es nicht für kontinuierliche und halbwegs verwendbare Höhenwerte aus.

Dummerweise stürzte QGIS auch noch reproduzierbar ab, wenn man versuchte die Daten anhand der verschiedenen Felder unterschiedlich darzustellen. Auch ein shape-export wurde nicht ermöglicht, ich denke da ist noch etwas zu tun im GPS-PlugIn. Nichtsdestotrotz ist es ein sehr angenehmer Weg die Daten schnell einzulesen und direkt zu betrachten.

Auch ein erster Test mit GrassGIS lief sehr vielversprechend, wenn auch wie QGIS nur unter Verwendung von gpsbabel im Hintergrund, gpstrans als GPS-Datenimporteur verweigerte die Zusammenarbeit wegen Formatproblemen wie es aussah. Schade, daß es keinen ebuild von gpstrans gibt, so mußte ich für den Test doch tatsächlich seit langem mal wieder ein Programm per Hand installieren, was sich aber auf das Herunterladen, entpacken, make && sudo make install reduzierte. Sehr einfach, in der jetzigen Form leider auch sehr überflüssig.

Ein weiterer Malus gegenüber dem Import mit QGIS ist, daß man zunächst eine Location anlegen muß, bevor man überhaupt Daten eimlesen konnte. Schließlich sind auch noch die einzelnen Feldbezeichner überraschenderweise unterschiedlich benannt. Was bei QGIS 'Elevation' ist, wurde von GrassGIS als 'Altitude' deklariert. Obwohl beide eigentlich mit gpsbabel den gleichen Datenimporteur verwenden sollten. Da stellte sich für mich die Frage, ob einer von beiden eine eigene und eben andere Bibliothek mitbringt.

Ich freue mich bereits darauf ein paar Spaziergänge aufzuzeichnen und hoffentlich als komplette Route einlesen zu können.

Die ersten Ergebnisse werde ich sicherlich hier veröffentlichen.

Juchuu! - nach fleißigem Basteln freue ich mich Version 0.4b der gis-tools.py freizugeben. Mein besonderer Dank geht an Seth Arnold, der mir mit viel Geduld geholfen hat die eine oder andere Hürde zu überwinden.

Hinter den Kulissen hat sich einiges getan:

• wie bereits angekündigt, ist der Code nun deutlich modularisiert und unterteilt in Benutzerschnittstelle, Konvertierungsfunktionen und dem Syntaxanalysierer (habe ich doch direkt mal das Wort 'parser' mit ding nachgeschlagen - herrliches Wort!), der derzeit noch den Kleber zwischen den anderen Ebenen spielt, sowie eine Hilfe und ein Auxiliarmodul für allgemeine Berechnungen.
• für die Umwandlung von Längen- und Breitengraden zu UTM-Koordinaten sind die Möglichkeiten hinzugekommen zwischen
  • einer aus den Längengraden berechneten gemeinsamen UTM-Zone,
  • je Koordinatenpaar die optimale Zone zu berechnen und
  • eine vom Anwender vorgegebene Zone, die angegeben werden muß
  zu wählen.

Ein bisl Zeit und Energie braucht es noch, bis auch das Analysieren der Eingabedatei flexibler von statten gehen kann. Momentan geht die Überlegung dahin, die Datenstruktur aus einer Titelzeile herauszulesen, das wäre am einfachsten für den Anwender, würde aber wiederum erschweren, 'mal eben' was auszulesen. Aber auch da wird es eine Lösung geben.

Manchmal hat man Glück. Das Thema Längen- und Breitengrade in UTM (Universal Transverse Mercator) umzuwandeln hat wohl aufgrund seiner enormen Komplexität des öfteren Interessierte veranlasst entsprechende Fragen zu stellen und glücklicherweise höchst fundierte Antworten zu bekommen.

So war es relativ einfach, die hinter der Konvertierung stehende Formel in die gis-tools.py einzubinden. Ein bischen Feinschliff und einige zusätzliche Features möchte ich noch einbinden, um auch große Reihen von Koordinaten elegant umzuwandeln. Version 0.4 wird also schon bald folgen.