RouteConverter 2.11 is ready

Release 2.11 from 30. October '13

• reads Columbus TimeAlbum (.csv) files
• reads and writes MotoPlaner URLs
• reads SRTM1 and SRTM3 files when completing elevation data
• allows to switch between speed and elevation in the context menu of the profile graph
• uses the Glopus (*.tk) format with latitude,longitude,comment when pasting to the clipboard
• uses a single instance when calling the Webstart API and passing it an URL to open
• uses integer tick units for the profile graph to avoid fraction number
• is more robust when reading NMEA 0183 Sentences (*.nmea) files
• allows to use zoom level 19 of Mapnik maps
• fixes the performance issues when deleting large number of positions in tracks with lots of positions
• fixes a bug when converting routes to tracks that inserted new positions in unpredictable order
• fixes a bug when reading NMEA 0183 Sentences (*.nmea) files where the ZDA year is encoded with 4 digits
• fixes a bug when writing Garmin POI (*.gpi) files with spaces in the position list name
• fixes a bug when writing Google Earth 5 (*.kml) speed bars with wrong speed segments
• fixes a bug when writing WebPage (*.html) files which failed to display positions
• fixes a bug when registering at the RouteConverter service that allowed empty first and last names

This is how it looks like:

RouteConverter 1.31 is ready

The latest version 1.31 from 11/11/09

• reads and writes Haicom Logger (*.csv) files
• supports the GSA sentences of NMEA 0183 Sentences (*.nmea) files
• remembers and restores the last opened category in the browse tab
• remembers and restores the order of the columns in the position list
• joins all tracks below a lap or course of Training Center Database 1 or 2 (*.tcx) files
• converts heading information for Columbus V900 Standard (.csv), GPS Tuner (*.trk) and TomTom Route (*.itn) files
• converts heading, HDOP, PDOP and VDOP information for Columbus V900 Professional (.csv) files
• converts heading, HDOP, PDOP, VDOP and satellite count information for GPX 1.0 and 1.1 (*.gpx) and NMEA 0183 Sentences (*.nmea) files

and much more...

Zusammenfassung von NMEA Sentences

Bei den vielen NMEA-Tracklogs, die ich hier zum Testen gesammelt habe, habe ich bemerkt, daß die meisten Programme nicht nur RMC-Sentences enthalten, sondern üblicherweise die 5 von RouteConverter unterstützten - GGA, RMC, WPL, ZDA und VTG - und häufig noch ein paar mehr.

Ich vermute, daß die Hersteller der Tracklogger und die Autoren der Programme möglichst alle vorhandenen Informationen erhalten und möglichst viele Programme, die die Daten nachher weiterverarbeiten, unterstützen möchten. Also schreiben sie für eine GPS-Position 3-5 Sentences mit meist redundanten Daten.

Bei Tripmaster sieht das z.B. so aus:

$GPRMC,175947.000,A,4812.0597,N,01136.4663,E,0.0,163.8,010907,,,A*62
$GPGGA,175947.000,4812.0597,N,01136.4663,E,1,07,1.4,495.3,M,,,,*09

oder bei Sonys CS1 GPS Modul

$GPGGA,180114,4808.9490,N,00928.9610,E,1,05,12.6,00616.6,M,048.0,M,,*49
$GPGSA,A,3,05,09,12,14,22,,,,,,,,19.9,12.6,15.3*0B
$GPGSV,2,1,08,05,40,250,50,09,85,036,51,22,16,285,36,17,,,00*4F
$GPGSV,2,2,08,12,57,247,49,13,,,27,30,,,39,14,16,320,35*77
$GPRMC,180114,A,4808.9490,N,00928.9610,E,000.0,000.0,160607,,,A*76
$GPVTG,000.0,T,,M,000.0,N,000.0,K,A*0D

Alle diese Sentences gelten für eine GPS-Position und werden in RouteConverter zu einer Position in der Positionstabelle zusammengefaßt. Der Code macht im Prinzip folgendes:

• Gelesen werden die Sentences GGA, RMC, WPL, ZDA und VTG. Alle anderen werden ignoriert.
• Aufeinanderfolgende Sentences mit gleicher Position (GGA, RMC, WPL) werden zusammengefaßt.
• Dazwischenliegende Sentences ohne Positionsdaten (ZDA, VTG) werden mit der davorliegenden Position zusammengefaßt.

Diese Logik erklärt sich durch die Anforderung, das Programm einfach zu halten und mit der Herkunft als Konvertierer:

• Eine Zeile in der Tabelle soll eine Position repräsentieren.
• Andere Formate bieten keine passenden Strukturen, um die NMEA-Sentences 1:1 darauf abbilden können.

One more NMEA problem solved

Abie pointed me to a very stupid bug in the NMEA processing of RouteConverter. Starting with version 1.8, I've replaced the older GPSBabel based implementation by a self written one. The intention was to

• make the processing faster
  
• interpret a wider set of NMEA sentences
• merge NMEA sentences which describe the same position

Obviously, this comes with a price: It takes some time to stabilize the code. Please try the new version 1.9.2 which solves the problem that NMEA positions in the south east are misinterpreted as south west.

1.8 is ready

The latest version 1.8 from 08/16/07

• reads and writes Navigon Mobile Navigator 5 (*.rte) files
• reads and converts date and time from GPX, Google Earth and Tripmaster ITN,GPX log files
• reads POIs that have been loaded onto or modified on a Navigon-device
• faster reads and writes NMEA 0183 sentences - by a factor of 8 to 10
• supports the NMEA 0183 sentences RMC, GGA, WPL and ZDA
• offers tooltips for the functionality to remove routes/tracks/waypoint lists from the current file
• fixes a bug which resulted in an altitude of 2147483646 metern if there was no altitude information present
• fixes a bug in the Motorrad Tourenplaner Format which left the type of waypoints empty and did not set them to zero
• fixes a bug which always led to leading and trailing spaces when editing the comments

NMEA logs

A while ago, I've implemented NMEA log support for RouteConverter by using GPSBabel. I've implemented this by converting NMEA to GPX with GPSBabel and parsing GPX. For long tracks with tens of thounds of NMEA sequences, this setup can consume a lot of time and memory.

Reimplementing this with just support for GGA sentences gave a speedup of factor 10, which shows for me that it could be worth it. On the other hand there are a lot of different sentence types.

What do you think? Is GGA and RMC enough?