GPSBabel-Weiterentwicklung (OVL und PTH-Format)

Möchte jemand mithelfen, GPSBabel weiter auszubauen?
Nachdem Toptrans nicht mehr angeboten wird, besteht bei mir Bedarf nach einem "Schweizer Taschenmesser", das auch OVL (Top50-Karten) und PTH (Top25-Karte) spricht. GPSBabel kann schon fast alle Formate, nur diese eben nicht.
Eine grafische Oberfläche (s.Bild) ist vorhanden. Per command-line lässt sich Babel zudem auch gut in andere Skripte einbinden.

Code für ASCII-OVL habe ich schon geschrieben, etwas in C zum Einlesen von OVL-Tracks und Flächen; und einen kleinen Skriptwriter für OVL-Waypoints. Diese Routinen kann ich gerne als Source spenden. Nach Weihnachten hätte ich noch etwas Zeit, die Dinge anzupassen. Möchte jemand mithelfen, das in den Babel-Source einzubauen? So ganz habe ich das System für Format-Erweiterungen noch nicht durchschaut. Auch mit dem PTH-Format habe ich mich noch nicht beschäftigt. Wäre gut, wenn da jemand ergänzen könnte. Babel steht unter der GNU-Lizenz, d.h. der Code wird immer frei bleiben. Wenn wir Beiträge schreiben, muss das auch darunter fallen. Es wäre schön, noch ein paar Do-it-yourself-Hobbyisten dafür zu finden. Alleine schaffe ich das nicht.

www.gpsbabel.org

Also, bei mir geht's einwandfrei. NMEA-Sequence einlesen (Dateityp * einstellen, da keine .txt-Endung), Google KML speichern. So wie im Screenshot. Wo ist das Problem?

So, hab jetzt meinen Bedarf an OVL-Support für's erste abgedeckt, damit ich auch ohne Toptrans zurechtkomme. Die entsprechenden Skripte habe ich den geotools.zip hinzugefügt (Download Hier). Wann und ob das in gpsbabel ergänzt werden kann, mal schauen. Dieses Jahr wohl nicht mehr. Momentan sehe ich noch nicht den richtigen Anknüpfungspunkt. Hat von euch jemand das Konzept verstanden? Der Babel-Source scheint nicht so recht modular für Extensions aufgebaut zu sein (d.h. es wäre an vielen Stellen zu patchen). Der Vorteil von GPSBabel ist natürlich, dass man gleich eine Windows-Oberfläche dazu hätte. Bash-Skripte sind nicht unbedingt etwas für Jedermann.

---
csv2ovl < track.csv > track.ovl
ovl2csv < track.ovl > track.csv

OVL-Dateien von/zu CSV-Dateien konvertieren.
Die ASCII-CSV-Dateien bestehen aus "latitude, longitude"-Zeilen.
Gelesen werden Textpunkte, Linien und Flächenecken. Geschrieben werden nur Polygonzüge.

kml2ovl < track.kml > track.ovl
KML Linie/Track zu OVL track konvertieren (nur ein Track, der Erste im KML)

Andere Formate sind per gpsbabel möglich.

---

zu den NMEA-Tracks:
wenn du mehrere Track-Dateien hast, kannst du dir die ganze Windowsklickerei sparen und einfach eintippen

nmea2kmz-all *.txt

Dann werden die Tracks alle automatisch in's KMZ-format konvertiert. Falls du Optionen haben willst, z.B. Trackreduktion oder Entfernen unrealistischer Einträge, einfach das Skript entsprechend der GPSBabel-Optionen anpassen.

zu deinem Problem: bitte erst im Texteditor prüfen ob das NMEA korrekt ist (du meinst doch nicht etwa das Fahrtenbuch ...:-), ob da wirklich Positionen drin sind oder kein Singal, ob die GPRMC-Sequenz mit Datum drin ist (sonst gprmc-Option deaktivieren). Und dann nochmal im KML-Quelltext hereinschauen, ob da überhaupt was drin ist.

---------
p.s. ja, es gibt einen kleinen feinen Unterschied zu Toptrans: mir ist aufgefallen, dass bei GPSBabel vereinzelt Alien-Positionen auftauchen. Z.b. Kurze Citytour in D-Land. Aber dann für eine Sekunde mal eben einen Abstecher nach Paris (wenn das so einfach wäre ....). Toptrans hat diese herausgefiltert, GPSBabel nicht. Ich weiss auch nicht, was nun richtig ist. Ich habe versucht, das NMEA-Log zu verstehen. Es passiert vor allem in den Phasen, wo der Navi nur Müll liefert (Signal verloren). Aber genau dieser Alien-Eintrag hatte scheinbar eine korrekte GPRMC und GPGGA-Sequenz (3 Sats und als Ok markiert). Auch durch den Gpsbabel VDOP/HDOP-Extremwertfilter und Checksummencheck ging der durch. Es ist aber ein Einzelwert zwischen heimischen Positionen. Vielleicht hat Toptrans den daran identifiziert. Kennt ihr das Phänomen? Mich stört das vor allem darum, weil in GoogleEarth der Track dann nicht so schön passend in den Bildschirm gesetzt wird (workaround bisher: Datenmüll im NMEA-Log löschen). Problemlösungen sind willkommen.

Prima, topo. Wenn sich genügend Leute die Arbeit aufteilen wird sich der Aufwand in Grenzen halten. Wie gesagt, für das OVL-Format habe ich jetzt eine Zwischenlösung per bash-script. Daher ist der Bedarf bei mir nicht mehr so groß. Aber gerne kann ich das noch in GPSBabel einbringen, damit auch der Windowsbenutzer das einfach nutzen kann. Im Babelsource gibt es übrigens dieses hier:

format_skeleton.c

Das ist die Vorlage für eigene Datenformate. Ich hab zunächst in den anderen Sourcen gewühlt und das README.contrib nicht gelesen ... Mit der Vorlage vereinfacht sich die Sache doch erheblich.

Hast du noch Formate, die du im GPSBabel vermisst? An PTH aus den Top25-Karten wäre zu denken, aber andererseits kann MagicMaps auch OVL schreiben. Ob es dann noch benötigt wird?

Folgende Dinge hatte ich mir für Babel noch überlegt:

- Ein Track/Wp-Editor wäre nett, der fehlt.
Momentan ist es schwierig, Einträge zu editieren. Im NMEA-Ursprungsformat oder im KML lässt sich nicht gut herumfummeln. Von daher sollte man evtl. ein CSV-Zwischenformat definieren (XCSV-Style?), in dem alle Felder drin sind, ähnlich wie im NH-Toptrans-Editor. Dann könnte das in Excel editiert werden und mit Babel dann in das Zielformat übertragen werden.

- Der beschriebene Effekt mit den Aussreisserpunkten müsste angegangen werden. Soweit ich das analysiert habe macht es Babel schon richtig, dass korrekte NMEA-Einträge umgewandelt werden. Aber ein einzelner Punkt in Paris auf einer Route von Augsburg nach München ist doch etwas ... naja, etwas naturgesetzwidrig. Vielleicht könnte die NMEA-Verarbeitung von Babel dahingehend angepasst werden, dass die dabei auftretenden Hyper-Geschwindigkeiten erkannt und rausgefiltert werden. Schwierig ist es nur deshalb, weil es ja auch legale Sprünge in den Einträgen gibt, wenn man sein Navi ausschaltet und woanders wieder einschaltet. Ein "singulärer" Extrempunkt könnte aber getrost eleminiert werden.

- Multi-Tracks sind da nicht drin, bringt auch nichts das nachzurüsten. Babel ist so aufgebaut, dass jeweils nur ein Track/Route verarbeitet wird. Das muss zwangsläufig über mehrere Dateien geregelt werden.

Sonst noch Ideen zum Nachrüsten?

p.s. hat jemand Glopus-PC auf WINE zum Laufen gebracht? Ich hatte nur das Standard-WINE von Suse genommen, ohne Windows-Installation. Da lief es nicht. Vielleicht nur ein paar DLL's die fehlten. Aber die Fugawi-Demoversion lief (toll, ohne Microsoft draufzuhaben...).

Von Vmware haben wir eine normale Lizenz, kein Problem. Aber irgendwie ist es schon lästig, für manche Programme ein anderes System starten zu müssen. Wine ist mir da lieber. Es läuft auch erstaunlich viel darin, mit den Crossover-Erweiterungen sogar MS-Office. Klar, Toptrans bekommt man mit Datumstricks am laufen, aber ich möchte lieber eine saubere Lösung ohne Tricks. Und GPSBabel lässt sich schön in eigene Skripte einbetten, NH-Toptrans nicht. Die Windowsklickerei ist nicht mein Ding. Mit bash und Tabulator zur Namensversvollständigung geht das meiste wesentlich schneller, auch unter Windows (wenn man nicht gerade im 2-Fingersuchsystem schreibt).

p.s. du musst gar nicht auf Linux umsteigen um nur Linux-Programme laufen zu lassen. Das meiste läuft auch sehr gut in Cygwin. Das ist eine fast komplette Unix-Umgebung. Dazu habe ich noch den Xming X-Server. Damit laufen dann auch die meisten X-Windows-Programme auf MS-Windows.

Gute Nachricht aus einem anderen Forum: es gibt sogar schon Code für OVL in GPSBabel. 700 Zeilen! Nur funktioniert der noch nicht, und ist deswegen auch im vecs.c Source auskommentiert. Leider war es nicht dokumentiert, so dass mir das overlay.c-Modul nicht aufgefallen ist. Mein Code ist sparsamer, etwa 60 Zeilen pro Richtung. Und der funktioniert sogar, zumindest für Tracks. OVL bietet aber noch viel mehr grafische Möglichkeiten, die ich nicht unterstütze. Mir persönlich reichen die Tracks. Ein Problem ist, dass OVL einen Kartenbezug braucht. So habe ich einfach "Länderübersicht" voreingestellt. Der Babel-Autor hat Niedersachsen voreingestellt. Auf jeden Fall sollte das noch konfigurierbar sein. Mal schauen, ob es einfacher ist, den existierenden Code zu erweitern oder meinen an Babel anzupassen.

Über Kartenimport würde ich mir keine falschen Hoffnungen machen. GPSBabel ist ein Track/Routen/Waypoint-Konverter, nicht mehr und auch nicht weniger. Kartenimport gehört funktional eher zu Kartenmanagement-Programmen. Allgemeine geografische Grundrechenarten kann man besser in eine Library (DLL) auslagern. Libraries gibt es schon ganz gute, das Rad muss nicht neu erfunden werden:
http://proj.maptools.org/
http://remotesensing.org/gdal/

Windows + Cygwin-Unix auf Desktop und Linux auf dem Server. So kann man gut arbeiten. Vor allem Konsumprodukte für den Desktop setzen meist Windows voraus (z.B. die Kartenprogramme). High-performance-computing gehört auf den Linux-Server, weil es für Unix mehr und bessere wiss.-techn. Libraries im Sourcecode gibt. Source heisst auch, dass man fast alles Libraries für 64-Bit kompilieren kann. 32-Bit Apps sind mir schon öfters am Speicherlimit hängengeblieben. Nicht umsonst läuft der neue BMW-Supercomputer unter Linux.

--- update:

ich hab's mir nochmal angeschaut: der Code in GPSBabel funktioniert sogar schon teilweise. Schreiben von Tracks ging nicht, aber ich kann damit OVL auslesen und in alle anderen Babelformate konvertieren. Sehr vielversprechend! Dazu ist nur in vecs.c die #if 0 -Kommentierung zum overlay-Vektor herauszunehmen. Und schon kennt babel das "overlay"-Format. Wie auch beim CSV-Format werden aber die Trackpunkte als Waypoints interpretiert, das kann der "transform"-Filter korrigieren (die kml-csv-Skripte nutzen das).

Übrigens ist meine jetzige Lösung zum OVL-Track Lesen/Schreiben dort drin: Download-Link. Das läuft schon gut. Eventuelle Bugs bitte melden. Eine Linux-Version hab ich noch drangehängt, wo sich hier schon 2 Leute als Pinguine bekannt haben. Zum Testen fehlte mir die Zeit, da ich sie nur unter Cygwin selbst nutze.

Michi, übrigens könnte dein "leerer Track" mit dem Datumsproblem zusammenhängen. Wenn keine GPRMC-Sequenz drin ist, verwirft Gpsbabel den ganzen Track - gibt aber auch eine dementsprechende Warnung aus. Das habe ich geändert, nun gibt's nur noch die Warnung und der Track bleibt (irgendwelche Nebenwirkungen?).

Auch den OVL-Support in Gpsbabel.exe habe ich freigeschaltet. Der war wohl doch schon weiter fortgeschritten als ich dachte. Im Test konnte Babel OVL sowohl lesen als auch schreiben. Wird die modifizierte gpsbabel.exe (mingw-variante) in das Windows-Verzeichnis gelegt, steht diese Funktion "Geogrid Viewer" auch der grafischen Oberfläche zur Verfügung. Sie ermittelt eigenständig, was gpsbabel.exe an Formaten versteht.

Übrigens noch ein Feature: meine Hauptanwendung mit NH-TopTrans war es immer, GPS-Logdateien in GoogleEarth anzuschauen und die Touren nachzufliegen. Die ganze Hantiererei mit Dateien in den Dialogen Suchen und Toptrans starten war doch recht umständlich. Jetzt geht es einfacher: GPS-Log (*.txt) anschauen mit Klick rechte Maustaste auf Logfile. Und schon geht GoogleEarth auf und zeigt den Track. Einfacher geht's nicht mehr, oder? In den aktuellen geotools.zip habe ich dazu ein Registry-File gebastelt, die diese Funktion einrichtet.

Download hier

Hi Thomas,

das klingt sehr interessant mit der Möglichkeit, Karten direkt zu lesen. Ein einfaches Ausprobieren scheitert aber zunächst an der Spezialisten-Programmiersprache IDL (grrrr, das riecht nach BASIC). Binaries sind nicht dabei. Hat jemand auf die angegebenen kommerziellen rsinc-Compiler Zugriff? Interessant wird es, bei Google noch das Keyword "GNU" zu IDL hinzuzufügen. Dann kommt das raus:
http://gnudatalanguage.sourceforge.net/
Vielleicht schluckt GDL den Code auch. Aber bei mir ist die Zeit für Kartenspielereien momentan auch zu knapp.

Wir sollten uns auch im Klaren sein, dass das nichts mit GPSBabel zu tun hat. GPSBabel ist ein Track/Routen/Waypointkonverter, weiter nichts. Auch in NH-Toptrans war die Kartenkonvertiererei eher ein "Anhängsel". Funktional haben die Sachen nicht viel miteinander zu tun. Auch vom Code hier bietet GPSBabel da nicht viel Anknüpfungspunkte.

Als separates Projekt ist der Kartenkonverter sicherlich sehr interessant für Glopus. Kalibrierdaten werden für qpeGPS geschrieben
http://qpegps.sourceforge.net/
Das lässt sich wohl locker konvertieren.

übrigens, es läuft gerade der Testbetrieb für den GPSBabel-Patch

Download
http://www.pocketnavigation.net/board/tid1053510-sid.htm

Neu ist der Datentyp OVL namens "overlay". In der grafischen Oberfläche heisst er "Geogrid Viewer", wenn das gepatchte gpsbabel.exe in das Verzeichnis mit der Babel-GUI geschoben wird. "overlay.c" war schon länger im Sourcecode drin, bislang aber deaktiviert.

Bitte mal testen, ob das unter allen Kombinationen funktioniert. Mein GPS-Log hat es fehlerfrei nach OVL konvertiert ... und wieder zurück. Das Format gibt aber noch eine Reihe weiterer Kombinationen her, die zu testen wären.

Weiterhin erlaubt der Patch nun auch date-free NMEA Tracks, d.h. wo die GPRMC-Datumssequenz fehlt. Früher wurden die einfach weggeworfen, falls das Datum nicht manuell nachgetragen wurde. Jetzt gibt es nur noch die Warnung und der Track bleibt. Es wäre aber denkbar, dass andere Funktionen schief laufen, wenn das Datum fehlt.

Bitte mal alles gründlich durchtesten. Wenn alles läuft, werd ich den Patch zum Einbau in die offizielle GPSBabel-Version einreichen.