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.

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 :)

Nach und nach nimmt die weite Reise Gestalt an.

Der große Rucksack ist bereit beladen zu werden, das ThinkPad ackert sich durch die letzten Vorbereitungen, damit ich (hoffentlich) vor Ort in Bogazköy gleich mit dem GPS draufloslaufen kann.

Lange Listen warten darauf viele, viele kleine Häkchen zu bekommen, wenn die einzelnen Dinge Ihren Platz gefunden haben, oder zu erledigende Aufgaben Ihren Abschluß gefunden haben.

Mal schauen, wie oft ich Gelegenheit haben werde vor Ort ins Internet zu gehen und hier ein paar Nachrichten zu hinterlassen. Wenn ich dort überhaupt etwas zu berichten habe, oder darf - kann ja sein, daß es so wichtige Ergebnisse gibt, daß ich an dieser Stelle nicht freimütig alles veröffentlichen darf.

Nebenbei habe mich noch ein wenig in digiKam eingearbeitet. Da ich noch keine Digitalcamera besitze, sondern nach wie vor der schrecklich teuren analogen Photographie treu geblieben bin (Diapositive haben immer noch eine unglaubliche Informationsdichte! - warum sind gute digitale Spiegelreflexcameras so teuer?) war für mich bisher wenig Bedarf dazu. Aber ich habe den Nutzen dann doch unterschätzt, meine vielen Rasterdaten kann ich damit viel besser überblicken, kommentieren und sortieren. Das hat mir die Arbeit an den Satellitenbildern sehr erleichtert.

Ich frage mich gerade, wieso man in Flugzeugen nur 20 kg Gepäck und 8 kg Handgepäck haben darf. Ich denke ich wiege weniger als der durchschnittliche deutsche Erwachsene, man könnte doch einfach die einzelnen Passagiere samt allen Gepäckes wiegen und das darf einen bestimmten Wert nicht überschreiten. Somit wären dicke Menschen angehalten den überdurchschnittlichen Kerosinverbrauch entweder durch reduziertes Gepäck zu kompensieren, oder eben zu bezahlen, während leichte Menschen, vielleicht etwas günstiger davonkämen. Solche Gdanken kommen, wenn man merkt, daß die ganze Ausrüstung und die mitzunehmende Kleidung (es ist zur Zeit ca. 30° C in der Region Ankara - zum Herbst hin wird es sich wohl empfindlich abkühlen) für 60 Tage doch einiges an Volumen und Gewicht bedeutet. Wenn es ganz eng wird, werde ich wohl auf ein bischen Fruchtgummi und Lakritz verzichten müssen. Oder meine Weste damit vollstopfen :).

Genug der wirren Gedanken - bis die Tage!

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.