diff -Nru gpsbabel-1.7.0+ds/debian/changelog gpsbabel-1.7.0+ds/debian/changelog --- gpsbabel-1.7.0+ds/debian/changelog 2020-08-07 13:38:18.000000000 +0000 +++ gpsbabel-1.7.0+ds/debian/changelog 2020-08-14 02:57:31.000000000 +0000 @@ -1,3 +1,13 @@ +gpsbabel (1.7.0+ds-5+rpi1) bullseye-staging; urgency=medium + + [changes brought forward from 1.5.4-2+rpi1 by Peter Michael Green at Thu, 26 Oct 2017 12:10:21 +0000] + * Remove armhf from architecture list for qtwebengine build-dep, + we don't have (and may never have) it in Raspbian. + * Remove armhf from architecture list for gpsbabel-gui, it + needs the aforementioned build-dep. + + -- Raspbian forward porter Fri, 14 Aug 2020 02:57:31 +0000 + gpsbabel (1.7.0+ds-5) unstable; urgency=medium * Add patch for i386 test failure diff -Nru gpsbabel-1.7.0+ds/debian/control gpsbabel-1.7.0+ds/debian/control --- gpsbabel-1.7.0+ds/debian/control 2020-07-09 20:46:34.000000000 +0000 +++ gpsbabel-1.7.0+ds/debian/control 2020-08-14 02:57:31.000000000 +0000 @@ -10,7 +10,7 @@ libusb-1.0-0-dev, zlib1g-dev, libshp-dev, qt5-default, - qtwebengine5-dev [amd64 arm64 armhf i386 mipsel], + qtwebengine5-dev [amd64 arm64 i386 mipsel], qttools5-dev-tools, imagemagick, locales-all, @@ -74,7 +74,7 @@ This package contains the detailed documentation of gpsbabel. Package: gpsbabel-gui -Architecture: amd64 arm64 armhf i386 mipsel +Architecture: amd64 arm64 i386 mipsel Depends: ${shlibs:Depends}, ${misc:Depends}, gpsbabel (= ${binary:Version}) Description: GPS file conversion plus transfer to/from GPS units - GUI GPSBabel converts waypoints, tracks, and routes from one format to diff -Nru gpsbabel-1.7.0+ds/debian/patches/auto-1.6.0+ds-3+rpi1-1edcf7f4aaa58679f27b343c3ef2291ab331699f-1564383990 gpsbabel-1.7.0+ds/debian/patches/auto-1.6.0+ds-3+rpi1-1edcf7f4aaa58679f27b343c3ef2291ab331699f-1564383990 --- gpsbabel-1.7.0+ds/debian/patches/auto-1.6.0+ds-3+rpi1-1edcf7f4aaa58679f27b343c3ef2291ab331699f-1564383990 1970-01-01 00:00:00.000000000 +0000 +++ gpsbabel-1.7.0+ds/debian/patches/auto-1.6.0+ds-3+rpi1-1edcf7f4aaa58679f27b343c3ef2291ab331699f-1564383990 2020-08-14 02:57:31.000000000 +0000 @@ -0,0 +1,7367 @@ +From: Peter Micheal Green +Subject: Automatically generated patch (1.6.0+ds-3+rpi1) + +Last (up to) 3 git changes, FYI: + +commit 1edcf7f4aaa58679f27b343c3ef2291ab331699f +Merge: 172c089 891a28a +Author: Peter Michael Green +Date: Mon Jul 29 03:02:35 2019 +0000 + + Manual merge of version 1.5.4-2+rpi1 and 1.6.0+ds-3 to produce 1.6.0+ds-3+rpi1 + +commit 891a28a8b1c29c210786597b0eaebec52e9d3338 +Merge: 6320c21 e74bcfa +Author: Jochen Sprickerhof +Date: Fri Jul 19 13:08:44 2019 +0100 + + Merge gpsbabel (1.6.0+ds-3) import into refs/heads/workingbranch + +commit 6320c21f5f37f7f46cf4f71a76cf6abef764b3e8 +Author: Jochen Sprickerhof +Date: Sun Jun 16 16:09:18 2019 +0200 + + Fix exec in gpsbabel.desktop + + + Gbp-Pq: Name 0011-Fix-exec-in-gpsbabel.desktop.patch +--- + +--- /dev/null ++++ gpsbabel-1.6.0+ds/docbook.css +@@ -0,0 +1,108 @@ ++ ++ ++/********************************/ ++/* start of styles in block.xsl */ ++ ++.formalpara-title { ++ font-weight: bold; ++} ++ ++div.blockquote-title { ++ font-weight: bold; ++ margin-top: 1em; ++ margin-bottom: 1em; ++} ++ ++span.msgmain-title { ++ font-weight: bold; ++} ++ ++span.msgsub-title { ++ font-weight: bold; ++} ++ ++span.msgrel-title { ++ font-weight: bold; ++} ++ ++div.msglevel, div.msgorig, div.msgaud { ++ margin-top: 1em; ++ margin-bottom: 1em; ++} ++ ++span.msglevel-title, span.msgorig-title, span.msgaud-title { ++ font-weight: bold; ++} ++ ++div.msgexplan { ++ margin-top: 1em; ++ margin-bottom: 1em; ++} ++ ++span.msgexplan-title { ++ font-weight: bold; ++} ++ ++/* end of styles in block.xsl */ ++/********************************/ ++ ++/********************************/ ++/* start of styles in autotoc.xsl */ ++ ++ ++/* end of styles in autotoc.xsl */ ++/********************************/ ++ ++/********************************/ ++/* start of styles in formal.xsl */ ++ ++div.figure-title { ++ font-weight: bold; ++} ++ ++div.example-title { ++ font-weight: bold; ++} ++ ++div.equation-title { ++ font-weight: bold; ++} ++ ++div.table-title { ++ font-weight: bold; ++} ++ ++div.sidebar-title { ++ font-weight: bold; ++} ++ ++ ++/* end of styles in formal.xsl */ ++/********************************/ ++ ++/********************************/ ++/* start of styles in verbatim.xsl */ ++ ++div.programlisting { ++ white-space: pre; ++ font-family: monospace; ++} ++ ++div.screen { ++ white-space: pre; ++ font-family: monospace; ++} ++ ++div.synopsis { ++ white-space: pre; ++ font-family: monospace; ++} ++ ++/* end of styles in verbatim.xsl */ ++/********************************/ ++ ++/* footnote rule */ ++hr.footnote-hr { ++ width: 100; ++} ++ +--- /dev/null ++++ gpsbabel-1.6.0+ds/gpsbabel.html +@@ -0,0 +1,7223 @@ ++ ++GPSBabel Documentation

GPSBabel Documentation

Table of Contents
Introduction to GPSBabel
The Problem: Too many incompatible GPS file formats
The Solution
1. Getting or Building GPSBabel
Downloading - the easy way.
Building from source.
2. Usage
Invocation
Suboptions
Advanced Usage
Route and Track Modes
Working with predefined options
Realtime tracking
Batch mode (command files)
List of Options
3. The Formats
? Character Separated Values (xcsv)
Alan Map500 tracklogs (.trl) (alantrl)
Alan Map500 waypoints and routes (.wpr) (alanwpr)
All database fields on one tab-separated line (tabsep)
Brauniger IQ Series Barograph Download (baroiq)
Bushnell GPS Trail file (bushnell_trl)
Bushnell GPS Waypoint file (bushnell)
Cambridge/Winpilot glider software (cambridge)
CarteSurTable data file (cst)
Columbus/Visiontac V900 files (.csv) (v900)
Comma separated values (csv)
CompeGPS data files (.wpt/.trk/.rte) (compegps)
Custom "Everything" Style (custom)
Data Logger iBlue747 csv (iblue747)
Data Logger iBlue757 csv (iblue757)
DeLorme .an1 (drawing) file (an1)
DeLorme GPL (gpl)
DeLorme Street Atlas Plus (saplus)
DeLorme Street Atlas Route (saroute)
DeLorme XMap HH Native .WPT (xmap)
DeLorme XMap/SAHH 2006 Native .TXT (xmap2006)
DeLorme XMat HH Street Atlas USA .WPT (PPC) (xmapwpt)
Destinator Itineraries (.dat) (destinator_itn)
Destinator Points of Interest (.dat) (destinator_poi)
Destinator TrackLogs (.dat) (destinator_trl)
EasyGPS binary format (easygps)
Embedded Exif-GPS data (.jpg) (exif)
Energympro GPS training watch (energympro)
Enigma binary waypoint file (.ert) (enigma)
F90G Automobile DVR GPS log file (f90g)
FAI/IGC Flight Recorder Data Format (igc)
Flexible and Interoperable Data Transfer (FIT) Activity file (garmin_fit)
FlySight GPS File (flysight)
Franson GPSGate Simulation (gpssim)
Fugawi (fugawi)
G7ToWin data files (.g7t) (g7towin)
Garmin 301 Custom position and heartrate (garmin301)
Garmin G1000 datalog input filter file (garmin_g1000)
Garmin Logbook XML (glogbook)
Garmin MapSource - gdb (gdb)
Garmin MapSource - mps (mapsource)
Garmin MapSource - txt (tab delimited) (garmin_txt)
Garmin PCX5 (pcx)
Garmin POI database (garmin_poi)
Garmin Points of Interest (.gpi) (garmin_gpi)
Garmin serial/USB protocol (garmin)
Garmin Training Center (.tcx) (gtrnctr)
Garmin Training Center (.xml) (gtrnctr)
Geocaching.com .loc (geo)
Geogrid-Viewer ascii overlay file (.ovl) (ggv_ovl)
Geogrid-Viewer binary overlay file (.ovl) (ggv_bin)
Geogrid-Viewer tracklogs (.log) (ggv_log)
GeoJson (geojson)
GEOnet Names Server (GNS) (geonet)
GlobalSat DG-100/BT-335 Download (dg-100)
GlobalSat DG-200 Download (dg-200)
GlobalSat GH625XT GPS training watch (globalsat)
Google Directions XML (googledir)
Google Earth (Keyhole) Markup Language (kml)
Google Navigator Tracklines (.trl) (gnav_trl)
GoPal GPS track log (.trk) (gopal)
GPS Tracking Key Pro text (land_air_sea)
GPS TrackMaker (gtm)
GPSBabel arc filter file (arc)
GpsDrive Format (gpsdrive)
GpsDrive Format for Tracks (gpsdrivetrack)
GPSman (gpsman)
gpsutil (gpsutil)
GPX XML (gpx)
HikeTech (hiketech)
Holux (gm-100) .wpo Format (holux)
Holux M-241 (MTK based) Binary File Format (m241-bin)
Holux M-241 (MTK based) download (m241)
Honda/Acura Navigation System VP Log File Format (vpl)
HTML Output (html)
Humminbird tracks (.ht) (humminbird_ht)
Humminbird waypoints and routes (.hwr) (humminbird)
IGN Rando track files (ignrando)
iGo Primo points of interest (.upoi) (igoprimo_poi)
iGO2008 points of interest (.upoi) (igo2008_poi)
IGO8 .trk (igo8)
Jelbert GeoTagger data file (jtr)
Jogmap.de XML format (jogmap)
Kompass (DAV) Track (.tk) (kompass_tk)
Kompass (DAV) Waypoints (.wp) (kompass_wp)
KuDaTa PsiTrex text (psitrex)
Lowrance USR (lowranceusr)
Lowrance USR version 4 (lowranceusr4)
Magellan Explorist Geocaching (maggeo)
Magellan Mapsend (mapsend)
Magellan SD files (as for eXplorist) (magellanx)
Magellan SD files (as for Meridian) (magellan)
Magellan serial protocol (magellan)
MagicMaps IK3D project file (.ikt) (ik3d)
Mainnav (mainnav)
Map&Guide 'TourExchangeFormat' XML (tef)
MapAsia track file (.tr7) (mapasia_tr7)
Mapbar (China) navigation track for Sonim Xp3300 (mapbar)
Mapfactor Navigator (mapfactor)
Mapopolis.com Mapconverter CSV (mapconverter)
MapTech Exchange Format (mxf)
MediaTek Locus (mtk_locus)
Memory-Map Navigator overlay files (.mmo) (mmo)
Microsoft Streets and Trips 2002-2007 (s_and_t)
MiniHomer, a skyTraq Venus 6 based logger (download tracks, waypoints and get/set POI) (miniHomer)
Mobile Garmin XT Track files (garmin_xt)
Motoactiv CSV (motoactv)
Motorrad Routenplaner (Map&Guide) .bcr files (bcr)
MTK Logger (iBlue 747,...) Binary File Format (mtk-bin)
MTK Logger (iBlue 747,Qstarz BT-1000,...) download (mtk)
MyNav TRC format (mynav)
National Geographic Topo .tpg (waypoints) (tpg)
National Geographic Topo 2.x .tpo (tpo2)
National Geographic Topo 3.x/4.x .tpo (tpo3)
Navicache.com XML (navicache)
Navigon Mobile Navigator .rte files (nmn4)
Navigon Waypoints (navigonwpt)
NaviGPS GT-11/BGT-11 Download (navilink)
NaviGPS GT-31/BGT-31 datalogger (.sbp) (sbp)
NaviGPS GT-31/BGT-31 SiRF binary logfile (.sbn) (sbn)
Naviguide binary route file (.twl) (naviguide)
Navitel binary track (.bin) (navitel_trk)
Navitrak DNA marker format (dna)
NetStumbler Summary File (text) (netstumbler)
NIMA/GNIS Geographic Names File (nima)
NMEA 0183 sentences (nmea)
Nokia Landmark Exchange (lmx)
OpenStreetMap data files (osm)
OziExplorer (ozi)
PocketFMS breadcrumbs (pocketfms_bc)
PocketFMS flightplan (.xml) (pocketfms_fp)
PocketFMS waypoints (.txt) (pocketfms_wp)
Raymarine Waypoint File (.rwf) (raymarine)
Ricoh GPS Log File (ricoh)
See You flight analysis data (cup)
Skymap / KMD150 ascii files (skyforce)
SkyTraq Venus based loggers (download) (skytraq)
SkyTraq Venus based loggers Binary File Format (skytraq-bin)
SubRip subtitles for video mapping (.srt) (subrip)
Suunto Trek Manager (STM) .sdf files (stmsdf)
Suunto Trek Manager (STM) WaypointPlus files (stmwpp)
Swiss Map 25/50/100 (.xol) (xol)
Tab delimited fields useful for OpenOffice, Ploticus etc. (openoffice)
Teletype [ Get Jonathon Johnson to describe (teletype)
Textual Output (text)
TomTom Itineraries (.itn) (tomtom_itn)
TomTom Places Itineraries (.itn) (tomtom_itn_places)
TomTom POI file (.asc) (tomtom_asc)
TomTom POI file (.ov2) (tomtom)
TopoMapPro Places File (tmpro)
TrackLogs digital mapping (.trl) (dmtlog)
U.S. Census Bureau Tiger Mapping Service (tiger)
Universal csv with field structure in first line (unicsv)
Vcard Output (for iPod) (vcard)
VidaOne GPS for Pocket PC (.gpb) (vidaone)
Vito Navigator II tracks (vitosmt)
Vito SmartMap tracks (.vtt) (vitovtt)
WiFiFoFum 2.0 for PocketPC XML (wfff)
Wintec TES file (wintec_tes)
Wintec WBT-100/200 Binary File Format (wbt-bin)
Wintec WBT-100/200 GPS Download (wbt)
Wintec WBT-201/G-Rays 2 Binary File Format (wbt-tk1)
XAiOX iTrackU Logger (itracku)
XAiOX iTrackU Logger Binary File Format (itracku-bin)
Yahoo Geocode API data (yahoo)
4. Data Filters
Add points before and after bends in routes (bend)
Include Only Points Inside Polygon (polygon)
Include Only Points Within Distance of Arc (arc)
Include Only Points Within Radius (radius)
Interpolate between trackpoints (interpolate)
Manipulate altitudes (height)
Manipulate track lists (track)
Rearrange waypoints by resorting (sort)
Remove all waypoints, tracks, or routes (nuketypes)
Remove Duplicates (duplicate)
Remove Points Within Distance (position)
Remove unreliable points with high hdop or vdop (discard)
Reverse stops within routes (reverse)
Save and restore waypoint lists (stack)
Simplify routes (simplify)
Swap latitude and longitude of all loaded points (swap)
Transform waypoints into a route, tracks into routes, ... (transform)
Validate internal data structures (validate)
A. Supported Datums
B. Garmin Icons
C. GPSBabel XCSV Style Files
Introduction to GPSBabel Styles
Style file overview
Internal Constants
Global Properties of the File
GPSBabel Behavior Directives
Defining the Layout of the File
Defining Fields Within the File
Examples
Miscellaneous Notes
Glossary
List of Tables
3.1. Grid values for garmin_txt
3.2. Supported distance units (garmin_gpi)
3.3. Supported speed units (garmin_gpi)
3.4. Track point structure (16 bytes)
3.5. Devices supported by miniHomer module
3.6. Devices supported by MTK module
3.7. Devices supported by skytraq module
3.8. Supported format characters for subrip
3.9. Vito SmartMap track file header (8 bytes)
3.10. Vito SmartMap track point (32 bytes)
List of Examples
2.1. Command showing Linux download from Magellan serial and writing to .loc file
2.2. Command showing Windows download from Magellan serial and writing to .loc file
2.3. Merging multiple files into one
2.4. Merging multiple files of differing types.
2.5. Writing the same data in multiple output formats.
2.6. Read realtime positioning from Garmin USB, write to Keyhole Markup
2.7. Read realtime positioning from Wintec WBT-201 via Bluetooth on Mac, write to Keyhole Markup
3.1. Command showing writing to Bushnell files
3.2. Conversion of a v900 csv log file to a gpx format
3.3. Conversion of a v900 csv log file to a gpx 1.1 format
3.4. Example 'csv' file
3.5. Example for gdb bitcategory option to put all waypoints in categories 1 and 16.
3.6. Using gdb option roadbook to create simple html roadbook
3.7. Command showing garmin_txt output with all options
3.8. Command showing garmin_gpi output example
3.9. Read GPX file, create GPI to alert when you're 1/2 mile from a speed camera.
3.10. Example for garmin bitcategory option to put all waypoints in categories 1 and 16.
3.11. Command showing DG-100 download and erase on Linux
3.12. Command showing DG-100 erase_only option on Linux
3.13. Command showing DG-200 download and erase on Linux
3.14. Command showing DG-200 erase_only option on Linux
3.15. Command showing list of tracks on device
3.16. Command track can be used to fetch a single track, defult is all tracks
3.17. Command showing list of tracks on device
3.18. Command track can be used to fetch a single track, defult is all tracks
3.19. Forcing creation of old Mobile Mapper files
3.20. Command showing miniHomer download of tracks and erasing the logger on Linux
3.21. Command showing miniHomer erasing the logger without download on Linux
3.22. Command showing miniHomer setting Car and Home POI
3.23. Command showing how to read data from an erased device
3.24. Set the target location of the miniHomer Home POI
3.25. Set the target location of the miniHomer Car POI
3.26. Set the target location of the miniHomer Boat POI
3.27. Set the target location of the miniHomer Heart POI
3.28. Set the target location of the miniHomer Bar POI
3.29. Sample BCR command with all options
3.30. Convert MTK binary trackpoints to GPX
3.31. Command showing MTK download track and waypoints and erase on Linux
3.32. Command showing skytraq download of tracks and erasing the logger on Linux
3.33. Command showing skytraq erasing the logger without download on Linux
3.34. Command showing skytraq download tracks via bluetooth on Linux
3.35. Set the target location of the Skytraq location finder
3.36. Set the logging parameters for Skytraq device
3.37. Command showing how to read data from an erased device
3.38. Example for splitoutput option to text format
3.39. Example for unicsv format option to write names of input formats.
3.40. Example for unicsv filename option to write filenames of input formats.
3.41. Example for unicsv fields option to describe input file.
3.42. Command showing conversion of a Wintec binary file to GPX
3.43. Command showing WBT-200 download and erase over Bluetooth on Mac OS X
3.44. Command showing conversion of a Wintec binary file to GPX
3.45. Command showing a download from itracku connected to com14.
3.46. Command showing a download from itracku with automatic port detection.
3.47. Download from the data logger while and append the new binary logger data to a backup file. Read the contents of the backup file.
3.48. Download from the data logger and append the new logger data to a backup file. Output only the new ++ waypoints.
3.49. Command showing reading an itracku data file.
4.1. Using the polygon filter
4.2. Using the polygon and arc filters to find points in or nearly in a ++polygon
4.3. Using the arc filter
4.4. Using the radius filter to find points close to a given point
4.5. Using the interpolate filter
4.6. This option subtracts the WGS84 geoid height from every altitude. For GPS receivers like the iBlue747 the result is the height above mean see level.
4.7. This options adds a constant value to every altitude.
4.8. Time-shifting a track with the track filter
4.9. Merging tracks with the track filter
4.10. Extracting a period of time with the track filter
4.11. Replace time values of a track
4.12. Add time values to a track
4.13. Merging tracks with missing timestamps with the track filter
4.14. Filtering data types with nuketypes
4.15. Using the duplicate filter to suppress points with the same ++ name and location
4.16. Using the duplicate filter to implement an "ignore list."
4.17. Using the duplicate filter to correct the locations of "puzzle" ++geocaches
4.18. Using the position filter to suppress close points
4.19. Using the discard filter for HDOP and VDOP.
4.20. Using the discard filter to require at least three satellites.
4.21. Discarding specific point by regular expression
4.22. Converting a track to a sequence of waypoints
4.23. Converting a pile of waypoints to a GPX route
4.24. Converting a pile of waypoints to a GPX track
4.25. Convert a GPX track to a GPX route, deleting the original track, using 2 digits for the generated numbers.
4.26. Convert a GPX track to a GPX route, deleting the original track, naming the generated points like the original track name.
4.27. Convert a GPX track to GPX waypoints, tossing the original track

Introduction to GPSBabel

Table of Contents
The Problem: Too many incompatible GPS file formats
The Solution

The Problem: Too many incompatible GPS file formats

There are simply too many gratuitously different file formats ++to hold waypoint, track, and route information in various programs ++used by computers and GPS receivers. ++GPX defines a ++standard in XML to contain all the data, but there are too many ++programs that don't understand it yet and too much data in ++alternate formats. ++

++Perhaps you have an Explorist 600 and your friend has a StreetPilot 2720. ++You've collected a list of your favorite locations as waypoints and you'd ++like to be able to share them. Unfortunately, his copy of Garmin Mapsource ++won't read data created by your copy of Magellan Mapsend DirectRoute. What you need ++is a program that converts data bewteen the two programs. ++

++GPSBabel actually solves that problem for you and much more... ++

The Solution

The original author of GPSBabel, Robert Lipe, needed to convert waypoints between a couple of formats, so he ++whipped up a converter and designed it upon an extensible foundation so ++that it was easy to add new formats and made the program freely available. Many others have contributed to the program since then.

Most file formats added so far have taken under 200 ++ lines of reasonable ISO C so they can be stamped ++ out pretty trivially. Formats that are ASCII text delimited in some ++ fixed way can be added with no programming at all via our ++ style mechanism. ++

Chapter 1. Getting or Building GPSBabel

Table of Contents
Downloading - the easy way.
Building from source.

Downloading - the easy way.

++GPSBabel is distributed "ready to run" on most common ++operating systems via the ++download page. ++

As GPSBabel runs on a wide variety of operating systems, ++be sure to visit the ++OS-Specific notes for ++additional information. ++

Building from source.

++ For operating systems where no binary is provided or if ++you want the latest development version, you will have to build it from ++source. The code should be compilable on any system with ++ISO C++. It's tested on Linux, Mac OS/X, and Windows cross compilers. ++Less frequently, someone will build on MSVC, FreeBSD, OpenBSD, Solaris, ++etc. Both Clang/LLVM and GNU C++ are regularly exercised. ++

++You can grab a release from the GPSBabel download page, but if you're going to be doing any development, you'll find that working from the GPSBabel Github repo is easier. Checkouts vis Git, HTTPS, SSH, and Subversion are supported. ++

++ In most cases, the code is as simple to build as running: ++

./configure && make

Qt ++is required for all builds. Mac and Windows users can download ++binaries from Qt Downloads ++Fedora or CentOS users may need to 'yum install qt-devel'. Optionally, use qt5-base. When in doubt, 'yum search qt' or 'yum search qt5' can help you find the correct package name ++Ubuntu users may need to 'apt-get install libqt4-core libqt4-dev'. ++Qt versions 4.6 and newer are supported. ++

libusb ++is recommended for OS/X and Linux if you want to use a USB Garmin or ++Delorme device. ++Fedora users may need to 'yum install libusb-devel'. Ubuntu users may ++need to 'yum install libusb-dev'. ++

There are additional flags that can be passed to configure to ++ customize your build of GPSBabel. ++

./configure --help

++lists all the supported options, but of interest we have:

++ --disable-shapefile Excludes the shapefile support. ++

++ --disable-csv Excludes all support for our something-separated formats. ++

++ --disable-filters Excludes all filter support. ++

++ --enable-efence Activate debugging mode for gpsbabel-debug. ++

++ --with-doc=dir Specifies that the doc should be created and installed in dir. ++

++ --without-libusb Disables use of libusb, even it's it's available. ++

++ --with-zlib=(included)|system|no By default, we use our own version of zlib. If you specify system the system zlib is used. A value of no (or --without-zlib) disables zlib. ++

Chapter 2. Usage

Table of Contents
Invocation
Suboptions
Advanced Usage
Route and Track Modes
Working with predefined options
Realtime tracking
Batch mode (command files)
List of Options

Invocation

++If you're using GPSBabel, you will need to know how to do at least two things: ++read data from a file, and write it to another file. There are four basic ++options you need to know to do those things: ++

CommandMeaning
-i formatSet input format
-f filenameRead file
-o formatSet output format
-F filenameWrite output file

Important

++Case matters. Notably -f (lowercase) sets the input file. -F (uppercase) sets the output file. ++

++The format parameters in the above list ++refer to the names of formats or file types supported by GPSBabel. ++

gpsbabel -?

will always show you the supported file types. In this document, the ++various supported formats are listed in Chapter 3, The Formats. The ++name that you would use on the command line follows the format name in ++parentheses. ++

++Options are always processed in order from left to right. ++In practical terms, this means that things you want to read should appear ++in the command before things you want to write. This sometimes surprises ++new users as adding options to turn on debugging at the end, for example, ++doesn't work as the debugging is turned on after all the interesting work is ++done. The reason for this strict ordering becomes more apparent once you ++learn about mixing formats and filters. ++

++The filename parameters specify the ++name of a file to be read or written. ++

To use ++ GPSBabel in its simplest form, just tell it what you're reading, where to read ++ it from, what you're writing, and what to write it to. For ++ example:

gpsbabel -i geo -f /tmp/geocaching.loc -o gpx -F /tmp/geocaching.gpx

tells it to read the file /tmp/geocaching.loc in geocaching.com ++ format and create a new file /tmp/geocaching.gpx in GPX format. It's important to note that the names have nothing to do with the formats actually used.

This command will read from a Magellan unit attached ++ to the first serial port on a Linux system (device names will ++ vary on other OSes; typically COMx: on WIndows) and write them as a geocaching loc file.

Example 2.1. Command showing Linux download from Magellan serial and writing to .loc file

gpsbabel -i magellan -f /dev/ttyS0 -o geo -F mag.loc


This second command does the same on Microsoft Windows.

Example 2.2. Command showing Windows download from Magellan serial and writing to .loc file

gpsbabel -i magellan -f com1 -o geo -F mag.loc


Optionally, you may specify -s in any command line. This ++ causes the program to ignore any "short" names that may be ++ present in the source data format and synthesize one from the ++ long name. This is particularly useful if you're writing to ++ a target format that isn't the lowest common denominator but ++ the source data was written for the lowest common ++ denominator. This is useful for writing data from geocaching.com ++ to a GPS so my waypoints have "real" names instead of ++ the 'GC1234' ones that are optimized for receivers of the lowest ++ common denominator. ++ A geocacher using Linux with a Magellan receiver may thus find commands ++ like this useful.

gpsbabel -s -i geo -f geocaching.loc -o magellan -F /dev/ttyS0

His counterpart on Windows will find this equivalent

gpsbabel -s -i geo -f geocaching.loc -o magellan -F com1

Suboptions

++ Many of the available format options in GPSBabel can themselves ++ take options. While we try to make all the formats do the most ++ sensible thing possible without any extra options; this allows ++ great power and flexibility in the operation of the program. ++

++ Suboptions are comma separated and immediately follow the option ++ itself. The available suboptions are listed on the individual ++ format pages. We'll make an example from the section called “Google Earth (Keyhole) Markup Language (kml)”: ++

gpsbabel -i gpx -f file.gpx -o kml,deficon="file://myicon.png",lines=0 -F one.kml -o kml -F two.kml

++ This command will read the GPX file file.gpx ++ and create two KML files. one.kml will ++ have the given icon and no lines between track and routepoints. ++ two.kml will be created with the defaults used ++ in the KML writer. ++

++ Suboptions for the various formats allow you to change serial speeds, ++ pass arguments to filters, change the type of file written, override ++ icon defaults, and lots of other things. The suboptions for each ++ filetype are documented on the page in this document that describes ++ the option itself. ++

Advanced Usage

Argument are processed in the order they appear on the command ++line and are translated internally into a pipeline that data flows ++through when executed. Normally one would:

read from one input
optionally apply filters
write into one output

but GPSBabel is flexible enough to allow more complicated ++operations such as reading from several files (potentially of ++different types), applying a filter, reading more data, then writing the ++merged data to multiple destinations. ++

The input file type remains unchanged until a new ++ -i argument is seen. ++ Files are read in the order they appear. So you could merge ++ three input files into one output file with:

Example 2.3. Merging multiple files into one

gpsbabel -i geo -f 1.loc -f 2.loc -f 3.loc -o geo -F big.loc


You can merge files of different types:

Example 2.4. Merging multiple files of differing types.

gpsbabel -i geo -f 1.loc -i gpx -f 2.gpx -i pcx 3.pcx -o gpsutil -F big.gps


Example 2.5. Writing the same data in multiple output formats.

You can write the same data in different output formats:

gpsbabel -i geo -f 1.loc -o gpx -F 1.gpx -o pcx -F 1.wpt


If you want to change the character set of input or/and ++ output side you can do this with the option -c ++ <character set>. You can get a complete list ++ of supported character sets with "gpsbabel -l". To change ++ the character set on both sides you should do this:

gpsbabel -i xcsv,style=foo.style -c latin1 -f foo -o xcsv,style=bar.style -c ms-ansi -F bar

Note, that some formats have a fixed character set and ignore this option.

Route and Track Modes

Most formats supported by GPSBabel will make a reasonable attempt to work ++ transparently with waypoints, tracks, and routes. Some ++ formats, like garmin and magellan require the -t flag to work with tracks and ++ -r to work with ++ routes. -w is for ++ waypoints, and is the default. So if you wanted to read all ++ data from a Magellan Meridian GPS receiver into a gpx file, you might use a command ++ like:

gpsbabel -t -r -w -i magellan -f com1: -o gpx -F backup.gpx

Tracks and routes are advanced features and don't try ++ to handle every possible hazard that can be encountered ++ during a conversion. If you're merging or converting files ++ of similar limitations, things work very well.

Many of those hazards can be overcome with our filters ++ but there are often compromises to be made. For example, if you ++ have a GPX route that contains 150 turn points but you're sending ++ the route to a GPS receiver that supports only 30 turnpoints, something has ++ to go. One might use our 'simplify' filter to produce a route that ++ retained the 30 most mathematically significant turnpoints but that ++ may not really be the route you had in mind. ++

Tracks and routes will sometimes be converted to a ++ list of waypoints when necessary, One example is when writing into one ++ of the CSV formats. The inverse operation is not supported ++ right now, so reading the converted track back from CSV will ++ always result in a list of waypoints, not the original track. ++

The presence of -s on the command line tends to ++ creats havoc on tracks and routes since many of these formats ++ rely on internal linkages between such points and renaming ++ them may break those linkages. In general, don't use ++ -s when tracks or ++ routes are present. ++

Working with predefined options

++ GPSBabel can read a file on startup to set defaults for options. All ++ module and filter options may be set this way. ++

++ The format of the file is identical to the inifile-format often seen ++ on Windows. Here is an example: ++

[Common format settings]
snupper=Y
snlen=10
[gpx]
gpxver=1.1
[magellan]
baud=115200
[tiger]
[Garmin categories]
; any # from 1 to 16
1=fixed waypoints
2=temporary waypoints

++ Each section of the file starts with a '[section]' header followed by any ++ number of lines formatted option=value. Leading and trailing whitespace ++ will be ++ automatically removed from header, option and value items. ++ ++ Lines starting ++ with '#' or ';' will be treated as comments and ignored. ++

++ There are three optional sections. ++

  • Common format settings.

    Any option from any of the formats listed here will be used by ++ GPSBabel unless explicitly provided on the command line. ++

  • Common filter settings.

    As above, but for filters.

  • Garmin categories

    This allows you to give readable names to the numeric categories ++ used internally in some Garmin devices and the Mapsource formats ++ such as GDB and MPS. This is information is also used by our GPX ++ and garmin_txt formats as well.

++

++ By default, GPSBabel tries at startup to load the file named ++ gpsbabel.ini from the following locations: ++

  • current working directory

  • Windows: all paths "APPDATA", "WINDIR", "SYSTEMROOT" declared in environment.

  • Unix like OS'ses: ${HOME}/.gpsbabel/, /usr/local/etc/ and /etc/

++ If the -p option is specified, the above locations are not searched. ++ Only the filename specified by that option will be used. ++

++ There may be situations where predefined values are not useable ++ (i.e. wrapper applications using GPSBabel in the background). ++ The inifile mechanism can be disabled with an empty filename. ++

gpsbabel -p "" -i gpx -f something.gpx -o tiger -F -

Realtime tracking

++ Introduced in GPSBabel 1.3.1, we now have an experimental feature for realtime tracking via the new -T option. This reads position reports from selected formats and writes an output file when a position report is received. ++

++ As of this writing, Garmin's PVT ++ protocol and ++ NMEA are supported ++ inputs. KML, NMEA, and the various XCSV formats are supported on ++ output. Additional formats may be added by interested parties ++ later. ++

Example 2.6. Read realtime positioning from Garmin USB, write to Keyhole Markup

gpsbabel -T -i garmin -f usb: -o kml -F xxx.kml

++ Will read the USB-connected Garmin and rewrite 'xxx.kml' atomically, ++ suitable for a self-refreshing network link in Google Earth. ++


Example 2.7. Read realtime positioning from Wintec WBT-201 via Bluetooth on Mac, write to Keyhole Markup

gpsbabel -T -i nmea -f /dev/cu.G-Rays2-SPPslave-1 -o kml -F xxx.kml

++ Will read the Wintec WBT-201 via Bluetooth, using the name that ++ the Mac assigned it, and rewrite 'xxx.kml' atomically, ++ suitable for a self-refreshing network link in Google Earth. ++


++ Be sure to substitute an device name appropriate for your device ++ and OS, such as /dev/cu.usbserial or ++ /dev/cu.BT-GPS-37A695-BT-GPSCOM-1 ++ for Mac, COM23: for Windows, or ++ usb: for ++ Garmin USB. These names ++ (except the "usb:" parlance for Garmin USB) are assigned by ++ your operating system. ++ ++

Batch mode (command files)

++ In addition to reading arguments from the command line, GPSBabel can ++ read directions from batch (or command) files via the -b option. ++

++ These files are ideal for holding long command lines, long file lists, complex filters ++ and so on. You can use all GPSBabel options and combinations when writing ++ such files. Nesting batch files by using the -b option within a batch file is supported. ++

++ Here is an example demonstrating segmenting a large command line ++ by placing the input and filtering directives in a file called 'all_my_files'. ++

gpsbabel -b all_my_files -o gdb -F all_my_tracks.gdb

++ 'all_my_files' could look like this: ++

-i gpx
-f saxony_in_summer_2004.gpx -f austria_2005.gpx
-i gdb
-f croatia_2006.gdb
-x nuketypes,waypoints,routes
-x track,pack,split,title="LOG # %Y%m%d"

List of Options

++ The complete list of available options to GPSBabel can be obtained by ++ running gpsbabel -h. While there are a number of ++ options, most people will not use most of them, so don't be intimidated. ++

-p Read preferences file. On startup, GPSBabel will look for a file named gpsbabel.ini containing preferences you have provided. This option lets you pick a different files. See the section called “Working with predefined options” for more info.

-s Write "smart" names. This option influences some - but not all - of our writers to try to build "smart" waypoint names. For example, in modules that know about geocaching, it may replace "GC1234" with the actual name of the geocache.

-r Work on routes. This option has a subtly different meaning in different cases. As the very first formats in GPSBabel were for serial GPSes and routes and tracks were large and thus time-consuming to transfer, the default was waypoints only with this option to turn on the extra data. Some of our file formats use this option to mean "work only on routes, even if you have tracks/waypoints", but we're trying to discourage that behavior and in most cases, consider it a bug.

-t Work on tracks. See -r for excuses.

-w Work on waypoints. This is the default.

-T Enable Realtime tracking. This option isn't supported by the majority of our file formats, but repeatedly reads location from a GPS and writes it to a file as described in the section called “Realtime tracking”

-b Process batch file. In addition to reading arguments from the command line, we can read them from files containing lists of commands as described in the section called “Batch mode (command files)”

-c Select character set. This option lets you chose the character set. You can get a list of supported character sets via -l

-N Control "smart" output. The -N actually has two subtoptions, -Ni and -Ns. This lets you control whether a given writer will choose smart icons and names, respectively. The option -N by itself selects both.

-x filter Run filter. This option lets use use one of of our many data filters. Position of this in the command line does matter - remember, we process left to right.

-D Enable debugging. Not all formats support this. It's typically better supported by the various protocol modules because they just plain need more debugging. This option may be followed by a number. Zero means no debugging. Larger numbers mean more debugging.

-l Print character sets.

-h-? Print help.

-V Print version number.

Chapter 3. The Formats

Table of Contents
? Character Separated Values (xcsv)
Alan Map500 tracklogs (.trl) (alantrl)
Alan Map500 waypoints and routes (.wpr) (alanwpr)
All database fields on one tab-separated line (tabsep)
Brauniger IQ Series Barograph Download (baroiq)
Bushnell GPS Trail file (bushnell_trl)
Bushnell GPS Waypoint file (bushnell)
Cambridge/Winpilot glider software (cambridge)
CarteSurTable data file (cst)
Columbus/Visiontac V900 files (.csv) (v900)
Comma separated values (csv)
CompeGPS data files (.wpt/.trk/.rte) (compegps)
Custom "Everything" Style (custom)
Data Logger iBlue747 csv (iblue747)
Data Logger iBlue757 csv (iblue757)
DeLorme .an1 (drawing) file (an1)
DeLorme GPL (gpl)
DeLorme Street Atlas Plus (saplus)
DeLorme Street Atlas Route (saroute)
DeLorme XMap HH Native .WPT (xmap)
DeLorme XMap/SAHH 2006 Native .TXT (xmap2006)
DeLorme XMat HH Street Atlas USA .WPT (PPC) (xmapwpt)
Destinator Itineraries (.dat) (destinator_itn)
Destinator Points of Interest (.dat) (destinator_poi)
Destinator TrackLogs (.dat) (destinator_trl)
EasyGPS binary format (easygps)
Embedded Exif-GPS data (.jpg) (exif)
Energympro GPS training watch (energympro)
Enigma binary waypoint file (.ert) (enigma)
F90G Automobile DVR GPS log file (f90g)
FAI/IGC Flight Recorder Data Format (igc)
Flexible and Interoperable Data Transfer (FIT) Activity file (garmin_fit)
FlySight GPS File (flysight)
Franson GPSGate Simulation (gpssim)
Fugawi (fugawi)
G7ToWin data files (.g7t) (g7towin)
Garmin 301 Custom position and heartrate (garmin301)
Garmin G1000 datalog input filter file (garmin_g1000)
Garmin Logbook XML (glogbook)
Garmin MapSource - gdb (gdb)
Garmin MapSource - mps (mapsource)
Garmin MapSource - txt (tab delimited) (garmin_txt)
Garmin PCX5 (pcx)
Garmin POI database (garmin_poi)
Garmin Points of Interest (.gpi) (garmin_gpi)
Garmin serial/USB protocol (garmin)
Garmin Training Center (.tcx) (gtrnctr)
Garmin Training Center (.xml) (gtrnctr)
Geocaching.com .loc (geo)
Geogrid-Viewer ascii overlay file (.ovl) (ggv_ovl)
Geogrid-Viewer binary overlay file (.ovl) (ggv_bin)
Geogrid-Viewer tracklogs (.log) (ggv_log)
GeoJson (geojson)
GEOnet Names Server (GNS) (geonet)
GlobalSat DG-100/BT-335 Download (dg-100)
GlobalSat DG-200 Download (dg-200)
GlobalSat GH625XT GPS training watch (globalsat)
Google Directions XML (googledir)
Google Earth (Keyhole) Markup Language (kml)
Google Navigator Tracklines (.trl) (gnav_trl)
GoPal GPS track log (.trk) (gopal)
GPS Tracking Key Pro text (land_air_sea)
GPS TrackMaker (gtm)
GPSBabel arc filter file (arc)
GpsDrive Format (gpsdrive)
GpsDrive Format for Tracks (gpsdrivetrack)
GPSman (gpsman)
gpsutil (gpsutil)
GPX XML (gpx)
HikeTech (hiketech)
Holux (gm-100) .wpo Format (holux)
Holux M-241 (MTK based) Binary File Format (m241-bin)
Holux M-241 (MTK based) download (m241)
Honda/Acura Navigation System VP Log File Format (vpl)
HTML Output (html)
Humminbird tracks (.ht) (humminbird_ht)
Humminbird waypoints and routes (.hwr) (humminbird)
IGN Rando track files (ignrando)
iGo Primo points of interest (.upoi) (igoprimo_poi)
iGO2008 points of interest (.upoi) (igo2008_poi)
IGO8 .trk (igo8)
Jelbert GeoTagger data file (jtr)
Jogmap.de XML format (jogmap)
Kompass (DAV) Track (.tk) (kompass_tk)
Kompass (DAV) Waypoints (.wp) (kompass_wp)
KuDaTa PsiTrex text (psitrex)
Lowrance USR (lowranceusr)
Lowrance USR version 4 (lowranceusr4)
Magellan Explorist Geocaching (maggeo)
Magellan Mapsend (mapsend)
Magellan SD files (as for eXplorist) (magellanx)
Magellan SD files (as for Meridian) (magellan)
Magellan serial protocol (magellan)
MagicMaps IK3D project file (.ikt) (ik3d)
Mainnav (mainnav)
Map&amp;Guide 'TourExchangeFormat' XML (tef)
MapAsia track file (.tr7) (mapasia_tr7)
Mapbar (China) navigation track for Sonim Xp3300 (mapbar)
Mapfactor Navigator (mapfactor)
Mapopolis.com Mapconverter CSV (mapconverter)
MapTech Exchange Format (mxf)
MediaTek Locus (mtk_locus)
Memory-Map Navigator overlay files (.mmo) (mmo)
Microsoft Streets and Trips 2002-2007 (s_and_t)
MiniHomer, a skyTraq Venus 6 based logger (download tracks, waypoints and get/set POI) (miniHomer)
Mobile Garmin XT Track files (garmin_xt)
Motoactiv CSV (motoactv)
Motorrad Routenplaner (Map&amp;Guide) .bcr files (bcr)
MTK Logger (iBlue 747,...) Binary File Format (mtk-bin)
MTK Logger (iBlue 747,Qstarz BT-1000,...) download (mtk)
MyNav TRC format (mynav)
National Geographic Topo .tpg (waypoints) (tpg)
National Geographic Topo 2.x .tpo (tpo2)
National Geographic Topo 3.x/4.x .tpo (tpo3)
Navicache.com XML (navicache)
Navigon Mobile Navigator .rte files (nmn4)
Navigon Waypoints (navigonwpt)
NaviGPS GT-11/BGT-11 Download (navilink)
NaviGPS GT-31/BGT-31 datalogger (.sbp) (sbp)
NaviGPS GT-31/BGT-31 SiRF binary logfile (.sbn) (sbn)
Naviguide binary route file (.twl) (naviguide)
Navitel binary track (.bin) (navitel_trk)
Navitrak DNA marker format (dna)
NetStumbler Summary File (text) (netstumbler)
NIMA/GNIS Geographic Names File (nima)
NMEA 0183 sentences (nmea)
Nokia Landmark Exchange (lmx)
OpenStreetMap data files (osm)
OziExplorer (ozi)
PocketFMS breadcrumbs (pocketfms_bc)
PocketFMS flightplan (.xml) (pocketfms_fp)
PocketFMS waypoints (.txt) (pocketfms_wp)
Raymarine Waypoint File (.rwf) (raymarine)
Ricoh GPS Log File (ricoh)
See You flight analysis data (cup)
Skymap / KMD150 ascii files (skyforce)
SkyTraq Venus based loggers (download) (skytraq)
SkyTraq Venus based loggers Binary File Format (skytraq-bin)
SubRip subtitles for video mapping (.srt) (subrip)
Suunto Trek Manager (STM) .sdf files (stmsdf)
Suunto Trek Manager (STM) WaypointPlus files (stmwpp)
Swiss Map 25/50/100 (.xol) (xol)
Tab delimited fields useful for OpenOffice, Ploticus etc. (openoffice)
Teletype [ Get Jonathon Johnson to describe (teletype)
Textual Output (text)
TomTom Itineraries (.itn) (tomtom_itn)
TomTom Places Itineraries (.itn) (tomtom_itn_places)
TomTom POI file (.asc) (tomtom_asc)
TomTom POI file (.ov2) (tomtom)
TopoMapPro Places File (tmpro)
TrackLogs digital mapping (.trl) (dmtlog)
U.S. Census Bureau Tiger Mapping Service (tiger)
Universal csv with field structure in first line (unicsv)
Vcard Output (for iPod) (vcard)
VidaOne GPS for Pocket PC (.gpb) (vidaone)
Vito Navigator II tracks (vitosmt)
Vito SmartMap tracks (.vtt) (vitovtt)
WiFiFoFum 2.0 for PocketPC XML (wfff)
Wintec TES file (wintec_tes)
Wintec WBT-100/200 Binary File Format (wbt-bin)
Wintec WBT-100/200 GPS Download (wbt)
Wintec WBT-201/G-Rays 2 Binary File Format (wbt-tk1)
XAiOX iTrackU Logger (itracku)
XAiOX iTrackU Logger Binary File Format (itracku-bin)
Yahoo Geocode API data (yahoo)

? Character Separated Values (xcsv)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is a very flexible module that can be used to read or write ++nearly any plain-text record-based waypoint file. This flexibility is ++achieved by combining this format with "style" files that describe the ++format of the waypoint files. ++

++There are several formats built in to GPSBabel that use the underlying xcsv ++machinery. Each of those formats takes the same options as the xcsv format, ++with the obvious exception of the style option. ++Those formats are all based on style files that can be found in ++the "style" directory in the GPSBabel source distribution. ++

style option

++ Full path to XCSV style file. ++

++This option specifies the style file that defines the records to be read on ++input or written on output. This is not a valid option for the various ++built-in xcsv-based styles; they have prebuilt style definitions. ++

++For information on the format of xcsv style files, see ++Appendix C, GPSBabel XCSV Style Files. ++

snlen option

++ Max synthesized shortname length. ++

++This option specifies the maximum allowable length for a short name on ++output. This option overrides the style file. ++

++Valid values for this option are 0 (off) and 1 (on). ++

snwhite option

++ Allow whitespace synth. shortnames. ++

++When this option is specified, GPSBabel will allow whitespace (spaces or tabs) ++in generated short names. This option overrides the style file. ++

++Valid values for this option are 0 (off) and 1 (on). ++

snupper option

++ UPPERCASE synth. shortnames. ++

++When this option is specified, GPSBabel will make all short names contain ++only UPPERCASE characters. This option overrides the style file. ++

++Valid values for this option are 0 (off) and 1 (on). ++

snunique option

++ Make synth. shortnames unique. ++

++When this option is specified, GPSBabel will ensure that all short names are ++unique within the output file. This option overrides the style file. ++

++Valid values for this option are 0 (off) and 1 (on). ++

urlbase option

++ Basename prepended to URL on output. ++

++This option specifies the base name to prepend to a URL on output. This ++might be useful if an input file contains URLs in a relative format and you ++need them to be in an absolute format. ++

prefer_shortnames option

++ Use shortname instead of description. ++

++This option causes GPSBabel to use the short name of the waypoint instead ++of the description. This overrides the style file. ++

++Valid values for this option are 0 (off) and 1 (on). ++

datum option

++ GPS datum (def. WGS 84). ++

++This option specifies the GPS datum to be used on read or write. Valid values for this ++option are listed in Appendix A, Supported Datums. ++

Alan Map500 tracklogs (.trl) (alantrl)

++ This format can... ++

  • ++ read and write tracks ++

++GPSBabel supports .wpr and .trl files for Alan Map500 devices running operating ++system versions 2.xx. ++

++.trl contain files tracklogs. If you use a CF-Card based ++operating system, tracklog files must have a .TRL extension when ++copied to the CF-Card. The default filename is TEMP_TRK.TRL. ++Only one .TRL file may be present. ++

++Alan's operating system 3.0 for Map500 is not supported yet. ++At the time of this writing, OS3 is still beta. ++Documentation on the new dataformats is sparse. ++

++The Alan Map500 handheld GPSr is identical to the Holux GM101. ++This GPSBabel module has only been tested against the Alan Map500. ++Still, if you use a GM101, GPSBabel will probably be able to convert ++your waypoints, routes and tracklogs. ++

++For more information on the Alan Map500 visit ++Alan Germany. There is very informative forum, too. The forum language is German but posts in English will be answered, too. ++

Alan Map500 waypoints and routes (.wpr) (alanwpr)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write routes ++

++GPSBabel supports .wpr and .trl files for Alan Map500 devices running operating ++system versions 2.xx. ++

++.wpr files contain waypoints and routes. If you use a CF-Card based ++operating system, waypoint files must have a .WPR extension when ++copied to the CF-Card. The default filename is TEMPWPRT.WPR. ++Only one .WPR file may be present. ++

++Alan's operating system 3.0 for Map500 is not supported yet. ++At the time of this writing, OS3 is still beta. ++Documentation on the new dataformats is sparse. ++

++The Alan Map500 handheld GPSr is identical to the Holux GM101. ++This GPSBabel module has only been tested against the Alan Map500. ++Still, if you use a GM101, GPSBabel will probably be able to convert ++your waypoints, routes and tracklogs. ++

++For more information on the Alan Map500 visit ++Alan Germany. There is very informative forum, too. Forum language is German but posts in English will be answered, ++too. ++

All database fields on one tab-separated line (tabsep)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++This format, like the custom format, is ++mainly used for the purpose of testing GPSBabel. It is supposed to contain ++one field for each piece of information supported by the ++xcsv format writer, but it may not be entirely ++in sync with the documentation at Appendix C, GPSBabel XCSV Style Files. ++

++For a list of fields, see the style/tabsep.style file in the GPSBabel source ++distribution. ++

Brauniger IQ Series Barograph Download (baroiq)

++ This format can... ++

  • ++ read tracks ++

Serial download protocol for the Brauniger IQ series of ++barograph recording flight instruments. This format creates a ++track of altitude vs time which can be merged with a GPS track ++of the same flight to create a three dimensional IGC file.

Bushnell GPS Trail file (bushnell_trl)

++ This format can... ++

  • ++ read and write tracks ++

++This format supports tracks from ++Bushnell GPS ++receivers, notably the Onix 400™. ++

++This format reads individual .trl files as written by the GPS. As this is ++a reverse-engineered format, it's not understood how (or even if) long ++tracks, in ++particular, span multiple files so initially this format is most effective ++on tracks under a few thousand points. ++

++ When writing tracks, a maximum of 4502 points is supported as this is the ++ most we believe these units can represent in a track. ++

++ The output base filename, converted to uppercase and stripped of ++ everything but letters and digits, is used for the trail name inside ++ the file itself. ++

Bushnell GPS Waypoint file (bushnell)

++ This format can... ++

  • ++ read and write waypoints ++

++This format supports reading and writing wayponts to ++Bushnell GPS ++receivers, notably the Onix 400™. ++

++It's an oddity for many GPSBabel norms that this format requires each ++waypoint be in a separate file. Our "output filename" argument, -F is ++modified to take an "output filename template". The output filename ++you specify will have a dash, and a sequentially increasing integer, ++and the ".wpt" extension appended to it. When the names are shown on ++the GPS itself, the shortnames from the source format are used and not these ++"made up" names. ++

Example 3.1. Command showing writing to Bushnell files

++Consider the case where 'whatever.gpx' holds three waypoints. ++ ++ gpsbabel -i gpx -f whatever.gpx -o bushnell -F /Volumes/Bushnell/WAYPOINT/whatever ++ ++will result in "whatever-0.wpt", "whatever-1.wpt", and "whatever-2.wpt" being ++created in that directory. ++Windows users may prefer the spelling: ++ ++ gpsbabel -i gpx -f whatever.gpx -o bushnell -F e:/WAYPOINT/whatever ++ ++

++At least for the 200CR, the directory name used by the device is "WAYPOINT" ++in the root directory. It's also worth mentioning that its USB Mass Storage ++protocol appears to not work on (at least) Snow Leopard 10.6.2. It's not ++known if other Onix models have a more compatible USB implementation. ++


Cambridge/Winpilot glider software (cambridge)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

Support for ++Cambridge ++and Winpilot ++ flight analysis and planning software for glider pilots.

CarteSurTable data file (cst)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

  • ++ read routes ++

With this format we can read CarteSurTable data files. ++ CarteSurTable is a shareware program widely used in France. The data ++inside have to be seen as a mixture of a waypoints list, one route and ++several tracks. ++

Columbus/Visiontac V900 files (.csv) (v900)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

Read-only support for the csv file format used by Visiontac VGPS-900™ and Columbus V-900™ GPS data loggers. These seem to be two brand names for the exact same product.

The the V-900 stores logs on a microSD card in a custom csv format. This format contains NULL characters and fixed length fields, and therefore can not be handled by the normal csv module in GPSBabel.

++Visiontac VGPS-900 ++

Example 3.2. Conversion of a v900 csv log file to a gpx format

gpsbabel -i v900 -f 09040400.csv -o gpx -F outfile.gpx


++The device support logging of trackpoints, waypoints, and voice recordings (.wav files). ++

If you create voice recording waypoints, a link (url) to the corresponding wav file is added to the waypoint. ++If you happen to use this for OpenStreetMap.org project, you can easily click on a waypoint and open the wav file from within JOSM. For this you must use gpx version 1.1 as the output file. The next example shows exactly how to do that. ++

Example 3.3. Conversion of a v900 csv log file to a gpx 1.1 format

gpsbabel -i v900 -f 09040400.csv -o gpx,gpxver=1.1 -F outfile.gpx


Comma separated values (csv)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

There are a billion variants of Comma Separated Value ++data. This is the one specifically that makes Delorme S&A Deluxe 9™ happy. It's ++also a very simple program and useful for many other programs like ++spreadsheets, but contains only a very minimal information. For general ++purpose use, you'll probably be more happy with our ++universal csv (unicsv) format.

CSV is also the correct format for ++ Lowrance MapCreate™, ++their commercial mapping program, or GDM6 (their free waypoint ++manager) for iFinder which is available at lowrance.com ++

++ On write, this format writes simple "latitude, longitude" pairs, but ++on read it will read anything supported by our human readable definition. ++

++ For something-separated data that has headers identifying the various ++ fields, see our universal csv format. ++

Example 3.4. Example 'csv' file
++35.97203, -87.13470, Mountain Bike Heaven by susy1313
++36.09068, -86.67955, The Troll by a182pilot & Family
++35.99627, -86.62012, Dive Bomber by JoGPS & family
++36.03848, -86.64862, FOSTER by JoGPS & Family
++

++that same data written in unicsv format would appear as: ++

++No,Latitude,Longitude,Name,Altitude,Description,Symbol,URL
++1,35.972033,-87.134700,"GCEBB",0.0,"Mountain Bike Heaven by susy1313","geocache","http://www.geocaching.com/seek/cache_details.asp?ID=3771"
++2,36.090683,-86.679550,"GC1A37",0.0,"The Troll by a182pilot & Family","geocache","http://www.geocaching.com/seek/cache_details.asp?ID=6711"
++3,35.996267,-86.620117,"GC1C2B",0.0,"Dive Bomber by JoGPS & family","geocache","http://www.geocaching.com/seek/cache_details.asp?ID=7211"
++4,36.038483,-86.648617,"GC25A9",0.0,"FOSTER by JoGPS & Family","geocache","http://www.geocaching.com/seek/cache_details.asp?ID=9641"
++

CompeGPS data files (.wpt/.trk/.rte) (compegps)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: deficon, index, radius, snlen .

++CompeGPS data files are those read and written by the ++CompeGPS™ TwoNav software (running on a Mac, a PC, ++or on select cell phones) as well as CompeGPS Land, and CompeGPS Air. ++These files are also used by the CompeGPS TwoNav Aventura and TwoNav Sportiva GPS receivers when they are in mass storage mode. ++

++Release 6.1 of CompeGPS Land and CompeGPS Air added GPX as an import export format for waypoints, routes, and tracks. As GPX is a more heavily used format, you should probably use that for new applications. ++

++For more information please see ++http://www.compegps.com ++

deficon option

++ Default icon name. ++

++This option specifies the default icon name on output. ++

index option

++ Index of route/track to write (if more than one in source). ++

++Because this format supports only one route or track, this option may be used ++on output to select a single route or track from a collection of routes and ++tracks read from a more expressive format. If you have, say, a ++gpx file that contains two routes, you may ++use this option to write them one at a time to individual files. ++

gpsbabel -i gpx -f routes.gpx -o compegps,index=1 -F route1.txt -o compegps,index=2 -F route2.txt

radius option

++ Give points (waypoints/route points) a default radius (proximity). ++

++This option specifies the default proximity for waypoints and route points. ++

snlen option

++ Length of generated shortnames (default 16). ++

++This option specifies the default length for short names generated on output. ++The default length is 16. ++

Custom "Everything" Style (custom)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++This format is not actually used by any real product. It is most useful ++for debugging purposes when developing a new format module for GPSBabel. ++

++To understand the contents of this file, look at the ++style/custom.style file in the GPSBabel source ++distribution as well as Appendix C, GPSBabel XCSV Style Files. ++

Data Logger iBlue747 csv (iblue747)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ This is the format used by the software that comes with the Transystem i-Blue747 GPS. ++

++ Notice that the iBlue 747 logs the sum of "height above sealevel" and "height of geoid above WGS84". If precise altitude matters to you, check out the height filter which allows you to compensate for this. ++

Data Logger iBlue757 csv (iblue757)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ This is the format used by the software that comes with the ++ ++ Transystem i-Blue757 Pro GPS ++ . ++ It is very similar to the iBlue747 ++ format, apart from the date format being reversed. ++

++ The csv log file can be extracted from the GPS receiver using ++ the BT747 software available from http://www.bt747.org ++

++Field definitions: ++

INDEX

++A sequential integer which corresponds for each logged point in the file. ++

example 3308 ++

RCR

++? ++

example 1: T ++

example 2: TD ++

DATE

++Date that the point was recorded, in the format YYYY/MM/DD ++

example: 2011/05/14 ++

TIME

++Time that the point was recorded, 24-hr format H:MM:SS. Unsure how fractions of a second are handled. ++

example: 4:15:11 ++

VALID

++? ++

example 1: DGPS ++

example 2: SPS ++

LATITUDE

++Degrees above the equator (use negative for south of the equator) ++

example: -33.803645 ++

N/S

++North (N)or South (S) of the equator ++

example: S ++

LONGITUDE

++Degrees east of the Prime Meridian (use negative for east of the Prime Meridian/Greenwich) ++

example: 150.880499 ++

E/W

++East (E) or West (W) of Greenwich ++

example: E ++

HEIGHT

++Height above sea level in metres ++

example: 99.859 m ++

SPEED

++Speed in km/h ++

example: 0.302 km/h ++

DISTANCE

++Distance covered since last point in metres ++

example: 0.30 m ++

Example File

++Example 3.X. Example 'iBlue 757' file ++


++INDEX,RCR,DATE,TIME,VALID,LATITUDE,N/S,LONGITUDE,E/W,HEIGHT,SPEED,DISTANCE
++3308,T,2011/05/14,4:15:11,DGPS,-33.803645,S,150.880499,E,99.859 m,0.207 km/h, 0.28 m
++3309,T,2011/05/14,4:15:12,DGPS,-33.803645,S,150.880499,E,100.137 m,0.362 km/h, 0.28 m
++3310,T,2011/05/14,4:15:13,DGPS,-33.803644,S,150.8805,E,100.416 m,0.302 km/h, 0.30 m
++

++

DeLorme .an1 (drawing) file (an1)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ write tracks ++

  • ++ read and write routes ++

This format has the following options: type, road, nogc, nourl, deficon, color, zoom, wpt_type, radius .

++This format supports the DeLorme ".an1" drawing file format used by their desktop software like Topo USA. It can ++currently be used to either read or write drawing files. If you use ++this format to create drawing files with routes or waypoints from another ++source, by default it will create "Red Flag" symbols for waypoints, and ++thick red lines for routes or tracks. It is possible to merge two drawing ++layers by doing something like this: ++

gpsbabel -i an1 -f one.an1 -f two.an1 -o an1 -F merged.an1

++In this case, the merged data will contain all of the ++properties of the original data. ++

++GPSBabel has a page describing creating routable onramps in Street Atlas with GPSBabel. ++

type option

++ Type of .an1 file. ++

This option specifies the type of the drawing layer ++to be created. The supported values are "drawing", "road", "trail", ++"waypoint", or "track". If you do not specify a type, the default ++will be either the type of the previous an1 file or "drawing" if there ++is no previous file. This lets you merge, for example, two road layers ++without having to specify "type=road" for the output.

road option

++ Road type changes. ++

++If you are creating a road layer, you may use the "road" option, which ++allows you to change the types of roads based on their names. You can ++change multiple roads at the same time. Currently supported types are ++

++

TypeMeaning
limitedLimited-access freeways
tollLimited-access toll highways
rampAccess ramps for limited-access highways
usNational highways (e.g. US routes)
primaryPrimary State/Provincial routes
stateState/Provincial routes
majorMajor Connectors
ferryFerry Routes
localLocal Roads
editableUser-drawn Roads

++

++GPSBabel defaults to creating editable roads. These are routed just like ++local roads, but may be edited with the drawing tools in Street Atlas. ++

++This option has a special format that is best demonstrated by example: ++

 "road=I-599!limited!Beecher St.!major"

++This option will cause any road named "I-599" to become a limited-access ++highway and any road named "Beecher St." to become a major connector. Note ++that roads that have had their types changed in this way are not editable ++in Street Atlas, so make sure they are where you want them before you ++change them, and make sure to keep a backup of your original road layer. ++Note that the ! is a shell metacharacter in bash and possibly other shells, ++so you may have to use single quotes or some other escape mechanism. ++

++There is a tutorial on ++how ++to create an onramp for a limited access highway in Street Atlas USA ++using GPSBabel. ++

nogc option

++ Do not add geocache data to description. ++

++If your original data contains geocaching-specific information such as ++difficulty and terrain, GPSBabel will automatically include that information ++in the waypoint descriptions in the generated drawing file. If you do not ++want that, specify the "nogc" option on the command line: ++

gpsbabel -i gpx -f 12345.gpx -o an1,nogc -F 12345.an1

nourl option

++ Do not add URLs to description. ++

++If your original waypoint data contains URLs, GPSBabel will include them as ++links in the generated drawing file. This causes the waypoint symbol to have ++a blue border, and it causes the waypoint text to be drawn in blue with an ++underline. ++

++If you do not want this behavior, specify the "nourl" option on the command ++line: ++

gpsbabel -i gpx -f 12345.gpx -o an1,nourl -F 12345.an1

deficon option

++ Symbol to use for point data. ++

++This option allows you to specify which symbol to use for points that ++don't have a symbol already. It defaults to "Red Flag" but it accepts ++any symbol name you can put in a DeLorme export file. To find the name ++of a specific symbol in Street Atlas, let the mouse pointer hover over ++it for a few seconds and the name will be displayed. ++

color option

++ Color for lines or mapnotes. ++

This option allows you to specify the color for ++line or mapnote data. It accepts color names of the form "#FF0000" (red) or any ++of the color names from the Cascading Style Sheets (CSS) ++specification.

zoom option

++ Zoom level to reduce points. ++

++This option specifies at what zoom level Street Atlas will begin showing ++reduced versions of your symbols. The default is 10. Setting zoom to 0 will ++disable this feature. Setting it to anything but the default will override ++the zoom level specified on any waypoints that were read from an existing ++an1 file; this is by design. ++

wpt_type option

++ Waypoint type. ++

++This option specifies how to represent point data in the draw file. ++Valid waypoint types are "symbol", "text", "mapnote", "circle", and "image". ++The default is "symbol". ++

++If you specify a waypoint type of "image", you should make sure that the ++icon descriptions of your waypoints are the full names, including drive letters ++and full path, of image files in a format that works with your DeLorme ++product. Note that this means that the .an1 file you generate will not work ++on any computer that does not have those images in the same place; this is ++part of the design of the an1 format and cannot be avoided. ++

radius option

++ Radius for circles. ++

++If the waypoint type is "circle", the "radius" option specifies ++the radius of the circles. By default, this is in miles, but it may be ++specified in kilometers by adding a 'k'. The default radius is 1/10 mile. ++

DeLorme GPL (gpl)

++ This format can... ++

  • ++ read and write tracks ++

++ This is the 'gpl' format as used in Delorme mapping ++ products. It is a track format and contains little more than the ++ tracklog of a GPS that was attached while driving. ++ frontiernet.net ++

DeLorme Street Atlas Plus (saplus)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

This format is for Delorme Street Atlas USA 2004 Plus and later. ++

For geocachers importing data from a tool like GSAK or ++Spinner, import the file twice in XData. One will create a file with ++the Cache description as a hyperlink on the flag. This can clutter up ++the screen and when you try to zoom in, it causes problems. So the ++second one will only have a flag. Thus you can turn off and on which ++one you want to view. The first time you import the file, in the ++assign field types, check the circle above Full Name and then next. ++The second time you import the file do not check any circle and in the ++second to last column, change URL to none and then click next. Use the ++same name you used the first time but add -Flag to it. ++

DeLorme Street Atlas Route (saroute)

++ This format can... ++

  • ++ read tracks ++

This format has the following options: turns_important, turns_only, split, controls, times .

++This format reads route files from many Delorme mapping products. ++It supports the anr, rte, and rtd formats as either tracks or ++routes.

All options only apply to route files from newer (anr) ++versions of DeLorme software; older versions didn't store the turn ++information with the route. ++

turns_important option

++ Keep turns if simplify filter is used. ++

This option only makes sense in ++conjunction with the 'simplify' filter. It ensures that the route ++simplification process will remove the points corresponding to turns ++only after it has removed all other route points. ++

turns_only option

++ Only read turns; skip all other points. ++

This option causes GPSBabel to read only the ++waypoints associated with named turns. This should create a list of ++waypoints that correspond to the itinerary from Street Atlas.

split option

++ Split into multiple routes at turns. ++

This option causes GPSBabel to create separate ++routes for each street, creating a new route at each turn point. For ++obvious reasons, 'split' cannot be used at the same time as the ++'turns_only' or 'turns_important' options.

controls option

++ Read control points as waypoint/route/none. ++

This option lets you read the control points ++(start, end, vias, and stops) for your route as well as the route ++itself. The default for this option is 'none', which won't read the ++control points. You may also specify 'waypoints', which reads the ++control points as waypoints, or 'route', which creates an extra route ++named 'control points' containing just the control points in order. ++Note that if your goal is to create an arc or other CSV file, you ++should use 'none' (or not use this option, which is the same ++thing.)

times option

++ Synthesize track times. ++

This option causes GPSBabel to read the route as if ++it were a track, synthesizing times starting from the current time, using ++the estimated travel times specified in your route file (you can change your ++travel speeds in the DeLorme product you used to create the route file.)

DeLorme XMap HH Native .WPT (xmap)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

Delorme TopoUSA/XMap Conduit is one of the bazillion ++CSV variants ++variants mentioned above. It's just like Delorme Streets & Atlas with the addition of ++a completely pointless line at the beginning and end of the file. This ++is the format used to hot-sync to XMap from withing TopoUSA. Done with ++help of Dan Edwards.

DeLorme XMap/SAHH 2006 Native .TXT (xmap2006)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

Delorme XMap2006 Conduit is just like ++XMap ++, except there are ++ no spaces between fields and the coordinate format is slightly ++ different. The completely pointless header and footer lines ++ are the same, at least. Use this to create the XMapHHWptsSend.txt ++ file needed to sync to Street Atlas Handheld 2006.

Note that in order to keep from creating duplicates on your handheld, you must first remove the file "XMapWptsDB" from your handheld, restart SAHH2006 on the handheld to create an empty database, and THEN sync the new file.

DeLorme XMat HH Street Atlas USA .WPT (PPC) (xmapwpt)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++Delorme XMapHandHeld Street Atlas USA is another of the ++billion CSV variants. ++This is the format used by XmapHH SA USA on (at least) PocketPC O/S. ++

++This XMap is not the same as the simpler ++XMap format, which is used with Topo USA 4.0 ++and XMapHH for Palm. ++

++Delorme XMap Handheld .WPT for PocketPC is a bit of a kludge. This ++chapter covers XMap Handheld Street Atlas USA edition. ++

++XMap on the PocketPC stores its waypoints in individual .wpt files. ++For example, waypoints generated by XMap on the PocketPC are stored ++by default in the "My Documents" folder using the sequential names ++"XMap1.wpt", "XMap2.wpt", ad nauseum. Needless to say, this is not very ++efficient. ++

++As writing multiple waypoint files is outside of the scope of GPSBabel, ++GPSBabel chooses to write one big file, one waypoint per line. ++Extracting lines from this file is left as an exercise for the end user. ++A simple Perl script to handle this conversion is included at the end ++of this chapter. ++

++It should also be noted that reading multiple files ++is indeed possible, but if you have more than a few points, it can be a task. ++For example: ++

gpsbabel -i xmapwpt -f Xmap1.wpt -f Xmap2.wpt -o mapsend -F mapsend.wpt

++will read the two Xmap .wpt files and write one mapsend file. This ++is fine for a small handful of points, but could be quite cumbersome ++for folks like me who have 100+ waypoints loaded into XMap. For *nix ++folks, something as simple as: ++

cat *.wpt > /tmp/foo.wpt ++gpsbabel -i xmapwpt -f foo.wpt -o mapsend -F mapsend.wpt

++will do the trick just fine. ++

++#!/full/path/to/perl
++$INPUTFILE = @ARGV[0];
++$TARGETDIR = @ARGV[1];
++$FILENAME  = @ARGV[2];
++
++if (! $FILENAME) {
++    print "Usage: xmap_split.pl " . 
++	"INPUT_FILE OUTPUT_DIRECTORY FILENAME_BASE\n";
++    print " (i.e. xmapl_split.pl points.wpt /tmp/points GPSB)\n";
++    print " (created GPSB0001-GPSBXXXX " .
++	" in /tmp/points/ from points.wpt)\n";
++    exit;
++}
++
++open (INFILE, $INPUTFILE) || die "Cannot open $INPUTFILE for read!\n";
++
++while (<INFILE>) {
++    $lc++;
++    $filename = sprintf("%s/Gpsb%04d.wpt", $TARGETDIR, $lc);
++
++    open (OUTFILE, ">$filename") || 
++	die "Cannot open $filename for write!\n";
++
++    print OUTFILE $_;
++
++    close(OUTFILE);
++}
++
++exit;
++
++

Contributed to GPSBabel by Alex Mottram.

Destinator Itineraries (.dat) (destinator_itn)

++ This format can... ++

  • ++ read and write routes ++

++ Support for Destinator™ itinerary files. ++

++ These have (mostly) extension .dat and are binary files. The file structure is undocumented ++ and so this format was reverse engineered from some .dat files. ++ At this time we can read and write name, comment and the coordinates of the route points. ++

++ Destinator™ by ++ Destinator Technologies ++ is a software for PNDs, Smartphones and PDAs. ++

++ ++ gpsbabel -i destinator_itn -f from_A_to_B.dat -o gpx -F from_A_to_B.gpx ++ ++

Destinator Points of Interest (.dat) (destinator_poi)

++ This format can... ++

  • ++ read and write waypoints ++

++ Support for Destinator™ binary POI files (.dat). ++

++ The basic information was found at mozoft.com. ++ GPSBabel can read and write all fields described at this document. Please note that 'house number' isn't ++ supported as a separate field. This field, if available in any source file, will be stored together with 'street' ++ into GSPBabel's internal 'address' field. ++

++ Destinator™ by ++ Destinator Technologies ++ is a software for PNDs, Smartphones and PDAs. ++

++ ++ gpsbabel -i destinator_poi -f interesting_places.dat -o gpx -F interesting_places.gpx ++ ++

Destinator TrackLogs (.dat) (destinator_trl)

++ This format can... ++

  • ++ read and write tracks ++

++ Support for Destinator™ binary tracklogs (.dat). ++

++ The basic information was found at mozoft.com. ++ In addition to the standard GPS track data of coordinates and timestamp, this format also stores the ++ position fix and the number of satellites seen during recording. ++

++ Destinator™ by ++ Destinator Technologies ++ is a software for PNDs, Smartphones and PDAs. ++

++ ++ gpsbabel -i destinator_trl -f last_trip.dat -o gpx -F last_trip.gpx ++ ++

EasyGPS binary format (easygps)

++ This format can... ++

  • ++ read and write waypoints ++

++ This is the binary file format used by EasyGPS ++ format is seemingly being phased out in favor of GPX in newer versions ++ of EasyGPS, but this allows conversions to and from the old binary ++ .loc format. ++

++ Information about and sketchy code to implement this file ++ format were provided by Eric Cloninger. ++

Embedded Exif-GPS data (.jpg) (exif)

++ This format can... ++

  • ++ read and write waypoints ++

This format has the following options: filename, frame, name, overwrite .

++ This format reads and writes GPS information embedded in ++ EXIF, ++ the Exchangeable Image Format, data. EXIF is a standardized method ++ of encoding data in pictures such as JPEG, TIFF, and WAV and is frequently ++ used by mobile phones with cameras and cameras with built-in GPS. ++

++ EXIF is frequently used for Geolocating photographs so their images can be ++ correlated with time and location. ++

filename option

++ Set waypoint name to source filename. ++

++ With this default option waypoint names are generated from source filename. ++

++ ++ gpsbabel -i exif -f "C:\Pictures\IMG_1199.JPG",filename=Y -o gpx -F OUT.GPX ++ ++ The resulting waypoint in OUT.GPX has name IMG_1199. ++

frame option

++ Time-frame (in seconds). ++

++ Frame means the maximum time difference that we accept between the EXIF time information ++ of a picture and the timestamp of a track-, route- and waypoint used for tagging. ++ Without this option the maximum time frame is 10 seconds. ++

++ gpsbabel -i gpx -f holiday.gpx -o exif,frame=60 -F IMG0784.JPG ++

++ If the camera time wasn't adjusted, you should move the track(s) by the this difference. ++ I.e. if the camera time is five minutes behind your time, the track(s) should be shifted ++ five minutes back. ++

++ gpsbabel -i gpx -f holiday.gpx -x track,move=-5m -o exif,frame=60 -F IMG0784.JPG ++

name option

++ Locate waypoint for tagging by this name. ++

++ When you specify a name with this option we're looking for a waypoint ++ with this name. And, if found, the GPS information of this point is used ++ for tagging the image file. ++

++ gpsbabel -i gpx -f holiday.gpx -o exif,name="On the beach" -F IMG0786.JPG ++

overwrite option

++ !OVERWRITE! the original file. Default=N. ++

++ In the default case GPSBabel reads the output file (the file that should be ++ tagged with GPS information) and then creates a new file with an additional ++ .JPG extension. With this option in a final step the original file will be ++ deleted and the new file renamed as the original filename. ++

Energympro GPS training watch (energympro)

++ This format can... ++

  • ++ read tracks ++

++ Input support for the Energympro™ training watches ++ file structure. ++

++The ++Energympro GPS sport watches present themselves as USB mass storage ++ devices. To get the training just connect the device using the supplied ++USB cable to your computer and the device will show up as a removable device. ++Your training data is in the Workout folder. ++

++ ++ gpsbabel -i energympro -f infile.cpo -o gpx,garminextensions -F outfile.gpx ++ ++

Enigma binary waypoint file (.ert) (enigma)

++ This format can... ++

  • ++ read and write routes ++

++ This MGL Avionics format holds waypoints or routes. This routes can be loaded by the MGL Stratomaster Enigma EFIS series ( ++Enigma™, ++Odyssey™, ++Voyager™, ++Explorer™). ++

++ The format is designed for microcontrollers. The use is free for any non-military ++ application. You can find a detailed description in the MGL Documentation. ++

F90G Automobile DVR GPS log file (f90g)

++ This format can... ++

  • ++ read tracks ++

++ ++This format is for the .map files produced by the F90G automobile ++Digital Video Recorder (DVR) when recording videos. The files are ++found on the sd card in /DCIM/DCIMA/NORMAL/ and are named with a time ++stamp and the .map extension. This format records each track point's ++latitude, longitude, local time, GMT time and velocity in Kilometers ++Per Hour. The local time is used in the gpsbabel translation. ++Minutes, seconds and the velocity are combined to form each track point's ++name in the converted trace. ++

++This was implemented by analyzing data from a F90G DVR supplied from China. ++Firmware F20-2013121217-E ++

++The format was tested only using .map samples collected in the USA. We are ++interested in samples or test results from other hemispheres. ++

FAI/IGC Flight Recorder Data Format (igc)

++ This format can... ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: timeadj .

++FAI/IGC Data File -- Used by the international gliding ++community to record gliding flights. IGC files can be converted to ++and from tracks representing recorded flights, and routes representing ++task declarations in other formats. ++

IGC Data Format Notes

++Refer to Appendix 1 of ++http://www.fai.org:81/gliding/gnss/tech_spec_gnss.asp ++for the specification of the IGC data format. ++

++A sample list of software applications that use data in IGC format can be ++found at ++http://www.fai.org:81/gliding/gnss/gnss_analysis_software.pdf ++

++GPSBabel can be used to translate data in IGC format to and from various other ++formats. ++

++Routes in other formats are used to represent IGC task declarations. ++

++Tracks in other formats are used to represent IGC recorded flights. ++

Converting to IGC format

++IGC files generated by GPSBabel will NOT pass security validation tests since ++the data they contain cannot be proven to originate from an approved flight ++recorder. For most software applications that use IGC files this is not an ++issue but for competition scoring, record and badge claims the generated files ++will not be accepted as proof of a flight. ++

++A track stored in another format (GPX for example) representing a recorded ++flight can be converted into an IGC file: ++

gpsbabel -i gpx -f mytrk.gpx -o igc -F myflight.igc

++If multiple track segments are provided in the input file, the one with the ++most points will be used. ++

++A route stored in another format representing a task declaration can be ++converted into an IGC file: ++

gpsbabel -i gpx -f myrte.gpx -o igc -F mytask.igc

++A route and a track in other formats can be included into a single IGC file: ++

gpsbabel -i gpx -f mytrk.gpx -f myrte.gpx -o igc -F myflight.igc

++A similar result can be obtained by downloading the track log and routes ++directly from a GPS device connected to a PC. For example to create an IGC ++file from data recorded in a Garmin GPS connected to the first serial port of ++a PC running Linux: ++

gpsbabel -t -r -i garmin -f /dev/ttyS0 -o igc -F myflight.igc

++For Windows operating systems: ++

gpsbabel -t -r -i garmin -f com1 -o igc -F myflight.igc

++A waypoint file in another format containing a waypoint whose short name is ++"PILOT" can be merged into an IGC file. The description field of the waypoint ++will be used for the pilot name in the IGC file header: ++

gpsbabel -i gpx -f mytrk.gpx -f myrte.gpx -f mywpt.gpx -o igc -F myflight.igc ++gpsbabel -w -t -r -i garmin -f /dev/ttyS0 -o igc -F myflight.igc

++Some formats such as GPX allow routes, tracks and waypoints to exist in the ++same file and can be used to fully populate an IGC file: ++

gpsbabel -i gpx -f myall.gpx -o igc -F myflight.igc

Converting from IGC format

++Data in an IGC file can be converted into other formats. For example to ++generate OziExplorer files containing tracks representing the recorded ++flight (myozi.plt) and routes representing declared tasks (myozi.rte): ++

gpsbabel -i igc -f myflight.igc -o ozi -F myozi

++Or to GPX format: ++

gpsbabel -i igc -f myflight.igc -o gpx -F myflight.gpx

++Header information from the IGC file will be written to the description field ++of the track(s). ++

++If both pressure altitude and GNSS altitude are recorded in the IGC file, two ++tracks will be written to the new track file, representing the two altitude ++tracks. The latitude, longitude and timestamps in the tracks will be identical. ++

Merging into IGC format

++A route stored in another format can be merged with an existing IGC file that ++has no task declaration, to generate a new IGC file with a task declaration: ++

gpsbabel -i igc -f myflight.igc -i gpx -f myrte.gpx -o igc -F mynew.igc

++A two dimensional (lat/lon) track recorded during a flight by a GPS receiver ++can be merged with a one dimensional (altitude) track recorded during the same ++flight by a barograph instrument. The result is a three dimensional IGC file ++representing the flight: ++

gpsbabel -i gpx -f baro.gpx -i igc -f my2D.igc -o igc -F my3D.igc

++The same can be achieved by downloading directly from a barograph instrument ++supported by GPSBabel. For example with a Brauniger IQ Comp GPS variometer: ++

gpsbabel -i baroiq -f /dev/ttyS0 -i igc -f my2D.igc -o igc,timeadj=auto -F my3D.igc

++or: ++

gpsbabel -i baroiq -f com1 -i igc -f my2D.igc -o igc,timeadj=auto -F my3D.igc

++(Documentation contributed by Chris Jones, Aug 2004) ++

timeadj option

++ (integer sec or 'auto') Barograph to GPS time diff. ++

++Sometimes there is a discrepancy between the internal clock in the barograph ++instrument and GPS time which can result in the altitude and ground positions ++not correlating correctly. This can be corrected manually by passing the time ++difference in seconds between the two time domains through the "timeadj" ++parameter. This can be any positive or negative integer: ++

gpsbabel -i gpx -f baro.gpx -i igc -f my2D.igc -o igc,timeadj=27 -F my3D.igc

++GPSBabel can also attempt to deduce the time difference automatically. This ++is done by comparing the time that it thinks that you landed on the GPS track ++and the barograph and adjusting accordingly: ++

gpsbabel -i gpx -f baro.gpx -i igc -f my2D.igc -o igc,timeadj=auto -F my3D.igc

Flexible and Interoperable Data Transfer (FIT) Activity file (garmin_fit)

++ This format can... ++

  • ++ read tracks ++

This format has the following options: allpoints .

allpoints option

++ Read all points even if latitude or longitude is missing. ++

++ This option specifies that all points in the input .fit-file should ++ be read. The default behavior is otherwise to skip points without ++ gps coordinates. This is especially useful for devices that do not ++ contain a gps, e.g., Garmin Vivosmart HR. ++

FlySight GPS File (flysight)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++This is the format used by the FlySight GPS for wingsuit pilots. ++

++Interfacing with the FlySight is pretty simple. FlySight acts like a USB disk when connected to a computer. Files are organized into folders by date, and individual files within the folder are named according to the time the log started (UTC). The files themselves are CSV text supported by this format. ++

Franson GPSGate Simulation (gpssim)

++ This format can... ++

  • ++ write waypoints ++

  • ++ write tracks ++

  • ++ write routes ++

This format has the following options: wayptspd, split .

++ This is a write-only format used to feed waypoints, tracks, and routes ++ into Franson Technolgies' ++ GpsGate simulator. ++

++ To use these files in GpsGate, select 'Simulator' and then ++ "File->Open". ++

wayptspd option

++ Default speed for waypoints (knots/hr). ++

++ This option specifies the speed of the simulation in knots. ++

split option

++ Split input into separate files. ++

When this option is specified, GPSBabel will split ++ split the output into multiple files using the output filename ++ as a base. For example, if you specify an output file of 'mytrip', ++

mytrip-waypoints.gpssim - will contain the waypoints.
mytrip-track0000.gpssim - will contain the first track.
mytrip-track0001.gpssim - will contain the second track.
... and so on.
mytrip-route0000.gpssim - will contain the first route.
mytrip-route0001.gpssim - will contain the seconds route.
... and so on.

++

++Valid values for this option are 0 (off) and 1 (on). The default is '0'. ++

Fugawi (fugawi)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

This was a requested CSV format, and is not the proprietary ++binary format used by Fugawi. Like any other CSV format, GPSBabel ++cannot read tracks in this format, but converting a track into it and ++then importing as track in Fugawi works.

It is known to work with Fugawi V3.1.4.635. When ++importing/exporting waypoints, one has to specify the order of fields ++as follows (names of fields may depend on the language used by ++Fugawi):

- Name
- Comment
- Description
- Latidude
- Longitude
- Altitude (metres)
- Date (yyyymmdd/yymmdd)
- Time of day (hhmmss)

When importing tracks, use "[ignore]" instead of "Name", ++"Comment" and "Description".

++ http://www.fugawi.com/ ++

G7ToWin data files (.g7t) (g7towin)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

  • ++ read routes ++

++ Like GPSBabel, G7ToWin is a program which allows uploading and ++ downloading information from several GPS devices (Garmin, Lowrance/Eagle, Magellan). ++ G7ToWin has its own data format, which is an enhanced format used in Gardown. ++

++ This format can read both file types, G7ToWin (.g7t) and Gardown (.gdn). ++

Garmin 301 Custom position and heartrate (garmin301)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

This is a very simple format that ++is most useful for exporting data from units that support heart rate ++data such as ++Garmin Forerunner 301™, ++Garmin Forerunner 305™, and ++Garmin Edge 305™, and ++to other programs ++for analysis. It's a simple comma delimited format that includes the ++timestamp, 3D position information and heart rate so you can pull it ++into a spreadsheet or graphing program.

Garmin G1000 datalog input filter file (garmin_g1000)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++Input format for Garmin G1000 integrated avionics system datalog generated by ++G1000 system software version 563.20 or later. This datalog is automatically ++generated and stored to a standard SD card if one is inserted in the *upper* ++SD card slot on the G1000's MFD (right-hand display on 2-screen installations, ++center display on 3-screen installations). ++

++Supports conversion of GPS track (including timestamp) and barometric altitude ++data to any of GPSBabel's output formats. Does not include support for G1000 ++stored flight plan (.fpl) route files or user waypoints. Tested on datalogs ++from Cessna 182T and Turbo 182T, but it should accommodate G1000 datalogs ++from other airframes as well. If any conversion failures or errors occur, ++check datalog csv file for incomplete or corrupted records/rows, delete ++those records/rows from the datalog file and reattempt. ++

Garmin Logbook XML (glogbook)

++ This format can... ++

  • ++ read and write tracks ++

++ This is the XML format used by the Garmin Logbook product ++ that ships with Forerunner and Foretrex. ++ As of early 2006, this program is apparently been discontinued in favor of ++ Garmin Training Center. ++ ++ See: http://www.garmin.com ++

Garmin MapSource - gdb (gdb)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: cat, bitscategory, ver, via, roadbook .

++ Support for the "Garmin GPS Database" format used by ++ default in MapSource™ versions since release 6.0 of ++ that product. By default GPSBabel creates ++ gdb files of version 2. Version 2 is used in Mapsource 6.3 and 6.5. This format ++ is also used by Garmin BaseCamp™ for Mac and Windows. ++

++ Garmin GPS database is an undocumented file format. The ++ basic info for this module came from the existing MapSource ++ conversion code. ++

cat option

++ Default category on output (1..16). ++

++This option specifies the default category for gdb output. It should be a ++number from 1 to 16. ++

bitscategory option

++ Bitmap of categories. ++

++ This option is closely related to the 'category' option. While category ++ allows you to choose a single category that waypoints should appear in, ++ this options allows you to specify a bitmask to be used for the category. ++ Options may be specified in either decimal or hex. ++

Example 3.5. Example for gdb bitcategory option to put all waypoints in categories 1 and 16.

++ The following two commands are equivalent. They place a the point in both the first and last of the sixteen available categories. ++ ++ gpsbabel -i gpx -f PocketQuery.gpx -o gdb,bitscategory=32769 -F foo.gdb ++ ++ ++ gpsbabel -i gpx -f PocketQuery.gpx -o gdb,bitscategory=0x8001 -F foo.gdb ++ ++ ++


ver option

++ Version of gdb file to generate (1..3). ++

++This option specifies the data format version for the output file. Version ++2 is the default. Currently, the only other valid values for this option are ++1 and 3. ++

via option

++ Drop route points that do not have an equivalent waypoint (hidden points). ++

++This option instructs GPSBabel to drop hidden (calculated) points from ++routes. ++

roadbook option

++ Include major turn points (with description) from calculated route. ++

++ If this option is specified, GPSBabel drops all calculated route points, ++ with exception of points with a description (i.e. "Make U-turns until you know where you are."). ++ The priority of this option is higher than of the via option. ++ A value of 1 or y overwrites the via settings. ++

Example 3.6. Using gdb option roadbook to create simple html roadbook

++ ++ gpsbabel -i gdb,roadbook -f sample.gdb -x nuketypes,waypoints,tracks -x transform,wpt=rte -o html -F roadbook.html ++ ++

++ Because gdb internally creates a route AND a waypoint list, you have to drop all ++ waypoints and transform the route into waypoints in order to get a well ordered ++ html output. We suggest these steps for all waypoint-only formats as html. ++


Garmin MapSource - mps (mapsource)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: snlen, snwhite, mpsverout, mpsmergeout, mpsusedepth, mpsuseprox .

++ This format supports the Garmin Mapsource™ product family. ++

++ This format is based on significant reverse-engineering and guesswork. ++ GPSBabel's output appears to be compatible with the various versions of ++ MapSource. Icon mapping is attempted between different MapSource versions. ++ Altitude is supported, but proximity and depth are not. ++

++ Naming files *.mps will allow file->open in Mapsource to find the files ++ more easily. ++

++ Versions 3, 4, and 5 of the Mapsource data format are handled automatically ++ on input. By default the output is version 5. (Until 3/2004, it was ++ version 3, but since Mapsource updates are free, the convenience of ++ having modern icon sets outweighs the backward compatibility concern. ++ Users of other versions can either upgrade or specify the switches to ++ get output in a compatible format.) Waypoints, routes, and tracklogs are ++ all handled, but map sets are ignored. ++

++ Information on the Garmin Mapsource format was provided by Ian Cowley and ++ Mark Bradley. The code was implemented by Robert Lipe and Mark Bradley. ++

snlen option

++ Length of generated shortnames. ++

++This option specifies the length of generated short names on output. The ++default is 10 characters. ++

snwhite option

++ Allow whitespace synth. shortnames. ++

++This option specifies whether to allow whitespace (space, tab, etc.) in ++generated short names on output. The default is to not allow whitespace. ++

mpsverout option

++ Version of mapsource file to generate (3,4,5). ++

++This option specifies the format version for the output file. The default ++is version 5, as noted above. Supported versions are 3, 4, and 5. ++

mpsmergeout option

++ Merge output with existing file. ++

++This option causes the output to be merged with a pre-existing output file. ++This allows MapSource sections that aren't handled by GPSBabel (e.g. map sets) ++to be preserved. ++

mpsusedepth option

++ Use depth values on output (default is ignore). ++

++This option causes GPSBabel to write depth values for waypoints. Most ++input formats do not support depth values, so the default is to not write ++them. ++

mpsuseprox option

++ Use proximity values on output (default is ignore). ++

++This option causes GPSBabel to write proximity values for waypoints. Most ++input formats do not support proximity values, so the default is to not write ++them. ++

Garmin MapSource - txt (tab delimited) (garmin_txt)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: date, datum, dist, grid, prec, temp, time, utc .

++This is a textual format that contains nearly all of the information ++contained in the MapSource™ main format, GDB. ++This format also contains some computed values such as distances between ++routepoints and trackpoints, speed, and course (heading). ++

++The main goal of garmin_txt is to make aviation data more available. Because ++MapSource™ supports only the export, GPSBabel gives you the possibility to ++bring aviation data into MapSource™. ++

++During the export with MapSource™, some fields are written using local settings ++of MapSource™ and Windows. These include grid format, gps datum, distance and ++temperature units, and the representation of date and time fields. GPSBabel ++tries to read all items automatically. Problems with date and time format can ++be solved with the 'date' and 'time' options. ++

Example 3.7. Command showing garmin_txt output with all options

gpsbabel -i garmin_txt,date="MM/DD/YYYY",time="hh:mm:ss xx" -f in.txt -o garmin_txt,date="DD.MM.YYYY",datum="WGS 72",dist=m,prec=6,temp=c,time="HH:mm:ss",utc=+2 -F out.txt


date option

++ Read/Write date format (i.e. yyyy/mm/dd). ++

++This option specifies the input and output format for the date. The format ++is written similarly to those in Windows. An example format is "YYYY/MM/DD". ++

datum option

++ GPS datum (def. WGS 84). ++

++This option specifies the datum to be used on output. Valid values for this ++option are listed in Appendix A, Supported Datums. ++

dist option

++ Distance unit [m=metric, s=statute]. ++

++This option specifies the unit to be used when outputting distance ++values. Valid values are M for metric (m/km/kph) or S for statute ++(ft/mi/mph). ++

grid option

++ Write position using this grid.. ++

++ This value specifies the grid to be used on write. ++

Table 3.1. Grid values for garmin_txt
# idxshortfile-headersample
0dddLat/Lon hddd.ddddd S26.25333 E27.92333
1dmmLat/Lon hddd°mm.mmN33 56.539 W118 24.471
2dmsLat/Lon hddd°mm'ss.sS25 25 26.8 E28 06 07.3
3bngBritish National GridTQ 18919 69392
4utmUniversal Transverse Mercator33 U 318293 5637154
5swissSwiss grid776519 167359

++ Idx or short are valid params for this option. ++

prec option

++ Precision of coordinates. ++

++This option specifies the precision to be used when writing coordinate values. ++Precision is the number of digits after the decimal point. The default ++precision is 3. ++

temp option

++ Temperature unit [c=Celsius, f=Fahrenheit]. ++

++This option specifies the unit to be used when writing temperature values. ++Valid values are C for Celsius or F for Fahrenheit. ++

time option

++ Read/Write time format (i.e. HH:mm:ss xx). ++

++This option specifies the input and output format for the time. The format ++is written similarly to those in Windows. An example format is "hh:mm:ss xx". ++

utc option

++ Write timestamps with offset x to UTC time. ++

++This option specifies the local time zone to use when writing times. It ++is specified as an offset from Universal Coordinated Time (UTC) in hours. ++Valid values are from -23 to +23. ++

Garmin PCX5 (pcx)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: deficon, cartoexploreur .

Garmin documents only PCX5, an older format limited to ++the lame NMEA six-character waypoint names that's treated as a ++second-class citizen in current versions of MapSource. In Mapsource, ++use file->import to read these files. If you name the files *.wpt, ++Mapsource will find them more easily. ++

In general, you should prefer the "mapsource" file format ++to this one. ++

This format has been extended to handle many - but not all - ++ files from GPS Utility. If you encounter something that GPSBabel does not handle well, use ++the free version of GPSUtil to read it and save as something more common. ++

deficon option

++ Default icon name. ++

++ The deficon option is used to control the icon output when writing to this format. It overrides any icon information that might be present in the source data. ++

cartoexploreur option

++ Write tracks compatible with Carto Exploreur. ++

++ Carto Exploreur requires a slightly incompatible variation of the PCX format ++when written. Specifying this option on write tells us to create that strain of PCX. ++

Garmin POI database (garmin_poi)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ The Garmin POI loader ++ loads custom points of interest into certain models of ++ Garmin GPS receivers. (As of this writing, only the models introduced ++ in 2005 and later are supported. See Garmin's site for more info.) ++ The garmin_poi format produces csv files that can be ++ converted into POI files by Garmin's POI loader. ++

++ This format was mostly useful when POI Loader couldn't read GPX and we ++ couldn't write GPI. See GPSBabel's GPI doc. ++

Garmin Points of Interest (.gpi) (garmin_gpi)

++ This format can... ++

  • ++ read and write waypoints ++

This format has the following options: alerts, bitmap, category, hide, descr, notes, position, proximity, sleep, speed, unique, units, writecodec .

++ The format garmin_gpi supports the binary POI (.gpi) files that are useable ++ on newer Garmin GPS receivers. See garmin_poi for additional information about Garmin's own Poiloader program. ++ Garmin POI-Loader is the standard application that creates GPI files ++ with all possible features. ++

++ Some of the third party and commercial GPI files are using some kind of ++ encryption or compression that makes the file contents completely unreadable ++ to us. If you get an error "Unsupported code page NNN. File is likely ++ encrypted." means we could basically recognize it as a Garmin GPI file, ++ but it's mangled beyond what we're likely to successfully read. ++

++ If a waypoint name is annotated with a trailing '@'NNN where NNN is ++ a number, that number will be used as the speed for POI alerts, just ++ as with Garmin's POI Loader program. The units default to metric kilometers ++ per hour, but this cn be changed to statute via the units argument. ++ A speed associated with a specific POI will get precdence over any ++ 'speed' argument provided. For example, a waypoint named "Point@30" will ++ associate a speed of 30 km/h with that specific point even if 'speed=40m' ++ is present in the output arguments. ++

++ The layout of GPI files isn't documented and our module was created ++ via reverse engineering. If you get a problem on reading or writing ++ a GPI file, please provide that file (mailto:gpsbabel-misc@lists.sourceforge.net). ++

++ At this time we don't support special features as "Tour-Guide" or links ++ to sounds and pictures. ++

Important

++ Creation timestamp issue: See the option sleep !!! ++

++ This module does not support direct transfer of .GPI files to ++ receivers in Garmin protocol mode. For units like Nuvi, Zumo, or ++ Streetpilot, just choose a file that's on the drive where your ++ GPS is mounted. For units like the X series (GPSMap 60CSx, GPSMap 60Cx, Legend Hcx, etc.) ++ you must explictly put the unit in mass storage mode or mount ++ the memory chip in an external reader and transfer the file ++ directly. ++

Example 3.8. Command showing garmin_gpi output example

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,category="Nice Restaurants",bitmap=restaurant.bmp,notes -F "My Points.gpi" ++ ++


alerts option

++ Enable alerts on speed or proximity distance. ++

++ Because speed isn't a real member of a normal waypoint, you can put the speed values into ++ the waypoint names. "Point@30" will result in a speed value of 30. By default we assume these ++ values are in kilometers per hour. ++

++ Proximity distance is also supported by GPX, Garmin GDB, OZI Explorer, ++ CompeGPS and Universal CSV. ++

++ ++ gpsbabel -i gpx -f "warnings.gpx" -o garmin_gpi,alerts=1 -F "warnings.gpi" ++ ++

bitmap option

++ Use specified bitmap on output. ++

++ The bitmap (BMP) should be 24x24 (or smaller) and can be in ++ RGB-colors (24- and 32-bit) or 8-bit indexed color format. ++

++ If you're starting from images in another format, you may need to ++ use another tool like Gimp or ImageMagick's convert to get the imaga ++ into oen of the above formats to avoid errors about "Unsupported color ++ depth". ++

++ Not all devices can support all color depths. GPSBabel (and its ++ developers) have no way of knowing what is supported on any given model ++ so some experimentation may be necessary on your part. It was reported ++ that a Nuvi 3790, for example, will read the POIs only if they use 8BPP. ++

++ A color value of 0xFF00FF (blue=255, green=0, red=255), ++ also called "Magenta", can be used for transparent areas. ++

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,bitmap="tux.bmp" -F "My Points.gpi" ++ ++

category option

++ Default category on output. ++

++ With this option you can specify the category which is primary ++ visible on the device (default is "My points"). ++

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,category="Best Restaurants" -F "My Points.gpi" ++ ++

hide option

++ Don't show gpi bitmap on device. ++

++ For a large list of points (or whyever) it can be useful when ++ no bitmaps are displayed on device. With this option no bitmap ++ is stored and displayed. ++

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,hide -F "My Points.gpi" ++ ++

descr option

++ Write description to address field. ++

++ The GPI address field is often visible in lists on the device. Use this ++ option if you want to see the waypoint description (which can be an address too) ++ in this lists. ++

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,descr -F "My Points.gpi" ++ ++

notes option

++ Write notes to address field. ++

++ The GPI address field is often visible in lists on the device. Use this ++ option if you want to see the waypoint notes (which can be an address too) ++ in this lists. ++

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,notes -F "My Points.gpi" ++ ++

position option

++ Write position to address field. ++

++ The GPI address field is often visible in lists on the device. Use this ++ option if you want to see the waypoint position (coordinates) in this lists. ++

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,position -F "My Points.gpi" ++ ++

proximity option

++ Default proximity. ++

++ When no proximity data is available in the source input, GPSBabel uses this as the default proximity value. ++ The parameter has to be in meters, or, when units=s specified, in miles. ++ alerts are automatically enabled. ++

Example 3.9. Read GPX file, create GPI to alert when you're 1/2 mile from a speed camera.

++ ++ gpsbabel -i gpx -f "SpeedCameras.gpx" -o garmin_gpi,units=s,proximity=0.5 -F "SpeedCameras.gpi" ++ ++


++ Its also possible to append a specific distance unit to the parameter. ++

++ ++ gpsbabel -i gpx -f "SpeedCameras.gpx" -o garmin_gpi,proximity=500m -F "SpeedCameras.gpi" ++ ++

++

Table 3.2. Supported distance units (garmin_gpi)
UnitDescription
faFathoms
feetFeet
ftFeet
kmKilometers
mMeters
miMiles
nmNautical miles


++

sleep option

++ After output job done sleep n second(s). ++

++ The Garmin units seem to use the creation timestamp of GPI files for internal purposes. ++ In other words, if you load GPI files with same creation timestamp on your device, ++ strange things will happen, such as having missing or repeated POIs. With the sleep option, GPSBabel waits a given ++ number of seconds after the GPI file was written. ++

++ In the normal case of using GPSBabel from the command line or from the GUI, the chance of creating files ++ with the same timestamp is in the nearly ZERO. In scripts or batch files where you are writing multiple files - even from different GPSBabel instances - the odds of this happening is rather good. ++ The sleep option forces GPSBabel to wait after creating a file to ensure the timestamps are unique. Values are specified in seconds and can be 1 or more. ++

++ ++ gpsbabel -i gpx -f "SpeedCameras.gpx" -o garmin_gpi,sleep=1 -F "SpeedCameras.gpi" ++ ++

speed option

++ Default speed. ++

++ When no speed data is available in the source input, GPSBabel uses this as the default speed value. ++ The parameter has to be in kilometers per hour, or, when units=s specified, ++ in miles per hour. alerts are ++ automatically enabled. ++

++ ++ gpsbabel -i gpx -f "SpeedCameras.gpx" -o garmin_gpi,units=s,speed=30 -F "SpeedCameras.gpi" ++ ++

++ Its also possible to append a specific speed unit to the parameter. ++

++ ++ gpsbabel -i gpx -f "SpeedCameras.gpx" -o garmin_gpi,speed=30mph -F "SpeedCameras.gpi" ++ ++

++

Table 3.3. Supported speed units (garmin_gpi)
UnitDescription
km/hKilometers per hour
kmhKilometers per hour
kphKilometers per hour
ktKnots
knotKnots
m/sMeters per second
mpsMeters per second
mi/hMiles per hour


++

unique option

++ Create unique waypoint names (default = yes). ++

++ Don't create unique names sample: ++

++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,unique=0 -F "My Points.gpi" ++ ++

units option

++ Units used for names with @speed ('s'tatute or 'm'etric). ++

++ Sample command tells GPSBabel to handle speed values in miles per hour: ++ ++ gpsbabel -i gpx -f "My Points.gpx" -o garmin_gpi,units=s -F "My Points.gpi" ++ ++

writecodec option

++ codec to use for writing strings. ++

++This lets you overwride the default codec of 'windows-1252' when writing ++strings in Garmin GPI files. This option may be removed in future versions ++of GPSBabel as it's not known which Garmin devices support which character ++sets. ++

Garmin serial/USB protocol (garmin)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: snlen, snwhite, deficon, get_posn, power_off, erase_t, resettime, category, bitscategory, baud .

++ GPSBabel supports a wide variety of Garmin hardware via serial ++ on most operating systems and USB on Windows, Linux, and OS X. ++

++ For serial models, be sure the GPS is set for "Garmin ++ mode" in setup and that nothing else (PDA hotsync programs, gpsd, ++ getty, pppd, etc.) is using the serial port. ++

++ Supported Garmin GPS receivers with USB include ++

AstroForerunner 205GPSMAP 60CSxStreetPilot 2650
Edge 205Forerunner 301GPSMAP 60CxStreetPilot 2720
Edge 305Forerunner 305GPSMAP 76CStreetPilot 2730
eTrex Legend CForetrex 201GPSMAP 76CSStreetPilot 2820
eTrex Legend CxForetrex 301GPSMAP 76CSXStreetPilot 7200
eTrex Legend HGPS 18[1]GPSMAP 76CxStreetPilot 7500
eTrex Legend HCxGPSMAP 195GPSMAP 96StreetPilot c310
eTrex Summit CxGPSMAP 276CGPSMAP 96CStreetPilot c320
eTrex Summit HCGPSMAP 295QuestStreetPilot c330
eTrex Venture CGPSMAP 296CQuest IIStreetPilot c340
eTrex Venture CxGPSMAP 378Rhino 520StreetPilot i2
eTrex Venture HCGPSMAP 396Rhino 530StreetPilot i3
eTrex Vista CGPSMAP 478Rhino 520 HCxStreetPilot i5
eTrex Vista CxGPSMAP 496Rhino 530 HCx 
eTrex Vista HGPSMAP 60CStreetPilot 2610 
eTrex Vista HCxGPSMAP 60CSStreetPilot 2620 

++

the following Bluetooth Garmin products: ++

GPS 10[1]   

++

and most serial Garmin GPS receivers including: ++

eMapeTrex HGPS 12 Rhino 110
eTrex CamoForerunner 201GPS 12XL Rhino 120
eTrex LegendForetrex 201GPS III Rhino 130
eTrex SummitGeko 201GPS III+ StreetPilot III
eTrex VentureGeko 301GPS II StreetPilot III+
eTrex VistaGPS 12CX GPS II+  
eTrex (Basic Yellow)GPS 12Map GPS V 

++

++The following Garmin GPS receivers are supported, but they do not ++support Garmin communication protocol and don't work with the ++garmin option. To use these receivers, read or write ++GPX files from the mass storage device as mounted on your computer. ++

eTrex 10[2]Nuvi 255[2]Nuvi 770[2]Nuvi 1690T[2]
eTrex 20[2]Nuvi 250W[2]Nuvi 775T[2]Nuvi 3750[2]
eTrex 30[2]Nuvi 255W[2]Nuvi 780[2]Nuvi 3760T[2]
Colorado 300[2]Nuvi 260[2]Nuvi 785T[2]Nuvi 3790T[2]
Colorado 400c[2]Nuvi 265T[2]Nuvi 880[2]Oregon 200[2]
Colorado 400i[2]Nuvi 265WT[2]Nuvi 885T[2]Oregon 300[2]
Colorado 400t[2]Nuvi 260W[2]Nuvi 1200[2]Oregon 400c[2]
Dakota 10[2]Nuvi 270[2]Nuvi 1250[2]Oregon 400i[2]
Dakota 20[2]Nuvi 275T[2]Nuvi 1260T[2]Oregon 400t[2]
GPSMap 62[2]Nuvi 300[2]Nuvi 1300[2]Oregon 450[2]
GPSMap 62sc[2]Nuvi 310[2]Nuvi 1350[2]Oregon 450t[2]
GPSMap 62stc[2]Nuvi 350[2]Nuvi 1370T[2]Oregon 550[2]
GPSMap 78[2]Nuvi 370[2]Nuvi 1390T[2]Oregon 550t[2]
GPSMap 78s[2]Nuvi 465T[2]Nuvi 1350[2]StreetPilot c510[2]
GPSMap 78sc[2]Nuvi 500[2]Nuvi 1490T[2]StreetPilot c530[2]
Montana 600[2]Nuvi 550[2]Nuvi 2250[2]StreetPilot c550[2]
Montana 650[2]Nuvi 600[2]Nuvi 2250LT[2]StreetPilot c580[2]
Montana 650t[2]Nuvi 650[2]Nuvi 2350[2]Road Tech Zumo[2]
Nuvi 30[2]Nuvi 650FM[2]Nuvi 2350LT[2]Zumo 220[2]
Nuvi 40[2]Nuvi 660[2]Nuvi 2360LT[2]Zumo 450[2]
Nuvi 50[2]Nuvi 670[2]Nuvi 2405[2]Zumo 500[2]
Nuvi 200[2]Nuvi 680[2]Nuvi 2450[2]Zumo 550[2]
Nuvi 205[2]Nuvi 750[2]Nuvi 2450LM[2]Zumo 660[2]
Nuvi 200W[2]Nuvi 755T[2]Nuvi 2450LT[2]Zumo 665[2]
Nuvi 205W[2]Nuvi 760[2]Nuvi 2450LMT[2]Surely any Garmin product that Garmin actually sensibly designed after 2006 or so.[2]
Nuvi 250[2]Nuvi 765T[2]Nuvi 2505[2] 

++

++ None of the GPSBabel developers has access to every model on that ++ list, but we've received reports of success and/or have reasonable ++ expectations that the above models work. If you succeed with ++ a model that is not on that list, please send a message to the ++ gpsbabel-misc mailing list with the details so that we may add it. ++

++ Not every feature on every model is supported. For example, ++ while we do extract data such as heart rate and temperature from ++ tracks on the sporting models like Edge and Forerunner, GPSBabel ++ is not a fitness program at its core and does not support features ++ like workouts or calorie/fitness zone data. Furthermore, sporting ++ models don't support track upload. When trying to upload tracks to ++ these devices, GPSBabel converts them to courses on the fly and ++ uploads these instead. When uploading waypoints at the same ++ time, these are converted to course points by mapping them to the ++ nearest track point on the track/course (no matter how far away from ++ the track they are). Since course point creation requires time ++ stamps for the track points, they are created automatically assuming ++ a speed of 10 km/h for tracks that lack them. ++

++ To communicate with a Garmin GPS serially, use the name of that ++ serial port such as COM1 or /dev/cu.serial. ++

++ To communicate via USB use usb: as the filename on all OSes. ++ Thus, to read the waypoints from a Garmin USB receiver and write ++ them to a GPX file: ++

gpsbabel -i garmin -f usb: -o gpx -F blah.gpx

++ If you have multiple units attached via USB, you may provide ++ a unit number, with zero being the implied default. So if you ++ have three USB models on your system, they can be addressed as ++ usb:0, usb:1, and usb:2. To get a list of recognized devices, ++ specify a negative number such as: ++

gpsbabel -i garmin -f usb:-1

++When reporting problems with the Garmin format, be sure to include ++the full unit model, firmware version, and be prepared to offer ++debugging dumps by adding -D9 to the command line, like: ++

gpsbabel -D9 -i garmin -f usb: -o gpx -F blah.gpx

++Custom icons are supported on units that support that. ++Neither GPSBabel nor your firmware know what is associated with any ++given slot number. They don't know that the picture you placed in the ++first slot is a happy face, they only know they're in the lowest ++numbered slot. GPSBabel names the them consistently with Mapsource, ++so they are named 'Custom 0' through 'Custom 511'. ++

++ For models where the connection on the GPS is a serial interface, ++ be sure the GPS is set for "Garmin ++ mode" in setup and that nothing else (PDA hotsync programs, gpsd, ++ getty, pppd, etc.) is using the serial port. ++

++ For models connected via USB, we recommend use of the usb: ++ filename. For this to work on Windows, you must install ++ the Garmin driver. For Linux, this will fail if you have the garmin_gps ++ kernel module loaded. ++ See the Operating System Notes for details. ++

++This module also supports realtime tracking ++which allows realtime position reports from a Garmin GPS receiver over USB ++or serial. ++

Important

The following Garmin units do not follow the standard Garmin ++communications protocol and are not supported ++by GPSBabel.

++Marine plotters: ++

GPSMap 420GPSMap 450GPSMap 530GPSMap 545
GPSMap 430GPSMap 520GPSMap 535GPSMap 550
GPSMap 440GPSMap 525GPSMap 540GPSMap 555

++

The PDA products ++

iQue 3000
iQue 3200
iQue 3600
iQue M3
iQue M4
iQue M5

++

snlen option

++ Length of generated shortnames. ++

This option overrides the internal logic to figure out how many ++characters an addressed Garmin GPS will support when using the '-s' smartname ++option. This should be necessary only if you have a receiver type that ++GPSBabel doesn't know about or if you want to "dumb down" one unit to match ++another, such as wanting waypoint names in a StreetPilot 2720 (which supports ++20 character names) to exactly match those in a 60CS (which supports 10). ++

snwhite option

++ Allow whitespace synth. shortnames. ++

This options controls whether spaces are allowed in generated ++smart names when using the '-s' option.

deficon option

++ Default icon name. ++

++This option specifies the icon or waypoint type to write for each waypoint on ++output. ++

++If this option is specified, its value will be used for all waypoints, not ++just those that do not already have descriptions. That is, this option ++overrides any icon description that might be in the input file. ++

++Value specified may be a number from the Garmin Protocol Spec or a name ++as described in the Appendix B, Garmin Icons. ++

++This option has no effect on input. ++

get_posn option

++ Return current position as a waypoint. ++

This options gets the current longitude and latitude from the attached GPS device ++and returns it as a single waypoint for further processing. For example, ++to return the current position from a USB Garmin to a KML file: ++

gpsbabel -i garmin,get_posn -f usb: -o kml -F myposition.kml

power_off option

++ Command unit to power itself down. ++

This command forces an immediate powerdown of the addressed Garmin ++receiver. It is ignored on hardware that does not support this command. ++Obviously, further processing once you have sent a "power off" command to ++a unit that supports it is rather futile, so place this option carefully ++in your command. ++ ++

gpsbabel -o garmin,power_off -F /dev/ttyS0

erase_t option

++ Erase existing courses when writing new ones. ++

++By default, GPSBabel makes effort in order to keep courses already present on ++the device, if any. This option allow to replace courses already present. If ++you don't mind to keep old courses, this option is recommended because it ++allows a faster transfer. ++

++This option applies only to Garmin devices that support courses such as the Edge 305 or the Forerunner 305. ++

resettime option

++ Sync GPS time to computer time. ++

++ This option is experimental and was added to solve a very specific problem. ++ Certain Garmin units (the original black and white Vista is known to have ++ this) will sometimes scramble their clock crazy far into the future (like ++ 2066). When this happens, the GPS itself may or may not work and ++ later conversations with GPSBabel may fail as the time overflows the ++ documented range. The use of resettime brings the GPS's internal clock ++ back close enough to reality that the GPS itself can then "fix" it when ++ it has next a lock. ++

category option

++ Category number to use for written waypoints. ++

This numeric option will force waypoints to be written with that ++category number when sending to a Garmin receiver that has category ++support. It is ignored on receivers without that capability.

bitscategory option

++ Bitmap of categories. ++

++ This option is closely related to the 'category' option. While category ++ allows you to choose a single category that waypoints should appear in, ++ this options allows you to specify a bitmask to be used for the category. ++ Options may be specified in either decimal or hex. ++

Example 3.10. Example for garmin bitcategory option to put all waypoints in categories 1 and 16.

++ The following two commands are equivalent. They place a the point in both the first and last of the sixteen available categories. ++ ++ gpsbabel -i gpx -f PocketQuery.gpx -o garmin,bitcategory=32769 -F usb: ++ ++ ++ gpsbabel -i gpx -f PocketQuery.gpx -o garmin,bitcategory=0x8001 -F usb: ++ ++ ++


baud option

++ Speed in bits per second of serial port (baud=9600). ++

++Sets baud rate on some Garmin serial unit to the specified baud rate. Garmin protocol uses 9600 bps by default, but there is a rarely documented feature in Garmin binary protocol for switching baud rate. Highest option is 115200. ++

++Download track log and waypoints 12 times faster than default: ++ ++gpsbabel -t -w -i garmin,baud=115200 -f /dev/ttyUSB0 -o gpx -F garmin-serial.gpx ++ ++

++At the end of the transfer, baud rate is switched to back to the default ++of 9600. If connection breaks, the unit stucks at high baud rate, a power ++cycle reverts to original state. ++

++This option does not affect USB transfer. ++

++Because this feature uses undocumented Garmin protocols, it may or may ++not work on your device. The author reported success with ++eTrex Vista, GPSMAP 76s, and GPS V, but it seems likely to be problematic ++on older units and may be more problematic for writing to the device than ++reading data from the device. ++

Garmin Training Center (.tcx) (gtrnctr)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read and write tracks ++

This format has the following options: course, sport, course, sport .

++GPSBabel supports reading and writing of tracks in the .tcx ++format used by Garmin Training Center™ (GTC). GTC is the successor ++to Garmin's Logbook™ program for their workout units. It is a ++free upgrade. ++

++GPSBabel can read GTC v1 and v2 files, and can write v2 files. ++v2 files are most likely to have a .tcx extension. v1 files ++typically have a .hst or .crs extension, depending on whether they ++are in the "history" or "course" format. ++

++There is a fundamental mismatch between this format and most of ++what we support. GPSBabel deals in waypoints, tracks, and routes. ++While we do record things like heart rate and temperature when we know ++it, the fundamentals of Training Center are different. It deals in ++concepts like laps and calories, which are rather alien to GPSBabel ++and most of the formats we support. As such, while we can describe ++the tracks pretty accurately, things like calories and heart zone ++tracking are not supported. Some of the auxiliary data, such as ++heart rate (not zone), cadence, and bicycling power are supported. ++

++One of the most useful things you can do with this format is to send ++.tcx files found on the web or elsewhere to any supported GPS ++unit. You will probably want to include the transform (rte=trk) ++and simplify filters in this process. For example, ++

++gpsbabel -i gtrnctr -f somefile.tcx -x simplify,count=50 ++-x transform,rte=trk -r -o garmin -F usb: ++

++where you select the count not to exceed the number of available ++waypoints for routing on your device. ++

course option

++ Write course rather than history, default yes. ++

++ This flag defaults to true; it must be turned off (course=0) if you want history instead of courses. ++

sport option

++ Sport: Biking (deflt), Running, MultiSport, Other. ++

++ Specify which sport is associated with this activity. Valid values are Biking, Running, MultiSport, and Other. ++

Garmin Training Center (.xml) (gtrnctr)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read and write tracks ++

course option

++ Write course rather than history, default yes. ++

sport option

++ Sport: Biking (deflt), Running, MultiSport, Other. ++

Geocaching.com .loc (geo)

++ This format can... ++

  • ++ read and write waypoints ++

This format has the following options: deficon, nuke_placer .

++This format supports the Geocaching.com/EasyGPS ".loc" format. This format ++was created specifically for Geocaching.com and is not the same as the ++standard EasyGPS .loc format. See the EasyGPS ++or GPX formats for more general EasyGPS support. ++

++This is a simple XML-based format containing only very basic information ++about geocaches. If you can use the GPX ++format from Pocket Queries instead, you should consider doing so as it is a much richer format. ++

++We have a separate page describing how to send from Geocaching.com pages to GPS ++

deficon option

++ Default icon name. ++

++This option specifies the icon or waypoint type to write for each waypoint on ++output. ++

++If this option is specified, its value will be used for all waypoints, not ++just those that do not already have descriptions. That is, this option ++overrides any icon description that might be in the input file. ++

++There is no list of valid values for this option. ++

++This option has no effect on input. ++

nuke_placer option

++ Omit Placer name. ++

++If this option is specified, GPSBabel will not read geocache placer information ++from a .loc file on input. That is, it will ignore any placer names in the ++input file. ++

++This option has no effect on output. ++

Geogrid-Viewer ascii overlay file (.ovl) (ggv_ovl)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

++ Overlay files used by Geogrid™-Viewer has to be in ASCII format. ++ Make sure you save the files correctly. ++

++ Lines or polygons within the Geogrid™-Viewer (type 3 and 4) will be ++ converted to tracks, except they are grouped. In this case GPSBabel creates routes. ++

++ During the creation of an overlay file, a circle will be added to each ++ position of a waypoint or a route. ++

++ Sample layout of the ASCII overlay file ++ 

++    [Symbol <number # >]
++    Typ=<1=picture,2=Text, 3=line, 4=area, 5=rectangle, 6=circle, 7=triangle>
++    Group=<1=no group, number > 1=group number>
++    Col=<number of the line color>
++    Zoom=<1=no zoom, 2=zoom>
++    Size=<size can be between 101 and 118>
++    Art=<style>
++    Punkte=<number of XKoord>
++    XKoord0=<decimal X coordinate (Longitude) of the waypoint>
++    YKoord0=<decimal Y coordinate (Latitude) of the waypoint>
++    [MapLage]
++    MapName=Top. Karte 1:50.000 Nieders.
++    DimmFc=100
++    ZoomFc=<zoom level of the map>
++    CenterLat=<map center in decimal Y coordinates>
++    CenterLong=<map center in decimal X coordinates of >
++    RefOn=0
++

++

Geogrid-Viewer binary overlay file (.ovl) (ggv_bin)

++ This format can... ++

  • ++ read tracks ++

++ Binary overlay files (.ovl) used by ++ Geogrid™-Viewer. ++

++ Geogrid-Viewer is part of several ++ Top50 ++ map products available in Germany and Austria. ++

++ This module supports binary overlay file format version 2.0, 3.0 ++ and 4.0. Those files can be identified by looking at the first ++ bytes: ++

++hexdump -C example.ovl | head -n 2
++00000000  44 4f 4d 47 56 43 52 44  20 4f 76 6c 66 69 6c 65  |DOMGVCRD Ovlfile|
++00000010  20 56 33 2e 30 3a 00 00  00 08 00 00 00 1e 00 00  | V3.0:..........|
++

++ The current file version 5.0 is not supported. ++

Geogrid-Viewer tracklogs (.log) (ggv_log)

++ This format can... ++

  • ++ read and write tracks ++

++ Binary track logs used by the Geogrid™-Viewer, a very ++ popular product in Germany. ++

++ GPSBabel has full support for version 1.0 of this file format. ++

++ We can also read some GPS data (including coordinates) from version 2.5. But ++ it seems, that this newer version no longer stores time stamps. This can be ++ a problem when converting to other formats or if you want to use our track filter. ++

GeoJson (geojson)

++ This format can... ++

  • ++ write waypoints ++

  • ++ write tracks ++

This format has the following options: compact .

++This module supports a subset of the GeoJSON format. ++

++GeoJSON is a poor fit for GPSBabel's internal data structures as GPSBabel ++was designed more around common GPS features (waypoints, tracks, routes) ++than about GIS-style concepts like MultiPolygons or Geometry Collections. ++In reality, for all but the most simple uses (such as converting a format ++that GPSBabel supports well to something like Leaflet, you should not expect ++high fidelity transfers through this format. ++

++Initially, only write support for waypoints and tracks is available. ++Waypoints are converted to a FeatureCollection of Points. ++The properties for name and description are written, where available. ++Tracks are converted to a LineString. ++

++Potential future work includes the ability to read Point Features and/or ++LineStrings as these would map into our concept of waypoints and ++routes/tracks. ++The potentially nested/recursive nature of GeoJSON in general would be ++an awkward implementation. ++

++Initial development was free-handed by looking at the GeoJSON RFC. Corner cases were handled by ++using GDAL's ogr2ogr ++to convert GPX to JSON and compare the output. The results were then ++ JSON validated and viewed on ++ JSON web viewer. ++

compact option

++ Compact Output. Default is off.. ++

++ This option, when set, reduces the amount of whitespace in the ++ generated GeoJSON. This reduces the size, especially when uncompressed, ++ but reduces the readibility to humans. ++

GEOnet Names Server (GNS) (geonet)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ Input support for the GEOnet Names Server (GNS) country ++ file structure. Export to this format is not possible, as this format ++ has too many fields that we never get populated by any other ++ format. ++

GlobalSat DG-100/BT-335 Download (dg-100)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: erase, erase_only .

++ Serial download protocol for the GlobalSat DG-100™, ++ GlobalSat BT-335™, ++ and GlboalSat BT-338X™GPS data loggers. ++

++ While the DG-100 has a button to record waypoints, they seem to be indistinguishable ++ from trackpoints. Therefore, all points will be presented as trackpoints, ++ regardless of whether they were recorded automatically or manually. ++

++ GlobalSat DG-100 ++

Example 3.11. Command showing DG-100 download and erase on Linux

gpsbabel -t -i dg-100,erase -o gpx /dev/ttyUSB0 outputfile.gpx


Example 3.12. Command showing DG-100 erase_only option on Linux

gpsbabel -t -i dg-100,erase_only /dev/ttyUSB0


++ The DG-100 provides a physical USB interface to the host computer, but ++ internally it uses a Prolific PL-2303 chip to do this. So you must have ++ drivers installed on your computer to recognize the PL-2303 and provide ++ that data as a serial port to software like GPSBabel. Such software ++ comes with the unit for Windows. Prolific provides software for Mac OS/X, ++ but unfortunately their driver has a defect which makes it unstable with ++ GPSBabel. ++

erase option

++ Erase device data after download. ++

This option erases the track log from the device after download.

erase_only option

++ Only erase device data, do not download anything. ++

++ Much like the erase this optio erases the data in the GPS. ++ It does not transfer data before doing so, making it much faster. This may ++ be handy in a work flow where you want to transfer the data from the GPS, ++ check it on a map, and then remove it from the unit. ++

GlobalSat DG-200 Download (dg-200)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: erase, erase_only .

Serial download protocol for the GlobalSat DG-200™GPS data loggers.

++GlobalSat DG-200 ++

Example 3.13. Command showing DG-200 download and erase on Linux

gpsbabel -t -i dg-200,erase -o gpx /dev/ttyUSB0 outputfile.gpx


Example 3.14. Command showing DG-200 erase_only option on Linux

gpsbabel -t -i dg-200,erase_only /dev/ttyUSB0


++ The DG-200 provides a physical USB interface to the host computer, but ++ internally it uses a Prolific PL-2303 chip to do this. So you must have ++ drivers installed on your computer to recognize the PL-2303 and provide ++ that data as a serial port to software like GPSBabel. Such software ++ comes with the unit for Windows. Prolific provides software for Mac OS/X, ++ but unfortunately their driver has a defect which makes it unstable with ++ GPSBabel. ++

erase option

++ Erase device data after download. ++

This option erases the track log from the device after download.

erase_only option

++ Only erase device data, do not download anything. ++

++ Much like the erase this optio erases the data in the GPS. ++ It does not transfer data before doing so, making it much faster. This may ++ be handy in a work flow where you want to transfer the data from the GPS, ++ check it on a map, and then remove it from the unit. ++

GlobalSat GH625XT GPS training watch (globalsat)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: showlist, track, dump-file, input-is-dump-file .

++ Serial download protocol for the GlobalSat Sport gh625XT™ training watch. ++

++The GlobalSat Sport GPS training device present themselves as USBserial devices. ++To get the training just connect the device using the supplied ++USB cable to your computer and the device will show up as a serial device. ++

gpsbabel -i globalsat -f /dev/ttyUSB0 -o gpx,garminextensions -F outfile.gpx

Example 3.15. Command showing list of tracks on device

gpsbabel -i globalsat,showlist=1 -f /dev/ttyUSB0


Example 3.16. Command track can be used to fetch a single track, defult is all tracks

gpsbabel -i globalsat,track=number -f /dev/ttyUSB0 -o gpx,garminextensions -F outfile.gpx


++ The gh625XT USB cable provides a physical USB interface to the host computer, but ++ internally it uses a Prolific PL-2303 chip to do this. So you must have ++ drivers installed on your computer to recognize the PL-2303 and provide ++ that data as a serial port to software like GPSBabel. Such software ++ comes with the unit for Windows or can be downloaded. ++

showlist option

++ list tracks. ++

++The showlist argment displays the list of tracks stored on the device. ++

Example 3.17. Command showing list of tracks on device

++ gpsbabel -i globalsat,showlist=1 -f /dev/ttyUSB0 ++


track option

++ get track. ++

++The 'track' option is used to fetch a single named track, probably one you ++learned about via the 'showlist' option from a previous invocation, instead ++of fetching all the tracks, which is our default. ++

Example 3.18. Command track can be used to fetch a single track, defult is all tracks

gpsbabel -i globalsat,track=number -f /dev/ttyUSB0 -o gpx,garminextensions -F outfile.gpx


dump-file option

++ Dump raw data to this file. ++

++The dump-file option is primarly for debugging is module. It lets you ++provide a file which contains the raw stream of bytes coming from the ++device. This is useful for capturing device state to describe to a ++developer that can't actually access hte physical device as well as mocking ++the entire device for automated regression testing. ++

++

++gpsbabel 
++-i glboalsat,dump-file=gh625xt.bin -f /dev/ttyUSB0
++

++can be used to read the device and store its state in the file gh625xt.bin. That file can then be distributed and someone else can ++read it with a command line: ++

++ gpsbabel 
++-i globalsat,input-is-dump-file=1 -f gh625xt.bin -o gpx -F test.gpx
++

++

input-is-dump-file option

++ Dump raw data to this file. ++

++This is the companion to dump-file and is used to tell the reader that ++the code is talking to a stored file and not physical hardware. ++

Google Directions XML (googledir)

++ This format can... ++

  • ++ read tracks ++

This format is designed to read the XML emitted when you ++use the ++ Google Directions API. ++

++If you use a Unix-compatible ++operating system, this shell script might be useful: ++

++#!/bin/sh 
++FROM="233 S. Upper Wacker Dr, Chicago, IL" 
++TO="1060 W. Addison St, Chicago, IL" 
++URL="http://maps.googleapis.com/maps/api/directions/xml"
++wget -O - "$URL?origin=$FROM&destination=$TO&sensor=false" \
++2>/dev/null >google_map.xml
++gpsbabel -i googledir -f google_map.xml -o gpx -F google_map.gpx
++

Google Earth (Keyhole) Markup Language (kml)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: deficon, lines, points, line_width, line_color, floating, extrude, track, trackdata, trackdirection, units, labels, max_position_points, rotate_colors, prec .

++KML, the Keyhole Markup Language format, was used by Keyhole and is used by ++Google Earth. ++

There are concepts in KML that GPSBabel can't support very well on ++read because they don't map well into other programs. For example, KML has ++ideas of camera views and names and descriptions can have arbitrarily ++complicated HTML in them. KML files may have tiered "Styles" which ++can identify sizing info and URLs of associated icons. Reading such ++files with GPSBabel - even if your goal it to write it back out as KML - can often ++have surprising results. Simple files with waypoints and paths (which ++GPSBabel represents internally as tracks) work fine. ++

++Google Earth also uses GPSBabel internally for receiver communications ++and several file format imports and exports. ++

++In general, GPSBabel's KML writer is relatively strong. GPSBabel handles simple KML on read fairly well, but if you're dealing with handcrafted KML that uses extensive features that have no analog in other formats like nested folders, ringgeometry, camera angles, and such, don't expect GPSBabel to do well with them on read. ++

++ Google Earth 4.0 and later have a feature that can surprise users of this ++ format. Earth's "time slider" feature controls what timestamped data ++ gets displayed. If you're using data that has timestampes (e.g. GPX ++ points that contain time or almost any track data) this will be important ++ to you. The time slider defaults to the far left position and fully closed. ++ This means that only the first data point will be displayed. You can ++ tweak Earth's settings to "view->show time->never" or ++ you can widen the time slider to show the range of data of interest. ++

++ See Google Earth's documentation on timelines for more info. ++

deficon option

++ Default icon name. ++

++This option specifies the default name for waypoint icons ++

lines option

++ Export linestrings for tracks and routes. ++

++When this option is nonzero, GPSBabel draws lines between points in ++tracks and routes. The default value for this option is 1, which causes ++lines to be drawn by default. To disable line-drawing, specify ++lines=0. ++

points option

++ Export placemarks for tracks and routes. ++

++When this option is nonzero, GPSBabel draws placemarks for tracks and routes. ++The default value for this option is 1, which causes placemarks to be drawn. ++To disable drawing of placemarks, specify points=0. ++

line_width option

++ Width of lines, in pixels. ++

++This option specifies the width of the drawn lines in pixels. The default ++value is six pixels. ++

line_color option

++ Line color, specified in hex AABBGGRR. ++

++This option specifies the line color as a hexadecimal number in ++AABBGGRR format, where A is alpha, B is blue, G is green, and R is red. ++

floating option

++ Altitudes are absolute and not clamped to ground. ++

++When this option is nonzero, altitudes are allowed to float above or below ++the ground surface. By default, this option is zero so that altitudes are ++clamped to the ground. Specify floating=1 to allow them to ++float. ++

++This option is more useful to pilots than to hikers. ++

extrude option

++ Draw extrusion line from trackpoint to ground. ++

++This option is a boolean flag to specify whether Google Earth should ++draw lines from trackpoints to the ground. It defaults to '0', which ++means no extrusion lines are drawn. The option of '1' is, of course, ++most useful for points that aren't actually on the ground such as those ++be captured from planes. ++

track option

++ Write KML track (default = 0). ++

++ This is a boolean flag, defaulting to '0', that controls whether GPSBabel ++ writes the <Track> tag that Google introduced in Earth 5.2 for tracks. You ++ may need to turn this off if you have a KML reader that's confused by new ++ tags or if size is critical. ++

++ Routes and tracks without sufficient time data are always drawn as ++ Linestrings and never Tracsks. ++

trackdata option

++ Include extended data for trackpoints (default = 1). ++

++This is a boolean flag that controls ++whether GPSBabel writes extensive data for each trackpoint generated. ++By default computed speed, timestamps, and so on are written with the default ++of '1' for this option. If you are writing large tracks and do not value ++this information, you can reduce the size of the generated file substantially ++by turning this flag off by setting it to '0'. ++

trackdirection option

++ Indicate direction of travel in track icons (default = 0). ++

++ If set, this options creates directional icons for trackpoints. Arrows ++ will show the direction of travel on drawn tracks and routes. ++

units option

++ Units used when writing comments ('s'tatute, 'm'etric,' 'n'autical, 'a'viation). ++

++Units is a simple option. Specify 's' for "statute" (miles, feet, and ++other things that don't sensibly convert to each other, but are craved ++by Americans), 'm' for "metric", 'n' for "nautical" or 'a' for "aviation". Default is 's'. ++

labels option

++ Display labels on track and routepoints (default = 1). ++

++When this option is zero, no labels are added for track and route points. ++This option defaults to one, so labels are added by default. ++

max_position_points option

++ Retain at most this number of position points (0 = unlimited). ++

++ This option allows you to specify the number of points kept ++ in the 'snail trail' generated in the realtime tracking mode. ++

rotate_colors option

++ Rotate colors for tracks and routes (default automatic). ++

++With this option GPSBabel uses different colors for each track or route. ++If this option is used without a value then the colors are automatically selected such ++that the spectrum will be rotated through once for all the tracks and once for all the routes. ++If this option is used with a positive value then the value is interpreted as the number of degrees ++in the color circle between adjacent tracks or routes. ++This option takes precedence over line_color. ++

prec option

++ Precision of coordinates, number of decimals. ++

++This option specifies the number of digits to be used when ++writing coordinate values. ++Precision is the number of digits after the decimal point. The default ++precision is 6. We limit the number of places we write to improve the ++fidelity when round-tripping thata, reduce file size, and reduce ++silliness in files caused by repeating decimals in insignificant ++digits. ++

++As a guideline, at the equator, five decimal places is about 1.1 m, ++placing it below the accuracy of commodity consumer GPS gear. Six places ++is 0.11 m, achievable via surveyor grade and differential corrected GPS. ++Seven is 11 millimeters. ++

++This value is ignored on read and has no impact on the internal ++representation of data. ++

Google Navigator Tracklines (.trl) (gnav_trl)

++ This format can... ++

  • ++ read and write tracks ++

++ Binary (little endian) tracklogs containing coordinates, timestamps and altitude values. ++

++ Google Navigator is an application for PDAs ++ running under Windows Mobile 5.0 or 6.0. ++

++

Table 3.4. Track point structure (16 bytes)
PositionData typeField info
032-bit signed intUnix timestamp
432-bit floatLatitude
832-bit floatLongitude
1232-bit floatAltitude (!rotated left by eight bits!)


++

GoPal GPS track log (.trk) (gopal)

++ This format can... ++

  • ++ read and write tracks ++

This format has the following options: date, maxspeed, minspeed, clean .

++ The gopal format is a track format written by the ++ GoPal Navigation program. ++

++ The format of the file itself is quite simple:

++ 

++        Fileformat GoPal
++        TICK;   TIME UTC; LONG;    LAT;       HEIGHT; SPEED km/h;  FIX; HDOP;     SAT
++        3801444, 080558, 2.944362, 43.262117, 295.28, 0.12964, 2, 2.900000, 3
++

++ ++Filenames are automatically created by the device as follows: ++ 

++        trackYYYYMMDD_HHMMSS.trk

++ and/or, depending on software version and settings: ++ 

++		A_YYYYMMDD_HHMMSS.trk
++

++ with HHMMSS local time (not UTC!) ++

++The file format lacks the correct date value for each trackpoint, so it has to be computed starting from the ++date given in the filename. To handle files without a parsable date in the ++name, the command line option 'date' is provided. ++

++Conversions from gopal into any other format are a bit lossy concerning the first field of each line wich looks like an useless time tick value ++and is simply discarded while reading. If written, there will be a time_t value from the current (computed) timestamp. ++

++Somewhere around Gopal 4.8 or 5.0, Electrobit added three more fields to the end of this format. They are, in order, date (which eliminates most of the silliness above), an unknown field, and a bearing. GPSBabel now reads the date and ignores the other two. We don't yet write these three fields for compatibility with earlier versions. ++

++ ++Filtering out invalid data points is handled by the options 'clean', 'minspeed' and 'maxspeed'. ++For each datapoint the speed needed to come the from the last valid point is ++calculated and compared with the limits. ++Thus one cat easily discard unreliable points. ++ ++

date option

++ Complete date-free tracks with given date (YYYYMMDD).. ++

++ This option is useful if you have tracks from Gopal that have been renamed. ++

maxspeed option

++ The maximum speed (km/h) traveling from waypoint to waypoint.. ++

++ This is useful for removing wildly erroneous data from your recorded track. ++

minspeed option

++ The minimum speed (km/h) traveling from waypoint to waypoint. Set &gt;0 to remove duplicate waypoints. ++

++ If this is greater than zero, duplicate waypoints will be removed. ++

clean option

++ Cleanup common errors in trackdata. ++

++ Specifying the clean flag makes the Gopal reader pass ++ over the data and discard data that is probably incorrect such as the ++ longitude and latitude of "0". ++

++ If you happen to be a boater or pilot off the south short of Ghana, ++ you may disagree that coordinates of "0, 0" are bad. ++

GPS Tracking Key Pro text (land_air_sea)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++Read-only support for the text format exported by Land Air Sea's (Windows only) Past-Track software. This may also work for importing text formatted files from Victoria GPS Tracking, GPS Tracking Key and Land Air Sea's other devices. ++

++Implementation ++

++The text format of the GPS Tracking Key Pro contains one route coordinate per line and is of the format: ++

++01-24-2011,09:12:30,N 48°51'57.9738",W 123°11'48.1354",20.5mph,83.8°,357ft ++

++GPS Babel style file correctly imports all data except for bearing (which is un-needed). Since there is no way to create waypoints or routes on the device itself, the text file is read in as one large track. ++

GPS TrackMaker (gtm)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

Input and output support for waypoints, tracks and routes in ++ the GPS TrackMaker ++ binary format.

Code implemented by Gustavo Niemeyer.

GPSBabel arc filter file (arc)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++This format is used by GPSBabel itself as the input to the ++arc and ++polygon filters. See those filters ++for more information. ++

++The arc format reads two numeric fields, a latitude and a longitude, ++in any format recognized as human ++readable and writes as simple degrees decimal. It really is ++intended for GPSBabel's own internal use more than general use, though ++it turns out to be a convenient way of expressing simple polylines and ++polygons. ++

GpsDrive Format (gpsdrive)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

GpsDrive way.txt file format. A space separated format ++file. Tested against GpsDrive v 1.30 found at gpsdrive.de. ++Contributed by Alan Curry.

GpsDrive Format for Tracks (gpsdrivetrack)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

Format used by GpsDrive to save tracks. Like GPSDRIVE a ++space separated format file. See above for a link to GpsDrive. ++Contributed by Tobias Minich.

GPSman (gpsman)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

GPS Manager ++can read and write formats GPSBabel doesn't understand. The format defaults ++(WGS84, DDD) work reliably. Tracks, routes, and non-default format options ++are not supported. ++

This format is documented at the GPS Manager ++ doc site. ++

gpsutil (gpsutil)

++ This format can... ++

  • ++ read and write waypoints ++

The format we call gpsutil is a simple file format used by a program that runs ++on POSIX- compliant OSes like UNIX and Linux. Reads and writes of ++this format are very reliable. (The lead ++developer of GPSBabel also contributed to this that 'gpsutil' ++the early days.)

++ Note that 'gpsutil' is a different format - and program - than the one called GPS Utility; for that one, you should probably use our PCX module. ++

GPX XML (gpx)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: snlen, suppresswhite, logpoint, urlbase, gpxver, humminbirdextensions, garminextensions .

This is one of the most capable and expressive formats of all the file ++formats supported by GPSBabel. It is described at topografix.com and is ++supported by EasyGPS, ExpertGPS, and many other programs described at ++topografix.com ++

++GPSBabel's reader of this module attempts to preserve tags it doesn't ++really understand. It also tries to glean interesting data from ++

pocket queries from Geocaching.com,
Garmin's "gpxx" GPX extensions,
Humminbird's "h" GPX extensions.

++

snlen option

++ Length of generated shortnames. ++

++ When used with the -s to control shortnames, the snlen suboption to GPX controls how long the generated smartname will be. This can be useful for cases like writing GPX files to a GPS that has a fixed waypoint name length. ++

suppresswhite option

++ No whitespace in generated shortnames. ++

++When used with the -s to generate smart shortnames, this suboption controls whether whitespace is allowed in the generated shortnames. ++

logpoint option

++ Create waypoints from geocache log entries. ++

++ When reading Groundspeak Pocket Queries , the logpoint option creates additional waypoints from the log entries. ++

++ A typical use for this is to get coordinates read from "corrected coordinates" logs. ++

urlbase option

++ Base URL for link tag in output. ++

++ This is a fairly esoteric option. If the GPX file you are reading has only base pathnames (e.g "foo.html") the value you specify to this argument will be prepended to that. For example, "-o gpx,urlbase=c:\My Documents\Whatever" would result in the link to that waypoint being written to refer to c:\My Document\WHatever\foo.html ++

gpxver option

++ Target GPX version for output. ++

++This option specifies the version of the GPX specification to use for ++output. The default version is 1.0 unless one or more of the input files ++is GPX 1.1, then it's 1.1. The only other valid value for this ++option is 1.1. ++

++Notice that this is not a full scale XML schema conversion. In particular, ++if you have a GPX 1.0 file that has extended namespaces in it (such as a ++pocket query from Geocaching.com) just writing it with this option will ++result in a horribly mangled GPX file as we can't convert the schema data. ++

humminbirdextensions option

++ Add info (depth) as Humminbird extension. ++

++Implies gpxver=1.1 ++

garminextensions option

++ Add info (depth) as Garmin extension. ++

++ Write Garmin-specific extensions, when such data is available, to the GPX. ++ Notably, depth, temperature, proximity, display color, ambient temperature, ++ heart rate, and cadence are read when they are available in the source data. ++ This data can, of course, only be read by GPX readers that know about the ++ Garmin gpxtpx and gpxx extended namespaces. ++

++Implies gpxver=1.1 ++

HikeTech (hiketech)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

++ This is the .gps format used by the Mac OS X applications ++ written by HikeTech. These include TopoDraw, Link2GPS, and GPSWrite. ++ More information about these products can be found at ++ hiketech.com ++

Holux (gm-100) .wpo Format (holux)

++ This format can... ++

  • ++ read and write waypoints ++

The Holux gm-100 (e-fox) gps receiver uses standard ++compact flash cards. File formats were provided by Holux-Taiwan ++holux.com to the author. ++The code was tested against version 2.27E1; other versions and ++receivers may work but have not been explicitly tested. Anyone with ++information on other Holux receivers is encouraged to contact ++jochen@bauerbahn.net. ++

When copying the .wpo file to a flash card, the file must ++be named tempwprt.wpo as the ++receiver will ignore all other files. ++

Comparing the waypoints of a .wpo files against other ++formats like .gpx you may notice a small difference in the latitude ++and longitude values. The reason is the low resolution of the ++coordinates in the wpo file format. In a .wpo file the resolution is ++1/10"; in gpx for example it is 1/100". A a practical matter, this ++loss is only about 1.7 meters (5 feet). ++

The generated waypoint failes can also be used by MapShow ++version 1.14. This program is free of charge from the Holux web site. ++

This format was contributed by Jochen Becker. ++

Holux M-241 (MTK based) Binary File Format (m241-bin)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: csv .

++ The Holux m241 is a small datalogger using the MTK chipset, with ++ a couple small differences in the binary format. In its default ++ configuration, it can store ~100000 trackpoints with very limited ++ data; to configure extended logging you can use the BT747 open ++ source software ++ bt747 ++ Waypoint storage is possible only if "recording reason" (RCR) is enabled in the settings. ++

++ Holux GPSport 245 is a datalogger with display suitable for cycling, walking and running. ++ It can store ~200k trackpoints with limited data. The m241 and m241-bin format is ++ able to automatically detect GPSport 245 data and handle the differences from Holux M-241 devices. ++ Note: GP245 does not log any quality of the position. ++

++ Use the m241 format to connect with the unit serially and m241-bin to read files saved by the device. ++

csv option

++ MTK compatible CSV output file. ++

++ Specifies a filename into which MTK-compatible CSV output will be written. ++

Holux M-241 (MTK based) download (m241)

++ This format can... ++

  • ++ read tracks ++

This format has the following options: erase, erase_only, log_enable, csv, block_size_kb .

++ The Holux m241 is a small datalogger using the MTK chipset, with ++ a couple small differences in the binary format. In its default ++ configuration, it can store ~100000 trackpoints with very limited ++ data; to configure extended logging you can use the BT747 open ++ source software ++ bt747 ++ Waypoint storage is possible only if "recording reason" (RCR) is enabled in the settings. ++

++ Holux GPSport 245 is a datalogger with display suitable for cycling, walking and running. ++ It can store ~200k trackpoints with limited data. The m241 and m241-bin format is ++ able to automatically detect GPSport 245 data and handle the differences from Holux 241 devices. ++ Note: GP245 does not log any quality of the position. ++

++ Use the m241 format to connect with the unit serially and m241-bin to read files saved by the device. ++

++ This module is also reported to handle the Holux M1000c. ++

++ Most of the loggers cannot receive bluetooth commands, they can only send ++ data. Since GPSBabel needs to send commands to the GPS device it won't ++ work. Download the data using the USB cable instead. ++

erase option

++ Erase device data after download. ++

This option erases the track log from the device after download.

erase_only option

++ Only erase device data, do not download anything. ++

This option will only erase the logger data. No data is downloaded.

This option is typically used as a second step after the data has been downloaded and verified.

log_enable option

++ Enable logging after download. ++

This option will enable the logger after download.

By default the logger is re-enabled when download is finished if previously were enabled. ++But if the download is aborted or failed the log functionality won't be enabled again.

csv option

++ MTK compatible CSV output file. ++

++ Note that this option is a bit of an oddity in the GPSBabel arsenal. This ++ should probably be a "real" output type of its own instead of being bolted ++ onto an input type. ++

block_size_kb option

++ Size of blocks in KB to request from device. ++

Honda/Acura Navigation System VP Log File Format (vpl)

++ This format can... ++

  • ++ read tracks ++

++ This is the log format output by factory-installed Honda/Acura (Alpine) Navigation Systems ++ in (at least) 2006 models and newer. (Though I've seen indirect data that says that Acura ++ nav systems at least as far back as 2004 use it too) ++

++ This format is definitely known to work with the following model cars specifically: ++

++ 2006 Honda Civic Hybrid ++

++ Logging may be enabled by simultaneously holding down the MAP/GUIDE, MENU, and CANCEL ++ buttons for 3-5 seconds, then selecting "Functional Setup", "Log Data". A PCMCIA card ++ must be inserted into the system (behind the Nav LCD) for logging to work. (The system ++ can read MP3/WMA files on this card and will also write logs to it. Generally, a ++ PCMCIA to CF or PCMCIA to SD adapter is used with a corresponding CF/SD card) With ++ logging successfully set up, the system will create a directory named "VPlog" off the ++ root of the card. Inside this directory, files will be created with names corresponding ++ to the date and time of engine start, in GMT. (YYMMDD_HHMM.vpl) ++

++ The VPL format contains quite a bit of data, much of which remains undecoded. This format ++ currently reads only lat/lon, altitude, speed, heading, date/time, visible sats, HDOP and ++ VDOP. ++

++ Generally, the layout of the format seems similar to NMEA, with discrete sentences ++ containing different fields of data, followed by a 1-byte XOR'd checksum. Some sentences ++ are generated only once per engine start, others every few seconds, many every second, ++ and a few on the order of five and in one case, up to twenty five times per second. All data in ++ the file is written in ASCII; most of it simply as hexadecimal characters. Most ++ fields are fixed width, though a few can be variable. (Those that are variable ++ have a field count as the first field after their sentence identifier) Currently, ++ only the '75'-sentence is processed (and only about 70% of it), though this provides all ++ the data necessary for position information. ++ ++ Some fields in other sentences have been decoded, but they are not currently processed. ++ Information on the data in these fields can be found in vpl.c. ++

HTML Output (html)

++ This format can... ++

  • ++ write waypoints ++

This format has the following options: stylesheet, encrypt, logs, degformat, altunits .

++ GPSBabel's HTML output generates a single HTML file of all of the ++ waypoints in the input file. It supports a number of Groundspeak GPX ++ extensions and filters out potentially harmful HTML from the ++ input file while maintaining almost all of the source HTML formatting. ++ This makes this format well suited for generating HTML to hand to programs ++ like Plucker for putting in a PDA and especially so for "paperless caching" ++ for Geocachers with pocket queries. ++

++ This format is similar to the text format. ++

++ The following command line reads a GPX file with ++ Groundspeak extensions and writes an HTML file with encrypted hints ++ that is rendered using a custom stylesheet: ++

++ gpsbabel -i gpx -f 12345.gpx -o html,stylesheet=green.css,encrypt -F 12345.html ++

stylesheet option

++ Path to HTML style sheet. ++

++Use this option to specify a CSS style sheet to be used with the ++resulting HTML file. ++

encrypt option

++ Encrypt hints using ROT13. ++

++Use this option to encrypt hints from Groundspeak GPX files. ++

logs option

++ Include groundspeak logs if present. ++

++Use this option to include Groundspeak cache logs in the created document. ++

degformat option

++ Degrees output as 'ddd', 'dmm'(default) or 'dms'. ++

++When GPSBabel writes coordinates, this option is consulted to see if it ++should write decimal degrees ('ddd') decimal minutes ('dmm') or degrees, ++minutes, seconds ('dms'). The default is 'dmm'. ++

altunits option

++ Units for altitude (f)eet or (m)etres. ++

++This option should be 'f' if you want the altitude expressed in feet and ++'m' for meters. The default is 'f'. ++

Humminbird tracks (.ht) (humminbird_ht)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read and write tracks ++

  • ++ read routes ++

See the Humminbird ++format for docs on this.

Humminbird waypoints and routes (.hwr) (humminbird)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read tracks ++

  • ++ read and write routes ++

++ This format supports: ++

Humminbird ++ waypoints and routes (.hwr files)
Humminbird ++ tracks (.ht files)
Humminbird ++ .dat files. (These accompany the ++ .png files you get when you take snapshots. ++ There are also .dat files generated when making ++ recordings, but those are not supported here.)

++

++ If you do "save all nav data" on the device, you'll get a ++ data.hwr and a 000.ht file on the ++ flash card (on a 797 in the matrix directory). ++

++ The humminbird module can read all of these file formats, but you need to ++ tell it which ones to write. By default, you get a .hwr ++ file, to get a track (.ht file), use the ++ "humminbird-track" format. ++

++

++

++Note:.dat files are read-only, they only make sense ++together with their images. ++

++ Supported models: ++

797c2i SI

++ (They should all work, but this is the only one tested so far.) ++

++ Known limits: ++

max 12 characters for waypoint names.
max 20 characters for route and track names.
max 50 points per route. Use simplify filter (count=50 or less) if you have routes with more points!
max 21835 points per track.

++

IGN Rando track files (ignrando)

++ This format can... ++

  • ++ read and write tracks ++

This format has the following options: index .

++This format supports IGN Rando track files. IGN Rando is a program mainly ++used in France for Topo maps. The files are XML based and are "windows-1252" ++encoded. Trackpoints do not have time stamps. ++

index option

++ Index of track to write (if more than one in source). ++

++Because the format supports only one track, this option may be used ++on output to select a single track from a collection of ++tracks read from a more expressive format. If you have, say, a ++gpx file that contains two tracks, you may ++use this option to write them one at a time to individual files. ++

gpsbabel -i gpx -f tracks.gpx -o ignrando,index=1 -F track1.txt -o ignrando,index=2 -F track2.txt

iGo Primo points of interest (.upoi) (igoprimo_poi)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ igoprimo_poi supports POI files from iGo Primo™ 'next generation ++ navigation' devices. iGo Primo is GPS Navigation Software that runs on Windows embedded ++ platforms, and is used in some OEM and aftermarket automotive head units. ++

iGO2008 points of interest (.upoi) (igo2008_poi)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ igo2008_poi supports POI files from Nav N Go iGO 8 Europe™. ++ This is a GPS Navigation Software for Windows Mobile™ based ++ PDA devices and Smartphones. ++

IGO8 .trk (igo8)

++ This format can... ++

  • ++ read and write tracks ++

This format has the following options: tracknum, title, description .

++ iGo8 is the successor to the "iGo My way" software package that is reasonably ++ prolific for GPS devices manufactured by Mio, Sony, LG, as well as many other ++ small manufacturers. iGo8 is notable in that it has full 3D rendering of ++ terrain as well as buildings and landmarks for most large cities. The ++ software can also be bought pre-loaded on a mico-SD card for use in many PPC ++ phones that are GPS enabled. ++

++ The track format used by iGo8 is rather rudimentary, consisting of a list of ++ coordinates and a time resolution of 1 second. While iGo8 supports exporting ++ tracks to GPX format, importing tracks is not natively supported. ++

tracknum option

++ Track identification number. ++

++ This option isn't entirely clear. It appears to be a unique number ++ for each track that is used for coloring on the main display. So if you ++ want two tracks to have different colors, set the track numbers to ++ different values. ++

++ If you can provide a better description of this option, please do contact ++ us. ++

title option

++ Track title. ++

++ Use this option to set the title of the track. ++

description option

++ Track description. ++

++Use this option to the description of the track which is text appears just below the track title in the track list on the device. ++

Jelbert GeoTagger data file (jtr)

++ This format can... ++

  • ++ read and write tracks ++

++ From the file format description: ++

++ The JTR file format is used by the Jelbert GeoTagger device to record ++ location information relating to where photographs have been taken. ++ One record entry is created for each press of the shutter on the ++ camera. ++

++ The JTR file format will be updated in the future so it is important to ++ check for the current version ID within the file that is present at the ++ beginning of each line of data. It is currently “GEOTAG2” ++

++ Each line of the JTR file currently starts with the word “GEOTAG2” ++ followed by a comma and then two NMEA sentences separated by a ++ comma character with a CR at the end. The $GPRMC (date, time and ++ position) data is followed by the $HCHDG (magnetic compass) data. ++

++ Although the $GPRMC data segment contains a compass bearing, this ++ should be ignored unless the $HCHDG compass direction is null which ++ can happen if the electronic compass is switched off. Use the magnetic ++ compass bearing in preference to the GPS derived compass. ++ The two NMEA checksums can be ignored for the time being. ++

Jogmap.de XML format (jogmap)

++ This format can... ++

  • ++ read tracks ++

++ This read-only format reads the XML marker files from Jogmap as tracks. Each "markers" entry is a new track with each "marker" entry being a trackpoint. ++

Kompass (DAV) Track (.tk) (kompass_tk)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ This module supports track files used by Kompass and DAV "Deutscher Alpenverein". ++

++ Kompass is a publishing company from Austria. ++ If you want to get more information about DAV, the German alpine association, ++ and if you are familiar with the german language, please have a look at their homepage. ++

Kompass (DAV) Waypoints (.wp) (kompass_wp)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ This module supports waypoint files used by Kompass and DAV "Deutscher Alpenverein". ++

++ Some more information under kompass_tk format. ++

KuDaTa PsiTrex text (psitrex)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This is a text format created by KuDaTa's PsiTrex program ++for the Psion PDAs. The format can't be readily handled by XCSV, so ++this format is handled explicitly. Waypoints, routes and tracks are ++all handled, with icon names used corresponding to version 1.13 of ++PsiTrex. This module was contributed to GPSBabel by Mark ++Bradley.

Lowrance USR (lowranceusr)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: ignoreicons, writeasicons, merge, break, wversion .

++The Lowrance iFinder GPS series has the unique capability within the Lowrance models ++to output its data to an MMC card. The data is saved to the card as a ++.USR file and can be read by your computer using a card reader. ++Waypoints, icons, routes, tracks are supported. Event marker icons contain a symbol, name, latitude and longitude ++only. By default, Event marker ++icons are converted to waypoints on read. On write, you are able to create icons from waypoints. ++

ignoreicons option

++ Ignore event marker icons on read. ++

++This option instructs GPSBabel to not convert icons to waypoints on input, ++but to instead disregard them altogether ++

writeasicons option

++ Treat waypoints as icons on write. ++

++(USR output) This option converts the waypoint information to an event marker icon. ++

merge option

++ (USR output) Merge into one segmented track. ++

++(USR output) This option merges all tracks into a single track with multiple segments. ++

break option

++ (USR input) Break segments into separate tracks. ++

++(USR input) Break track segments into separate tracks. ++file. ++

wversion option

++ (USR output) Write version. ++

++ Newer (post 2006 or so) Lowrance devices added a version three of their ++ .usr file format that adds depth. Specify "3" here to use that format ++ on write. ++

++ ++ gpsbabel ... -o lowranceusr,wversion=2 -F blah.usr ++ ++is exactly the same as ++ ++ gpsbabel ... -o lowranceusr -F blah.usr ++ ++

++To create a file that contains depth but therefore isn't usable ++on older Lowrance products, use this: ++ ++ gpsbabel ... -o lowranceusr,wversion=3 -F blah.usr ++ ++ ++

Lowrance USR version 4 (lowranceusr4)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: title, serialnum, description .

Newer Lowrance HDS ++series units use a new format, USR version 4. Waypoints, routes, ++tracks are supported. The format is not completely understood, so ++certain extended data is ignored, but basic waypoint, route, and track ++details are all present. Icons are not currently deciphered. ++

title option

++ (output) Output title string. ++

serialnum option

++ (output) Device serial number. ++

description option

++ (output) Content description. ++

Magellan Explorist Geocaching (maggeo)

++ This format can... ++

  • ++ read and write waypoints ++

++ This format supports the on-card format used by the ++ Magellan Explorist 400, ++ Explorist 500, Explorist 600, Explorist 210, and Explorist XL ++ to describe geocaches. Notice what while the format can ++ hold an infinite number of geocaches, the unit will read and silently ++ discard all but 200 geocache POIs at a time.

++ You should name any file created with this format with a ".gs" extension ++ so the firmware can read it. ++

++ This format does support reading .gs files, but it's kind of a ++ pointless operation as the units can't create or edit these files. ++ Round-tripped data is lossy for all but the most trivial cases as ++ many fields are shortened or discarded on write. "Date last found" is ++ discarded on read as there are no logs stored on the device in which to ++ store the date last found. ++

Magellan Mapsend (mapsend)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: trkver .

++ This format supports the ++ Magellan ++ MapSend™ native file format. ++

++ Kudos to Magellan for having the foresight to document their file formats, ++ making software like this possible. ++

trkver option

++ MapSend version TRK file to generate (3,4). ++

++This option sets the MapSend version to generate TRK files, ++since new MapSend versions can't open version 3 files. ++Valid values are 3 (MapSend v3.0) or 4 (MapSend v4.0 and v4.1). ++

Magellan SD files (as for eXplorist) (magellanx)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: deficon, maxcmts .

++ This is the SD card format used by the Magellan Explorist 400, ++ Explorist 500, Explorist 600, and Explorist XL and internally on those devices plus the ++ Explorist 210. Stored waypoints are identical to the Magellan SD format ++ used by Meridian, but the newer models allow longer waypoint names. Routes are ++ subtly different. ++

++ You should name any file containing waypoints created with ++ this format with a ".upt" extension so the firmware can read it. ++ Similarly, routes should be named ".rte" and tracks should be ++ named ".log". ++

deficon option

++ Default icon name. ++

++ The deficon option is used to control the icon output when writing to this format. It overrides any icon information that might be present in the source data. ++

maxcmts option

++ Max number of comments to write (maxcmts=200). ++

++The maxcmts option allows you to specify the number comments that will ++be sent to the unit. ++

++Magellan receivers allow a maximum of 200 waypoint comments. Unfortunately, ++DirectRoute uses waypoint comments to provide next turn directions for ++navigation pop-ups and that comes from that pool of 200 comments. It ++is therefore sometimes convenient to limit the number of waypoint ++comments written to the receiver. For example, a geocacher might want ++to upload 400 waypoints, but only 190 with comments so that DirectRoute ++could provide driving directions for the next ten turns. ++

Magellan SD files (as for Meridian) (magellan)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: deficon, maxcmts .

GPSBabel supports the following Magellan receivers: ++

310Meridian Color
315Explorist 100 (with aftermarket cable)
Map330Explorist 200 (with aftermarket cable)
SporTrak Map ColorExplorist 300 (with aftermarket cable)
SporTrak MapExplorist 210
SporTrak Map ProExplorist 300
SporTrak Map TopoExplorist 400
Meridian (green or yellow)Explorist 500
Meridian GoldExplorist 600
Meridian PlatinumExplorist XL

++

++ This format is used for both the serial protocol used on the ++ devices with serial ports such as Map330 and Meridian and for ++ the files stored either in either the unit's internal memory ++ (Explorist 210, Explorist 400, Explorist 500, Explorist 600, ++ Explorist XL) or on removable memory. ++

++ If you specify a serial port for the file (.e.g. "COM1", "/dev/ttyS0") ++ to be read or written, GPSBabel will use serial protocol. Specifying ++ a file, either on local filesystem or on a mounted flash card reader, ++ will results in the file-based format being used. ++

deficon option

++ Default icon name. ++

++ The deficon option is used to control the icon output when writing to this format. It overrides any icon information that might be present in the source data. ++

maxcmts option

++ Max number of comments to write (maxcmts=200). ++

++The maxcmts option allows you to specify the number comments that will ++be sent to the unit. ++

++Magellan receivers allow a maximum of 200 waypoint comments. Unfortunately, ++DirectRoute uses waypoint comments to provide next turn directions for ++navigation pop-ups and that comes from that pool of 200 comments. It ++is therefore sometimes convenient to limit the number of waypoint ++comments written to the receiver. For example, a geocacher might want ++to upload 400 waypoints, but only 190 with comments so that DirectRoute ++could provide driving directions for the next ten turns. ++

Magellan serial protocol (magellan)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: deficon, maxcmts, baud, noack, nukewpt .

GPSBabel supports the following Magellan receivers: ++

310Meridian Color
315Explorist 100 (with aftermarket cable)
Map330Explorist 200 (with aftermarket cable)
SporTrak Map ColorExplorist 300 (with aftermarket cable)
SporTrak MapExplorist 210
SporTrak Map ProExplorist 300
SporTrak Map TopoExplorist 400
Meridian (green or yellow)Explorist 500
Meridian GoldExplorist 600
Meridian PlatinumExplorist XL

++

++The RoadMate family of products is not supported. ++

++ This format is used for both the serial protocol used on the ++ devices with serial ports such as Map330 and Meridian and for ++ the files stored either in either the unit's internal memory ++ (Explorist 210, 400, 500, 600, XL) or on removable memory. ++

++ If you specify a serial port for the file (.e.g. "COM1", "/dev/ttyS0") ++ to be read or written, GPSBabel will use serial protocol. Specifying ++ a file, either on local filesystem or on a mounted flash card reader, ++ will result in the file-based format being used. ++

++ Users of the Explorist generation of receivers should probably ++ prefer to use the magellanx ++ format over this one. ++ ++

Important

++This module does not support the units that do not follow Magellan's ++documented communications protocols including:

Maestro 3100 RoadMate 800
Maestro 3140 RoadMate 860T
Maestro 3200 RoadMate 1200
Maestro 3210 RoadMate 1400
Maestro 3220 RoadMate 1412
Maestro 3225 RoadMate 1430
Maestro 3250 RoadMate 2000
Maestro 4000 RoadMate 2000
Maestro 4040 RoadMate 2200T
Maestro 4050 RoadMate 3000T
Maestro 4200 RoadMate 3050T
Maestro 4210 RoadMate 6000T
Maestro 4220 RoadMate AAA
Maestro 4250 Triton 200
Maestro 5310 Triton 300
RoadMate 300 Triton 400
RoadMate 360 Triton 500
RoadMate 500 Triton 1500
RoadMate 700 Triton 2000
RoadMate 760 

deficon option

++ Default icon name. ++

++This option specifies the icon or waypoint type to write for each waypoint on ++output. ++

++If this option is specified, its value will be used for all waypoints, not ++just those that do not already have descriptions. That is, this option ++overrides any icon description that might be in the input file. ++

++This option has no effect on input. ++

maxcmts option

++ Max number of comments to write (maxcmts=200). ++

++The maxcmts option allows you to specify the number comments that will ++be sent to the unit. ++

++Magellan receivers allow a maximum of 200 waypoint comments. Unfortunately, ++DirectRoute uses waypoint comments to provide next turn directions for ++navigation pop-ups and that comes from that pool of 200 comments. It ++is therefore sometimes convenient to limit the number of waypoint ++comments written to the receiver. For example, a geocacher might want ++to upload 400 waypoints, but only 190 with comments so that DirectRoute ++could provide driving directions for the next ten turns. ++

baud option

++ Numeric value of bitrate (baud=4800). ++

++ This option causes GPSBabel to use the given baud rate for serial ++ communications. It must match the given baud rate on the receiver. The ++ default value matches the default on the receiver, 4800. ++

++ Valid options are 1200, 2400, 4800, 9600, 19200, 57600, and 115200. ++

noack option

++ Suppress use of handshaking in name of speed. ++

++Magellan's protocol specification strongly encourages the use of software ++acknowledgements on every packets. This is a simple "this is what I think ++I heard. If you agree that I heard it correctly, let's go to the next packet" ++handshake that is used to ensure the integrity of the data transfer. ++

++Certain firmware versions have problems handling this which makes transfers ++unnecessarily slow. Transfers on all units at high serial speeds are also ++severely restricted by this process. ++

++In controlled environments (good cables, low electrical noise, receiving ++from the unit, not doing donuts with the unit set to "track up" at a 150 ++mile scale with 500 waypoints on the screen) it is sometimes useful to ++release that safety belt by using the "noack" suboption. ++

nukewpt option

++ Delete all waypoints. ++

++This option erases all waypoints in the receiver before doing a transfer. ++

++This is a convenient option to use in automated processes where you want ++to ensure the units starts with a clean state before sending waypoints to ++it. Using this option on transmit is a better idea than doing it on ++receive since the latter would erase all the waypoints before asking the ++unit to send all the waypoints. ++

MagicMaps IK3D project file (.ikt) (ik3d)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

++ This is the format for MagicMaps project (.ikt) files. ++

++ MagicMaps "Das interaktive Kartenwerk"™ is a Software from Germany. It's a ++ route-planning software with a 3-dimensional environment. ++

++ The project files are XML based and we can read the main GPS items (names and coordinates). ++ For an output these files are too complex. ++

Mainnav (mainnav)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++This is the format used by the Mainnav MG-950d data logger. It may work with other Mainnav devices. ++

Map&amp;Guide 'TourExchangeFormat' XML (tef)

++ This format can... ++

  • ++ read routes ++

This format has the following options: routevia .

++TEF, internally called "TourExchangeFormat", is an XML based export format ++used by Map&Guide Motorrad-Routenplaner 2005/06™. ++

++Because this is only an export format, GPSBabel does not support writing to ++this format. ++

++GPSBabel also supports the bcr format, which ++may also be used with this program and supports both reading and writing. ++

gpsbabel -r -i tef,routevia -f in.xml -o gpx -F out.gpx

routevia option

++ Include only via stations in route. ++

++This option may be used to eliminate calculated route points from the route. ++

MapAsia track file (.tr7) (mapasia_tr7)

++ This format can... ++

  • ++ read and write tracks ++

++ Mapking provides a set of tools for GPS ++ navigation.  The location of distributed maps is mainly in Asia, so the software seems ++ not (yet) well known in Europe or US.  Some of the GPS tools (e.g. Mapking 2007 for Windows Mobile) ++ can also be used to write waypoints and save them under the .tr7 format which can be translated by GPSBabel. ++

Mapbar (China) navigation track for Sonim Xp3300 (mapbar)

++ This format can... ++

  • ++ read tracks ++

++ This format is the Mapbar navigation programs used on phones such as ++ the Sonim XP3300 popular in China. ++ The files are found on the sd card in /mapbar/userdata/tracks. ++ This format just logs track point by latitude and longitude; no time ++ information is available. ++

++This was implemented by analyzing data from a Sonin SoninXp3300, ++software version: 3.73.47.39836, data version: B29. ++

++The following devices of using mapbar navigation are supported. Other ++devices with using mapbar navigation maybe be supported, but not have ++not been tested: ++

Sonim Xp3300(China version)

++

Mapfactor Navigator (mapfactor)

++ This format can... ++

  • ++ read and write waypoints ++

++This format can write a favourites.xml file that stores the waypoints in the Mapfactor Navigator street navigation program for Windows and Android OS. The waypoints are listed in the My places menu option. The favourites.xml file are stored in the Navigator directory. ++

++This format can read waypoints from the favourites.xml file to use in other programs. ++

++The format has been tested with Windows 8, Navigator version 12.3 and Android OS, v4.2.2, Navigator version 1.1.5. ++

++The format has been tested with Windows 8, Navigator version 12.3 and Android OS, v4.2.2, Navigator version 1.1.5. ++

++Groups are not supported, as they don't map well to other more common ++file formats. ++

Mapopolis.com Mapconverter CSV (mapconverter)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++Mapconverter is a format that is read by Mapopolis.com's ++mapconverter application. ++

++Mapconverter is an application used to create userland maps and map data for ++Mapopolis.com's Mapopolis program. The mapconverter format is essentially ++waypoint data prepared in a format that the mapconverter application will ++accept. ++

++The steps for using GPSBabel and Mapconverter go something like this: ++

++Step 1: Create a mapconverter file using gpsbabel. ++

gpsbabel -i geo -f geocaching.loc -o mapconverter -F foo.txt

++Step 2: Launch mapconverter.exe and choose foo.txt as your input file. ++ Click the begin button to have mapconverter process foo.txt. ++

++If all goes successfully, you should have a file called "foo.pdb" ready ++for syncing with your PDA. Put it wherever Mapopolis thinks it should be ++on your PDA. ++

Notes

  • ++GPSBabel will write the name of its own output file in the output file ++ it creates as the input for Mapconverter. Mapconverter will replace ++ the extension of this filename with ".pdb". ++

  • ++The PocketPC version of Mapopolis doesn't notice files with the ".pdb" ++ extension. To make this work, change the extension to ".mlp" when ++ copying the mapconverter output to your PocketPC PDA. ++

  • ++Mapconverter only works with Mapopolis version 3.x. Mapopolis version ++ 4 will refuse to load mapconverter maps. There is no known work-around ++ for this at the time of this writing. ++

  • ++Mapconverter is no longer available from the Mapopolis website. If you ++ need a copy of mapconverter, ask on your local GPS Software discussion ++ forum and I'm sure someone will have it. As far as I know, It was never ++ actually acknowledged/supported by Mapopolis to begin with. ++

MapTech Exchange Format (mxf)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

Maptech Exchange Format - Another CSV format file. This ++format complies with (at least) Maptech Terrain Navigator, Terrain ++Professional, Take a Hike, and ExpertGPS import/export MFX. ++Contributed by Alex Mottram.

MediaTek Locus (mtk_locus)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: baudrate, download, erase, status, enable .

++This format is a protocol supports the MediaTek MT3339, a GPS ++chipset that shipped around 2011 that has internal logging capability. ++It is the ++core of at least two GPS modules, including the ++GlobalTop PA6H and the Fastrax IT530. The GlobalTop PA6H module is in ++turn the heart of the Adafruit "Ultimate" GPS breakout board, popular ++in the Arduino "maker" world. ++

++It is similar to the mtk and mtk-bin formats for earlier Mediatek parts. ++

baudrate option

++ Speed in bits per second of serial port (autodetect=0). ++

The default is to autodetect the baudrate, but that can take a few seconds. If you know the baudrate of the device it is faster to specify it explicitly.

Only valid when using a USB device as input.

download option

++ Download logged fixes. ++

This option processes a set of Locus fixes, by downloading it from an ++attached USB device or by reading records stored in a normal file.

You might want to disable this option if all you want to do is erase the memory ++or display the device status. Downloading a large dataset can take several minutes ++and while that is happening no other device commands can be executed.

erase option

++ Erase device data after download. ++

This option erases the track log from the device after download.

Only valid when using a USB device as input.

status option

++ Show device status. ++

This option displays the status of the device after the download is complete. Status includes firmware version, number of log records in memory, interval between fixes, etc.

Only valid when using a USB device as input.

enable option

++ Enable logging after download. ++

This option sets logging on the device to on or off. Setting the logging off does not erase the saved fixes.

Only valid when using a USB device as input.

Memory-Map Navigator overlay files (.mmo) (mmo)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: locked, visible, ver .

++ The 'mmo' format provides support for binary .mmo files used by the ++ Memory-Map Navigator software. ++

++ Our module was reverse engineered from a couple of .mmo files found ++ in the www. The results of the writing code have been tested with a current ++ Memory-Map Navigator trial ('Viewer') release. ++

++ Because of different file versions and sometimes slightly different file structure ++ we cannot ensure, that every .mmo file is loadable at this time. If you have one, ++ which causes errors, please provide it [mailto:gpsbabel-misc@lists.sourceforge.net]. ++

++ More information can be found at the ++ Memory-Map site. ++

locked option

++ Write items 'locked' [default no]. ++

++ By default GPSBabel creates only 'un-locked' items. ++

++ Sample command to write an mmo file with 'locked' items: ++

++ ++ gpsbabel -i gpx -f in.gpx -o mmo,locked=y -F out.mmo ++ ++

visible option

++ Write items 'visible' [default yes]. ++

++ This option can be useful, if you want to convert a big file with a lot of entries. ++ By default GPSBabel creates only 'visible' items. ++

++ Sample command to write an mmo file with 'invisible' items: ++

++ ++ gpsbabel -i gpx -f in.gpx -o mmo,visible=n -F out.mmo ++ ++

ver option

++ Write files with internal version [n]. ++

++Two major strains of Mobile Mapper files have been identified in the wild. Version 17 is reported as "Memory Map OS Edition 2004, Versio 4.2.3 Build 432" and version 18 is used by the large majority of current files. We can read either and when writing, we write version 18 by default. ++

++If you have a particularly old Mobile Mapper installation, it may complain "This file was created with a newer version of the Software" when reading our output.You can get around this if force GPSBabel to create the old format with this option. ++

Example 3.19. Forcing creation of old Mobile Mapper files

++ gpsbabel -i gpx -f whaetever.gpx -o mmo,ver=17 -F whatever.mmo ++


Microsoft Streets and Trips 2002-2007 (s_and_t)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

This is a format for creating data to be read by ++ Microsoft Streets and ++ Trips. It's been exercised on versions from 2003 through 2008. Detailed ++ instructions on how to use it, including preserving hyperlinks, are at ++ gpsbabel.org ++

++ We have an additional page describing how to solve the ++ traveling salesman problem with ++ Streets & Trips to efficiently optimize a trip with many stops, such as ++ is often made by geocachers. ++

++ Since modern versions of Streets and Trips support reading GPX, this format is probably ++ not so useful. ++

MiniHomer, a skyTraq Venus 6 based logger (download tracks, waypoints and get/set POI) (miniHomer)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: baud, dump-file, erase, first-sector, initbaud, last-sector, no-output, read-at-once, Home, Car, Boat, Heart, Bar .

++Serial download protocol for GPS data loggers called "miniHomer". ++These loggers are based on Skytraq Venus 5 and Venus 6 chipsets, but with modified firmware. ++The miniHomer logger has five POI (or better: Point-to-Return, PTR?), which can be set programatically. The miniHomer module in gpsbabel is an extension of the skytraq module. ++

++Following a list of devices which should be supported by this module ++(Note that not all of them have actually been tested, so if you can confirm that additional models work, please mail the gpsbabel-misc group with your success, tips, and any pertinent links for your model.) ++

Table 3.5. Devices supported by miniHomer module
ManufacturerModelUSB (baud)Bluetooth (baud)
++ Navin ++ Z:NEX ++ miniHomerup to 230400this device does not have bluetooth

Example 3.20. Command showing miniHomer download of tracks and erasing the logger on Linux

gpsbabel -i miniHomer,erase -f /dev/ttyUSB0 -o gpx -F out.gpx


Example 3.21. Command showing miniHomer erasing the logger without download on Linux

gpsbabel -i miniHomer,erase,no-output -f /dev/ttyUSB0


miniHomer has five POI called Home, Car, Boat, Heart, Bar. You can set the lla ++(Latitude, Longitude, Altitude) for each of the POI. The format is ++<name>=<lat>:<lng>[:<alt>] ++Once the according POI symbol is selected on miniHomer, the display shows you the direction and distance to the POI. ++

Example 3.22. Command showing miniHomer setting Car and Home POI

++ ++ gpsbabel -i miniHomer,Car=36.790145:-6.352898,Home=-3.066667:37.359167:5895 -f /dev/ttyUSB0 -o gpx -F out.gpx ++ ++ Sets the Car/Home symbols' latitude longitude and altitude. ++ If you select the Car/Home symbol on miniHomer, the display will show the direction and distance to ++ this location as soon as it has a satellite fix. ++


baud option

++ Baud rate used for download. ++

The following baud rates can be used: 4800, 9600, 19200, 38400, 57600, 115200, 230400. ++Note that your logger might not support all of them (especially 230400 which isn't documented ++in the chipset manual, though there are known devices that are capable of this speed). ++

If baud=0 (zero) download takes place at the baud rate the ++device is currently set to. This is especially useful for Bluetooth connections (if available) since they ++often don't allow changing the baud rate.

dump-file option

++ Dump raw data to this file. ++

++This function is identical to the dump-file function of skytraq module: ++Writes raw data as it is read from the logger to the file given as this option's argument ++(additional to decoding it as usual). The resulting binary files can be read and decoded by the skytraq-bin format. ++Mainly useful for debugging/development purposes. ++

erase option

++ Erase device data after download. ++

++Erase log buffer. ++

first-sector option

++ First sector to be read from the device. ++

++This function is identical to the first-sector function of skytraq module. ++

The logger's memory is organized in sectors, serially numbered starting at 0. Each sector takes 4096 bytes of data. ++Typical devices hold about 250 sectors. The memory is always filled from sector 0 on, until it is full or the device being ++erased again by the user.

Normally you can safely omit this option. However, it might be useful to read data from erased devices: we observed ++that on erase, only the first two sectors are actually cleared. The following example shows how to read the remaining data: ++

Example 3.23. Command showing how to read data from an erased device

gpsbabel -i miniHomer,first-sector=2 -f /dev/ttyUSB0 -o gpx -F out.gpx


initbaud option

++ Baud rate used to init device (0=autodetect). ++

++This function is identical to the init-baud file function of skytraq module. ++

The "initbaud" option might be helpful if autodetection fails or takes too long. With this option you ++can tell GPSBabel the baud rate the device is currently set to. In contrast, the option "baud" specifies ++the rate at which the actual download should take place. If it is different than "initbaud" (or the autodetected ++rate, if initbaud wasn't given), the initial setting will be restored after finishing the download. ++

++Please note that miniHomer by default uses 38400bps and does not autodetect the port speed. If you need autodetect, start as ++gpsbabel -i miniHomer,initbaud=0 -f /dev/ttyUSB0 -o gpx -F out.gpx ++

last-sector option

++ Last sector to be read from the device (-1: smart read everything). ++

A value of -1 (the default) enables automatic mode, i.e. reading is stopped when an empty sector is ++encountered. ++We observed that sometimes the device doesn't report the correct number of used sectors, which confuses the Windows ++software, so that it might not get all trackpoints. ++In contrast, our algorithm ensures that everything is being read (please report if it doesn't work for you).

no-output option

++ Disable output (useful with erase). ++

If this option is given, no GPS log data will be read from the device ++(unless "dump-file" is given too; in that case only decoding will be disabled).

read-at-once option

++ Number of sectors to read at once (0=use single sector mode). ++

If read-at-once >= 1, batch mode is enabled with that many sectors being read at a time. ++A value of zero disables batch mode and switches to single read mode. Not all devices support batch mode; in that case ++gpsbabel automatically switches to single read mode.

Under normal circumstances, the larger this number the faster the transfer. ++Reducing read-at-once or even switching to single sector mode might help when you get ++transmission errors/aborts.

Home option

++ POI for Home Symbol as lat:lng[:alt]. ++

++ The device provides a location finder display supporting five locations "Home", "Car", "Boat", "Heart", "Bar". ++ You can program the location of each either by a keypress on the device (which uses the actual position) ++ or with GPSBabel (which lets you use any position) ++ You can set the location of "Home" with the 'Home' option. Use ':' as the delimiter between latitude, longitude and altitude. ++ You can leave altitude out, in which case it is assumed to be zero. ++ Note that GPSBabel terminates after writing the location info to the device, i.e. no logging data will be read from it. ++

Example 3.24. Set the target location of the miniHomer Home POI

++ gpsbabel -i miniHomer,Home=-3.066667:37.359167:5895 -f /dev/ttyUSB0 -o unicsv -F - ++

++ Sets the Home symbols' latitude to 3.066667S longitude to 37.359167E and altitude to 5895m. ++ If you select the Home symbol on miniHomer, the display will show the direction and distance to ++ this location as soon as it has a satellite fix. ++


Car option

++ POI for Car Symbol as lat:lng[:alt]. ++

++ The device provides a location finder display supporting five locations "Home", "Car", "Boat", "Heart", "Bar". ++ You can program the location of each either by a keypress on the device (which uses the actual position) ++ or with GPSBabel (which lets you use any position) ++ You can set the location of "Car" with the 'Car' option. Use ':' as the delimiter between latitude, longitude and altitude. ++ You can leave altitude out, in which case it is assumed to be zero. ++ Note that GPSBabel terminates after writing the location info to the device, i.e. no logging data will be read from it. ++

Example 3.25. Set the target location of the miniHomer Car POI

++ gpsbabel -i miniHomer,Car=-25.272309:153.235330 -f /dev/ttyUSB0 -o unicsv -F - ++

++ Sets the Car symbols' latitude to 25.272309S longitude to 153.235330E and altitude to 0m. ++ If you select the Car symbol on miniHomer, the display will show the direction and distance to ++ this location as soon as it has a satellite fix. ++


Boat option

++ POI for Boat Symbol as lat:lng[:alt]. ++

++ The device provides a location finder display supporting five locations "Home", "Car", "Boat", "Heart", "Bar". ++ You can program the location of each either by a keypress on the device (which uses the actual position) ++ or with GPSBabel (which lets you use any position) ++ You can set the location of "Boat" with the 'Boat' option. Use ':' as the delimiter between latitude, longitude and altitude. ++ You can leave altitude out, in which case it is assumed to be zero. ++ Note that GPSBabel terminates after writing the location info to the device, i.e. no logging data will be read from it. ++

Example 3.26. Set the target location of the miniHomer Boat POI

++ gpsbabel -i miniHomer,Boat=32.29287:-64.77527 -f /dev/ttyUSB0 -o unicsv -F - ++

++ Sets the Boat symbols' latitude to 32.29287N longitude to 64.77527E and altitude to 0m. ++ If you select the Home symbol on miniHomer, the display will show the direction and distance to ++ this location as soon as it has a satellite fix. ++


Heart option

++ POI for Heart Symbol as lat:lng[:alt]. ++

++ The device provides a location finder display supporting five locations "Home", "Car", "Boat", "Heart", "Bar". ++ You can program the location of each either by a keypress on the device (which uses the actual position) ++ or with GPSBabel (which lets you use any position) ++ You can set the location of "Heart" with the 'Heart' option. Use ':' as the delimiter between latitude, longitude and altitude. ++ You can leave altitude out, in which case it is assumed to be zero. ++ Note that GPSBabel terminates after writing the location info to the device, i.e. no logging data will be read from it. ++

Example 3.27. Set the target location of the miniHomer Heart POI

++ gpsbabel -i miniHomer,Heart=36.1269:-115.1698 -f /dev/ttyUSB0 -o unicsv -F - ++

++ Sets the Heart symbols' latitude to 36.1269N longitude to 115.1698W and altitude to 0m. ++ If you select the Heart symbol on miniHomer, the display will show the direction and distance to ++ this location as soon as it has a satellite fix. ++


Bar option

++ POI for Bar Symbol as lat:lng[:alt]. ++

++ The device provides a location finder display supporting five locations "Home", "Car", "Boat", "Heart", "Bar". ++ You can program the location of each either by a keypress on the device (which uses the actual position) ++ or with GPSBabel (which lets you use any position) ++ You can set the location of "Bar" with the 'Bar' option. Use ':' as the delimiter between latitude, longitude and altitude. ++ You can leave altitude out, in which case it is assumed to be zero. ++ Note that GPSBabel terminates after writing the location info to the device, i.e. no logging data will be read from it. ++

Example 3.28. Set the target location of the miniHomer Bar POI

++ gpsbabel -i miniHomer,Bar=38.99809:-86.34662 -f /dev/ttyUSB0 -o unicsv -F - ++

++ Sets the Bar symbols' latitude to 38.99809N longitude to 86.34662W and altitude to 0m. ++ If you select the Bar symbol on miniHomer, the display will show the direction and distance to ++ this location as soon as it has a satellite fix. ++


Mobile Garmin XT Track files (garmin_xt)

++ This format can... ++

  • ++ read tracks ++

This format has the following options: ftype, trk_header .

ftype option

++ Garmin Mobile XT ([ATRK]/STRK). ++

trk_header option

++ Track name processing option ([0]-nrm/1-ign). ++

Motoactiv CSV (motoactv)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++The MotoACTV™ smart watch creates csv ++format files. GPSBabel can read and write these files through ++the xcsv format when using the included motoactv.style specification. ++

++The specific format of the csv file has changed over time, to ++add new data fields. The current version of the GPSBabel style ++specification expects to work with this ordered set of fields: ++

++"DISTANCE","activity_id","HEARTRATE","SPEED","STEPS_PER_MINUTE", ++"LATITUDE","repetitions","temperature","INSTANT_TORQUE_CRANK", ++"timestamp_epoch","ELEVATION","POWER","STRIDES","wheel_torque", ++"CALORIEBURN","LONGITUDE","CADENCE","heading","STEP_RATE" ++

++gpsbabel -i motoactv -f rawDataCsv.csv ++-x transform,trk=wpt -o gtrnctr,course=0 -F outfile.tcx ++

Motorrad Routenplaner (Map&amp;Guide) .bcr files (bcr)

++ This format can... ++

  • ++ read and write routes ++

This format has the following options: index, name, radius, prefer_shortnames .

++This file format (extension .bcr) is used in Map&Guide ++Motorrad Routenplaner 2002™ and later versions. ++BCR is a route-only format. If you own a newer release (2005 or later) you ++may also use the XML export with GPSBabel's tef ++input format. ++

++There may be other products from Map&Guide that use this format as well. ++

++Coordinates are stored in a BCR file in a Mercator projection. The ++conversion from the Mercator projection to polar (latitude/longitude) ++coordinates and back again may result in visible differences. Experience ++reports are welcome. ++

Example 3.29. Sample BCR command with all options

gpsbabel -r -i gpx -f in.gpx -o bcr,index=1,name="From A to B",radius=6371012 -F a_to_b.bcr


index option

++ Index of route to write (if more than one in source). ++

++Because the format supports only one route, this option may be used ++on output to select a single route from a collection of ++routes read from a more expressive format. If you have, say, a ++gpx file that contains two routes, you may ++use this option to write them one at a time to individual files. ++

gpsbabel -i gpx -f routes.gpx -o bcr,index=1 -F route1.bcr -o bcr,index=2 -F route2.bcr

name option

++ New name for the route. ++

++This route specifies the name of the route. This is particularly useful if ++the route came from an input format that did not support named routes, but ++it may also be used to rename a route. ++

radius option

++ Radius of our big earth (default 6371000 meters). ++

++This option instructs GPSBabel to use a different value for the radius of ++the earth when converting between the Mercator projection and geographic ++coordinates. The default value is 6371000.0 meters. ++

++Careful experimentation with this value may help to reduce conversion ++errors. ++

prefer_shortnames option

++ Use shortname instead of description. ++

++This option causes GPSBabel to use the short name of the waypoint instead ++of the description. ++

MTK Logger (iBlue 747,...) Binary File Format (mtk-bin)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: csv .

Binary file protocol converter for MTK based GPS loggers. ++This format reads the raw binary format created by the MTK Windows application ++and outputs to other formats supported by GPSBabel ++When using the csv option a MTK application compatible output file will also be created.

++It has been tested with Transystem i-Blue 747™ but other devices should ++work as well (Qstarz BT-Q1000, iTrek Z1, ...) ++

++All position items (including button push) will be listed as trackpoints in the output. ++Log items due to button push are presented as waypoints. ++In theory we would not add waypoints to the list of trackpoints. But as the MTK logger restart the ++log session from the button press we would loose a trackpoint unless we include/duplicate it. ++ ++

++Transystem i-Blue 747 ++

Example 3.30. Convert MTK binary trackpoints to GPX

++ gpsbabel -t -i mtk-bin,csv=extra.csv -f data.bin -o gpx -F out.gpx ++ Additionally a CSV output file is created. ++


csv option

++ MTK compatible CSV output file. ++

++ Specifies a filename into which MTK-compatible CSV output will be written. ++

++ Note that this option is a bit of an oddity in the GPSBabel arsenal. This ++ should probably be a "real" output type of its own instead of being bolted ++ onto an input type. ++

MTK Logger (iBlue 747,Qstarz BT-1000,...) download (mtk)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: erase, erase_only, log_enable, csv, block_size_kb .

++ This format is the serial download protocol for the MTK chips. ++ Mediatek's MT3301/3179 (MTKv1) and MT3318 (MTKv2) chips are used ++ in a large number of products sold under different names. ++

++ Many GPS products, especially of the data logger variety, expose ++ the Mediatek protocol to the user via USB. Some modify Mediatek's ++ protocol in minor ways, but the core protocol is very commonly ++ seen in loggers. ++

++ The Holux M-241 and GPSport 245 ++ are examples of a device using an incompatible variation of the MTK ++ protocol. ++

++The following products are known or are expected to work with this module. ++As the products are typically very low cost, they tend to have a short ++product life cycle and are often imported to different areas under ++different names. Keeping ++track of the list is difficult. Often the "same" GPS is sold in different ++plastic or with different Windows software or different options such as ++compass or motion sensors or charging cables with different model numbers. ++If you can confirm success with others, please share with us. ++

Table 3.6. Devices supported by MTK module
ProductConfirmed to workNotes
iBlue 821YesAvailable from Semsons
iBlue 747, 747A+YesAvailable from Semsons
QStarz BT-1000, BT-Q1000X, BT-1000eXYes 
iTrek Z1  

++ The Mediatek chip offers a native serial port. Data logger designers ++ frequently pair this with commodity USB/Serial converter internally. So ++ these devices typically look like Prolific, FTDI, or Silab usb/serial ++ devices to the host OS. You'll need drivers for that whatever chip ++ your product uses for your operating system. For the "A+ GPS Recorder", ++ the Silicon Labs CP210x chip is used. On OS/X, you'll get ++ awesome device names like /dev/cu.usbmodem1d13410 - fortunately, our GUI ++ makes that multiple choice so you don't have to guess. ++

++ Downloaded data will be stored in data.bin file in the current ++ directory together with the choosen output format. This is a rather ++ uncommon feature in GPSBabel's formats and is likely to change in future ++ versions. ++

See mtk-bin on how trackpoints/waypoints are handled

Example 3.31. Command showing MTK download track and waypoints and erase on Linux

gpsbabel -t -w -i mtk,erase -f /dev/ttyUSB0 -o gpx -F out.gpx


++ For more info and tweaks on MTK based loggers: ++ MTK Tips and Tweaks and ++ iBlue 747 Logger ++ For info about the used log format, see ++ MTK binary format ++

++Most of the loggers cannot receive bluetooth commands; they can only send ++ data. Since GPSBabel needs to send commands to the GPS device it won't ++ work. Download the data using the USB cable instead. ++

erase option

++ Erase device data after download. ++

This option erases the track log from the device after download.

erase_only option

++ Only erase device data, do not download anything. ++

This option will only erase the logger data. No data is downloaded.

This option is typically used as a second step after the data has been downloaded and verified.

log_enable option

++ Enable logging after download. ++

This option will enable the logger after download.

By default the logger is re-enabled when download is finished if previously were enabled. ++But if the download is aborted or failed the log functionality won't be enabled again.

csv option

++ MTK compatible CSV output file. ++

This option will create an additional CSV output file. ++The CSV file is compatible with the original MTK logger application.

block_size_kb option

++ Size of blocks in KB to request from device. ++

MyNav TRC format (mynav)

++ This format can... ++

  • ++ read tracks ++

++ Input support for the TRC file format used by MyNav Map ++ Manager™ and VDO GP7™ GPS ++ devices. ++

++ For information on the data format see track format ++ specification. ++

++ ++ gpsbabel -i mynav -f infile.trc -o gpx,garminextensions -F outfile.gpx ++ ++

National Geographic Topo .tpg (waypoints) (tpg)

++ This format can... ++

  • ++ read and write waypoints ++

This format has the following options: datum .

National Geographic Topo! Waypoint and Route Format. This module ++reads and writes .TPG files created by various editions of NG Topo! ++Reading/writing of route data is not supported yet.

Contributed by Alex Mottram.

datum option

++ Datum (default=NAD27). ++

The option 'datum="datum name"' can be used to override ++the default of NAD27 ("N. America 1927 mean") which is correct for the ++continental U.S.

Any legal datum supported ++by GPSBabel may be used. For example, points in Hawaii should ++use "Old Hawaiian_mean".

National Geographic Topo 2.x .tpo (tpo2)

++ This format can... ++

  • ++ read tracks ++

++ This module reads tracks from .TPO files created by ++ National Geographic Topo! version 2.x ++

++ Contributed by Steve Chamberlin. ++

National Geographic Topo 3.x/4.x .tpo (tpo3)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

  • ++ read routes ++

This module reads .TPO files created by National Geographic Topo! version ++3.x and 4.x. It will read tracks, routes, waypoints, map notes, symbols, and ++text notes. The latter three are converted to waypoints.

Contributed by Curt Mills.

Navicache.com XML (navicache)

++ This format can... ++

  • ++ read waypoints ++

This format has the following options: noretired .

++ This is the XML format that's used by Navicache.com for ++ their geocaching data. There are a number of fields in it that are ++ marked "required" but are Navicache-specific, so GPSBabel can not ++ write these files, but we can still read them. ++ navicache.com ++

noretired option

++ Suppress retired geocaches. ++

++ If this option is present, retired (archived) caches will be suppressed on write. ++

Navigon Mobile Navigator .rte files (nmn4)

++ This format can... ++

  • ++ read and write routes ++

This format has the following options: index .

Support for Navigon Mobile Navigator route (.rte) files. ++This is a very simple text format that only requires coordinates, but ++has fields for many other things. We only write coordinates as fields ++like 'city' and 'street' cannot typically be populated from other ++formats. www.navigon.com ++

index option

++ Index of route to write (if more than one in source). ++

++Because the format supports only one route, this option may be used ++on output to select a single route from a collection of ++routes read from a more expressive format. If you have, say, a ++gpx file that contains two routes, you may ++use this option to write them one at a time to individual files. ++

gpsbabel -i gpx -f routes.gpx -o nmn4,index=1 -F route1.rte -o nmn4,index=2 -F route2.rte

Navigon Waypoints (navigonwpt)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ This is the waypoint file format for Navigon units such as the Navigon 7100. ++

++ To actually manipulate the file on the unit, use a USB cable or SD card ++ reader and work with MN6\Settings\Favorites.storage ++ The waypoints are be created with a minimal amount of data; the unit will ++ fill in the other fields on use. The other fields appear to be data the ++ unit infers, such as nearby streets. ++

++ Note that this is the waypoint/placemark format (.storage) and not the ++ route file format (.rte, .mn4) that is used by routes. ++

NaviGPS GT-11/BGT-11 Download (navilink)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: nuketrk, nukerte, nukewpt, nukedlg, datalog, power_off .

++ GPSBabel supports the Navilink protocol used by the ++ Locosys GT-11 ++ and ++ GT-31 ++ GPS receivers. These are sold under a variety of names including: ++

NaviGPSBGT-11Amaryllo
NaviGPS-BTGT-31 
GT-11BGT-31 

++

++ This format is used for both the serial protocol used on ++ the USB link and for the files which can be copied from the ++ internal memory to the SD card using recent firmware versions. ++

++ If you specify a serial port for the file (.e.g. "COM1", "/dev/ttyUSB0") ++ to be read or written, GPSBabel will use the serial protocol. Specifying ++ a file, either on local filesystem or on a mounted flash card reader, ++ will results in the file-based format being used. ++

++ To access the device using the serial protocol over USB the ++ device needs to be in Navilink mode, which can be activated ++ from the main menu of the device. This device uses a Prolific ++ PL2303 USB/Serial adapter internally and that's how it will ++ present itself to the host operating system. You thus need ++ USB drivers for the PL2303, such as those from the 'Download' ++ section of ++ ++ Locosys USB Genie GT-31/BGT-31 drivers ++ . ++

++ Details of the Navilink serial protocol can be found ++ here. ++

nuketrk option

++ Delete all track points. ++

++This option erases all track data in the receiver before or after ++doing the transfer, depending on whether track data is sent to or ++received from the device. ++

++This is a convenient option to use in automated processes where you want ++to ensure the units starts with a clean state before sending track data to ++it, or if you want to clear the device after receiving the track data. ++

nukerte option

++ Delete all routes. ++

++This option erases all routes in the receiver before or after doing ++the transfer, depending on whether routes are sent to or received from ++the device. ++

++This is a convenient option to use in automated processes where you ++want to ensure the units starts with a clean state before sending ++routes to it, or if you want to clear the device after receiving the ++routes. ++

nukewpt option

++ Delete all waypoints. ++

++This option erases all waypoints in the receiver before or after doing ++the transfer, depending on whether waypoints are sent to or received ++from the device. ++

++This is a convenient option to use in automated processes where you ++want to ensure the units starts with a clean state before sending ++waypoints to it, or if you want to clear the device after receiving ++the waypoints. ++

nukedlg option

++ Clear the datalog. ++

++This option clears the datalogger in the receiver after doing the ++transfer. ++

++This is a convenient option to use in automated processes if you want ++to clear the device after receiving the data logger contents. ++

datalog option

++ Read from datalogger buffer. ++

++This option transfers the contents of the unit's data log. The data is ++downloaded as a single track. ++

++Only reading of the data log is supported, and you must use ++the -t option to receive any data. ++

power_off option

++ Command unit to power itself down. ++

++This options powers down the Navilink receiver once any transfers are ++complete. ++

NaviGPS GT-31/BGT-31 datalogger (.sbp) (sbp)

++ This format can... ++

  • ++ read tracks ++

++ This format is for SBP datalog files saved to the SD card by ++ the Locosys GT-11/BGT-11/GT-31/BGT-31 GPS receivers. ++

NaviGPS GT-31/BGT-31 SiRF binary logfile (.sbn) (sbn)

++ This format can... ++

  • ++ read tracks ++

++ This format is for SBN datalog files saved to the SD card by ++ the Locosys GT-11/BGT-11/GT-31/BGT-31 GPS receivers. ++

++ On the device, logging in this format is enabled by choosing ++ SBN from the NMEA ITEMS menu on the MEMORY CARD screen. ++

++ Not all data logged in this format is converted by GPSBabel, ++ but the following are: ++ ++

PositionFix type (2D/3D/DGPS)Number of satellites visible
ElevationSpeedHorizontal Dilution of Precision (HDOP)
TimeCourse 

++

++ The specification of this format can be found in ++ the ++ SiRF Binary Protocol Reference Manual, in the section ++ called Geodetic Navigation Data - Message ID 41. ++

Naviguide binary route file (.twl) (naviguide)

++ This format can... ++

  • ++ read and write waypoints ++

This format has the following options: output, reorder .

Naviguide 3.02 is off-road navigation software. Naviguide covers the area of Israel and uses the Israeli old grid as a reference; Naviguide uses Hebrew as its default language.

Naviguide uses unique map file format and binary file format (.twl) as route file. ++The *.twl file contains a route that is comprised of a list of waypoints. Naviguide does not support a file that contains only waypoints.

GPSBabel supports reading and creating Naviguide route files. Plot files are not supported.

output option

++ 'wp' - Create waypoint file , 'rte' - Create route file. ++

reorder option

++ 'n' - Keep the existing wp name, 'y' - rename waypoints. ++

Navitel binary track (.bin) (navitel_trk)

++ This format can... ++

  • ++ read and write tracks ++

++ NavitelNavigator is very popular navigation ++ software in Russia and it's neighbors. ++

++ This binary format only stores the latitude and the longitude of a trackpoint and is ++ limited to 10000 points per file. ++

Navitrak DNA marker format (dna)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ Navitrak DNA marker format - Another CSV format file. This ++ is the format that is compatible with the DNA Desktop import/export ++ command. Reading the binary Markers.jwp format directly off the data ++ card is not supported yet. Contributed by Tim Zickus. ++

NetStumbler Summary File (text) (netstumbler)

++ This format can... ++

  • ++ read waypoints ++

This format has the following options: nseicon, nsneicon, seicon, sneicon, snmac .

++This format reads summary files from NetStumbler™ ++0.4 or MacStumbler™. ++

++The default behavior when creating waypoints is to use the SSID for ++the short name, and information about the access point for the ++description. When the SSID is not unique, is not available, or ++consists of whitespace, a short name is synthesized. ++

++Different icons are assigned to encrypted, ++non-encrypted, stealth, and non-stealth access points; these may be ++changed with options. ++

++NetStumbler ++

++MacStumbler ++

nseicon option

++ Non-stealth encrypted icon name. ++

++This option specifies the name of the icon to use for ++non-stealth, encrypted access points. ++

nsneicon option

++ Non-stealth non-encrypted icon name. ++

++This option specifies the name of the icon to use for ++non-stealth, non-encrypted access points. ++

seicon option

++ Stealth encrypted icon name. ++

++This option specifies the name of the icon to use for ++stealth, encrypted access points. ++

sneicon option

++ Stealth non-encrypted icon name. ++

++This option specifies the name of the icon to use for ++stealth, non-encrypted access points. ++

snmac option

++ Shortname is MAC address. ++

++This option causes GPSBabel to use the MAC address as the short name for the ++waypoint. The unmodified SSID is included in the waypoint description. ++

NIMA/GNIS Geographic Names File (nima)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

This is a CSV format from the National Imagery and Mapping ++Agency.

NMEA 0183 sentences (nmea)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

This format has the following options: snlen, gprmc, gpgga, gpvtg, gpgsa, date, get_posn, pause, append_positioning, baud, gisteq, ignore_fix .

This format is the file representation of the NMEA ++(National Marine Electronics Association) 0183 ++log and waypoint format for GPS devices. Some hardware and software ++that work with NMEA-0183 formatted data include: ++

++ GPS Data Logger ++ ++ VisualGPS ++ ++ SparkFun GPS Datalogger ++
++ GPS TrackMaker ++ ++ GPS Utility ++ ++ AMOD 3080 GPS ++
++ GPSMaster ++ ++ GeoConv ++ ++ Wintec WPL-1000 GPS ++
++ NMEAlog ++ ++ CommLinx GPS recorder ++ ++ Sony GPS_CS1 ++

++This module also supports realtime tracking ++which allows realtime position reports from a GPS, such as one connected ++serially, over Bluetooth, or a USB module emulating a serial port, to be used ++with selected output formats. Just specify an input file that is the device ++name such as COM1: for Windows or a device-dependent name like ++/dev/cu.usbserial for Mac or /dev/ttyUSB0 for Linux. (Note that serial ++device names vary on Mac and Linux.) ++

++When used in realtime tracking mode, if ++GPSBabel does not sense incoming NMEA sentences arriving from the port, it ++will send Sirf "reset to NMEA" commands to the port at a variety of speeds ++in an attempt to communicate with an attached GPS. This lets devices ++like the Microsoft GPS or Pharos GPS that are Sirf chips with an integrated ++USB/Serial adapter work with this input format. ++

snlen option

++ Max length of waypoint name to write. ++

++This option specifies the maximum length to be used for waypoint names in ++the GPWPL sentence. Longer names will be shortened to no more than this ++length, but all waypoint names will remain unique. ++

gprmc option

++ Read/write GPRMC sentences. ++

++This option tells GPSBabel whether to read (on input) or write (on output) ++GPRMC sentences. The default is to read or write GPRMC sentences. To ++disable GPRMC sentences, specify gprmc=0. ++

++GPRMC sentences contain the "recommended mimimum" positional information, ++including date and time, heading, and velocity. Note that they do not ++include altitude. For altitude, you will have to include GPGGA sentences. ++

gpgga option

++ Read/write GPGGA sentences. ++

++This option tells GPSBabel whether to read (on input) or write (on output) ++GPGGA sentences. The default is to read or write GPGGA sentences. To ++disable GPGGA sentences, specify gpgga=0. ++

++GPGGA sentences contain the location and quality of the GPS position fix. ++

gpvtg option

++ Read/write GPVTG sentences. ++

++This option tells GPSBabel whether to read (on input) or write (on output) ++GPVTG sentences. The default is to read or write GPVTG sentences. To ++disable GPVTG sentences, specify gpvtg=0. ++

++GPVTG sentences contain information about the heading and the speed at the ++time of the fix. They do not contain any location information; for that ++you will need either or both of GPGGA or GPRMC. ++

gpgsa option

++ Read/write GPGSA sentences. ++

++This option tells GPSBabel whether to read (on input) or write (on output) ++GPGSA sentences. The default is to read or write GPGSA sentences. To ++disable GPGSA sentences, specify gpgsa=0. ++

++GPGSA sentences contain information on the quality of the positional fix ++and the individual satellites from which it was derived. However, GPSBabel ++neither reads nor writes the individual satellite data. On input, the ++satellite fields are ignored and on output they are left blank. ++

date option

++ Complete date-free tracks with given date (YYYYMMDD).. ++

++On input, track points with times but no dates will have this date applied. ++

++This is necessary because some NMEA sentences contain times but no dates. If ++this option is not specified and the date cannot be determined from one or ++more of the available NMEA sentences, the tracks will be discarded. ++

get_posn option

++ Return current position as a waypoint. ++

This options, when specified, returns the current position as a single ++waypoint. ++

pause option

++ Decimal seconds to pause between groups of strings. ++

++This option tells GPSBabel to pause between individual track records when ++used on output. This may be used with appropriate external software or ++hardware to simulate a GPS receiver for testing purposes. On Unix, for ++example, you may use a named pipe to feed the output from GPSBabel to gpsd. ++

++If a value for this option is specified, it is in seconds and it may be ++either a whole number of seconds or a fraction (e.g. 0.5 for a 1/2 second ++pause between trackpoints.) ++

++If this option is specified without a value, the time between adjacent ++trackpoints will be computed and used for the length of the pause. That is, ++if your trackpoints are 5 seconds apart, GPSBabel will pause 5 seconds ++between trackpoints. ++

++Note that very long tracks may be subject to clock drift, as GPSBabel does ++not take into account the amount of time it may take to write the NMEA ++sentences. Also, there is no guarantee that it will pause for exactly the ++specified number of seconds between samples; different operating systems ++will allow greater or lesser precision for timers, so actual precision may ++be as much as plus or minus 100 milliseconds. ++

++If you are using this option with compressed or simplified tracks from ++your handheld GPS receiver, you might find the ++interpolate filter useful. ++

append_positioning option

++ Append realtime positioning data to the output file instead of truncating. ++

++ When writing NMEA realtime positioning data, append to the ++ output file instead of truncating it on each successive position ++ fix. ++

baud option

++ Speed in bits per second of serial port (baud=4800). ++

++To the "nmea" module, the "baud" option specifies the baud rate of the ++serial connection when used with the real-time tracking option. ++

gisteq option

++ Write tracks for Gisteq Phototracker. ++

++ This option writes the Gisteq format - which has the extension of .GPS - ++ to allow third-party GPS hardware with the Gisteq PhotoTrackr software. ++

++ The Gisteq PhotoTrackr is a GPS data logger hardware and software package ++ that allows one to easily record the locations of where the user has taken ++ photos. The PhotoTrackr software works by comparing EXIF timestamps in ++ digital photos with the timestamps in the tracking data. In doing so, the ++ software plots the locations of the photos using Google Maps. The logging ++ format used by the Gisteq hardware is very close to NMEA format, but with a ++ few small quirks. ++

++More information can be found at the ++Gisteq site. ++

ignore_fix option

++ Accept position fixes in gpgga marked invalid. ++

Nokia Landmark Exchange (lmx)

++ This format can... ++

  • ++ read and write waypoints ++

This format has the following options: binary .

++This format supports ++ ++Nokia Landmark Exchange (LMX) files used by several Nokia phones. ++GPSBabel supports the traditional XML format for reading and writing. The ++compressed binary format (WBXML) can be written, but most current Nokia phones ++do not support it (confirmed with N82 and N95). ++

++With this format, landmarks can be imported into the landmark store of the ++mobile phone. This landmark store is then used to display them on a map with ++several applications. The most common ones are the pre-installed Ovi Maps (or ++its predecessor Nokia Maps) and Google Maps Mobile. ++

binary option

++ Compact binary representation. ++

++This option specifies if you want to write the compressed binary format (WBXML) ++instead of the XML format. However, most current Nokia phones do only support ++the XML format (confirmed with N82 and N95). ++

++This option has no effect when used for input, only reading the traditional XML ++format is supported. ++

OpenStreetMap data files (osm)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ write tracks ++

  • ++ read and write routes ++

This format has the following options: tag, tagnd, created_by .

++ This format is used to exchange data with the OpenStreetMap project. ++ The main goal of this collaborative project is to create free editable maps. ++

++ These data files are XML based. Every GPS element (way or node) described by the files has a unique ++ number as identifier. When we write OSM data files and don't know something about the id's, ++ negative numbers will be used as identifier. This has been tested with JOSM. ++

++ Because the resulting timestamps of OSM ways differ from real GPS tracks, ++ we read OSM ways into routes. On the output side we write all available routes and tracks into the osm target file. ++

tag option

++ Write additional way tag key/value pairs. ++

++ With this option you can preset OSM features (tags) on all exported ways. ++

++ gpsbabel -i gdb -f ways.gdb -o osm,tag="highway:motorway" -F ways.osm ++

tagnd option

++ Write additional node tag key/value pairs. ++

++ With this option you can preset OSM features (tags) on every written nodes. ++

++ gpsbabel -i gdb -f nodes.gdb -o osm,tagnd="amenity:pub;building:yes" -F nodes.osm ++

created_by option

++ Use this value as custom created_by value. ++

Use this value as custom created_by value in an OSM file.

++With this option, the given string is added as the 'created_by' field in ++all the created nodes and ways. ++

++ ++gpsbabel -i INTYPE -f INFILE -o osm,created_by=somestring -F out.osm ++ ++

++ If an empty string is given, the 'created_by' tag is omitted altogether. ++

++ ++gpsbabel -i INTYPE -f INFILE -o osm,created_by= -F out.osm ++ ++

OziExplorer (ozi)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: pack, snlen, snwhite, snupper, snunique, wptfgcolor, wptbgcolor, proximity, altunit, proxunit .

++ OziExplorer Waypoint Format - Another CSV format file. ++ Tested against OziExplorer v 3.90.3a / Shareware. Contributed by Alex Mottram ++

pack option

++ Write all tracks into one file. ++

++ In normal case GPSBabel creates for each track a separate file (track.plt, track-1.plt, ...). ++ With this option all tracks will be written into one file. A '1' in the third field of the ++ trackpoint record signals the beginning of a new track. ++

++ ++ gpsbabel -i gpx -f tracks.gpx -o ozi,pack -F track ++ ++

snlen option

++ Max synthesized shortname length. ++

++ This option allows you to specify the length of waypoint names written to this format when used with the -s option. ++

snwhite option

++ Allow whitespace synth. shortnames. ++

++ This option forces waypoint names generated with -s to allow whitespace in the names. ++

snupper option

++ UPPERCASE synth. shortnames. ++

++ When specified, this option will force generated shortnames to be in all uppercase letters. ++

snunique option

++ Make synth. shortnames unique. ++

++ When specified, this option will force the generated waypoint names to be unique. ++

wptfgcolor option

++ Waypoint foreground color. ++

++ This option allows you to specify a foreground color of a waypoint. You can specify it as either a decimal number or one of the standard web colors. ++

wptbgcolor option

++ Waypoint background color. ++

++ This option allows you to specify a background color of a waypoint. You can specify it as either a decimal number or one of the standard web colors. ++

proximity option

++ Proximity distance. ++

++ This option, specified in meters, allows you to set the proximity of ++written waypoints. ++

altunit option

++ Unit used in altitude values. ++

++ By default the ozi module uses feet as altitude unit. With this option you can specify also 'Meters' (m) ++ as unit for altitude values. ++

proxunit option

++ Unit used in proximity values. ++

++ By default the proximity values are handled in meters. With this option you can now specify (m)iles, ++ (k)ilometers or (n)autical miles as the units for proximity when reading or writing ozi files. ++

PocketFMS breadcrumbs (pocketfms_bc)

++ This format can... ++

  • ++ read and write tracks ++

++ This format provides support for binary breadcrumb files from PocketFMS. The default filename is GPS followed by the timestamp with no file extension. ++

++ PocketFMS breadcrumbs files contain track information. That is latitude, longitude, altitude, speed, course, variation, separation, GPS error, fix type and timestamp. With exception of separation all info get processed by GPSBabel in both in and out direction. ++

PocketFMS flightplan (.xml) (pocketfms_fp)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read routes ++

++ This format provides support for XML flightplans from PocketFMS. ++

++ PocketFMS XML flightplans contain route and waypoint information and much more flight planning info as airspaces, aircraft performance, fuel management etc. This format cannot be read by PocketFMS. Hence GPSBabel supports only input of route and waypoint information. ++

++ The PocketFMS flightplan converter take into account the -w waypoint flag. If set then additional waypoints are stored to the route point and path information. ++

PocketFMS waypoints (.txt) (pocketfms_wp)

++ This format can... ++

  • ++ read and write waypoints ++

++ This format provides support for the PocketFMS user waypoints text file. ++

++ PocketFMS waypoint text files contain one waypoint per line. Any waypoint has name, latitude and longitude, separated by space. Latitude and longitude are either decimal degrees or degrees°minutes'seconds'' triples. For details see the PocketFMS help file. You can find more information at the PocketFMS forum. ++

Raymarine Waypoint File (.rwf) (raymarine)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write routes ++

This format has the following options: location .

++ This format supports the "Raymarine Waypoint File" format (.rwf). ++ More information to Raymarine you'll find at their homepage. ++

++ Known limits: max. 16 characters for waypoint names and max. 50 waypoints per route. ++

location option

++ Default location. ++

++ With this option you can specify the name of the folder ++ where the waypoints are placed. ++

++ This name is also limited to 16 characters. ++

Ricoh GPS Log File (ricoh)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

This is the format for the Ricoh 500SE GPS logging camera. ++

++ This camera creates log files on the SD card in a folder name "GPSLOG" that ++ are named "YYMMDDNN.LOG" wher NN increments from 00 through 99. The camera ++ appends new tracks into the current file, hence the "new track" field. When ++ the current file reaches about 500K, NN increments and logging continues into ++ the next file. Therefore, there may be multiple tracks in each log ++ file, and tracks may span one or more files. ++

++ GPSBabel will recognize the "new track" field and will generate a new track, ++ so if you specify multiple files in the correct order, your tracks will be ++ automatically split sensibly. ++

++For additional tips, see the ++ OpenStreetMap page on Ricoh 500SE. ++

See You flight analysis data (cup)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ This format supports flight analysis data from the ++ See You ++ program. ++

++ Position information is preserved, but the aviation-specific ++ information such as runway length and airport frequency, are ++ written as blanks and ignored on read. ++

++ Tasks are not supported. ++

Skymap / KMD150 ascii files (skyforce)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

++ This format provides support for ascii files from Skyforce PC interface for  ++ Skymap IIIC, Skymap II (Version 4) and KMD 150. Our module was developed ++ from their interface description. ++

++ Each kind of our basic GPS data (waypoints, routes, and tracks) is ++ stored in a separate file. Therefore you need three steps to ++ convert a complex format like GPX or GDB into skyforce. ++ ++ gpsbabel -i gpx -f file.gpx -o skyforce -w -F waypoints.txt -r -F routes.txt -t -F tracks.txt ++ ++

SkyTraq Venus based loggers (download) (skytraq)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: erase, targetlocation, configlog, baud, initbaud, read-at-once, first-sector, last-sector, dump-file, no-output .

Serial download protocol for GPS data loggers based on Skytraq Venus 5 and Venus 6 chipsets. ++This chipset is used by a number of devices from different manufacturers. ++If your logger came with the Windows software iTravelTech GPS Photo Tagger, chances are that you can ++use this format to read its memory.

Following a list of devices which should be supported by this module ++(Note that not all of them have actually been tested, so if you can confirm that additional models work, please mail the gpsbabel-misc group with your success, tips, and any pertinent links for your model.):

Table 3.7. Devices supported by skytraq module
ManufacturerModelUSB (baud)Bluetooth (baud)
SJA"3-in-1" GPS loggerup to 2304009600
NavilockBT-455PDLuntesteduntested
PolarisTravel Honeyup to 2304009600
Pearl DiffusionKeymate STV-5untesteduntested
CanmoreGT-730FL-Suntestedn/a
CanmoreGT-750Funtesteduntested
GisteqDPL900up to 230400untested
Adapt MobileKeychain Prountesteduntested
Adapt Mobile Keychain Pro96009600

Windows users of GPSBabel version 1.5.2 or less may have to explicitly specifiy a bit rate of 115200 or lower.

Example 3.32. Command showing skytraq download of tracks and erasing the logger on Linux

gpsbabel -i skytraq,erase -f /dev/ttyUSB0 -o gpx -F out.gpx


Example 3.33. Command showing skytraq erasing the logger without download on Linux

gpsbabel -i skytraq,erase,no-output -f /dev/ttyUSB0


If available, reading the logger using bluetooth should also work. However, many devices support only one ++specific baud rate over bluetooth, e.g. 9600. In that case you should use the option baud=0 ++to tell GPSBabel to use that default baud rate:

Example 3.34. Command showing skytraq download tracks via bluetooth on Linux

rfcomm bind 0 <bdaddr>

gpsbabel -i skytraq,baud=0 -f /dev/rfcomm0 -o gpx -F out.gpx


erase option

++ Erase device data after download. ++

targetlocation option

++ Set location finder target location as lat,lng. ++

++ The device provides a location finder built from eight LEDs and can use ++ those LEDs to guide you to a location. You can set the target location ++ with the 'targetlocation' option. Use ':' as the delimiter between latitude ++ and longitude. Note that GPSBabel terminates after writing the location info ++ to the device, i.e. no logging data will be read from it. ++

Example 3.35. Set the target location of the Skytraq location finder

++ gpsbabel -i skytraq,targetlocation=12.34:-56.78 -f /dev/ttyUSB ++0 -o unicsv -F - ++

++ Sets latitude and longitude of the location finder to N12.34 and ++ W56.78 respectively. ++ The arrows on the device will point you to this location as soon as ++ it has a satellite fix. ++


configlog option

++ Configure logging parameter as tmin:tmax:dmin:dmax. ++

++ Set the logging configuration as tmin:tmax:dmin:dmax. ++ Here tmin and tmax are in seconds, and dmin and dmax in meters. ++ With dt = time since last log, dx = distance since last log, ++ and v the current speed, the device logs if ++

++ (dt > tmin and dx >= dmin and v >= vmin) or dt > tmax or dx > dmax or v > vmax ++

++ If you use this option, vmin is fixed at 0 and vmax at 65535 km/h. ++

++ Example. Set the device to log every 6 seconds (or 10km, whichever ++ happens first!) ++

Example 3.36. Set the logging parameters for Skytraq device

++ ++ gpsbabel -i skytraq,configlog=6:3600:0:10000 -f /dev/ttyUSB0 ++ ++


baud option

++ Baud rate used for download. ++

The following baud rates can be used: 4800, 9600, 19200, 38400, 57600, 115200, 230400. ++Note that your logger might not support all of them (especially 230400 which isn't documented ++in the chipset manual, though there are known devices that are capable of this speed).

If baud=0 (zero) download takes place at the baud rate the ++device is currently set to. This is especially useful for Bluetooth connections since they ++often don't allow changing the baud rate.

initbaud option

++ Baud rate used to init device (0=autodetect). ++

The "initbaud" option might be helpful if autodetection fails or takes too long. With this option you ++can tell GPSBabel the baud rate the device is currently set to. In contrast, the option "baud" specifies ++the rate at which the actual download should take place. If it is different than "initbaud" (or the autodetected ++rate, if initbaud wasn't given), the initial setting will be restored after finishing the download.

read-at-once option

++ Number of sectors to read at once (0=use single sector mode). ++

If read-at-once >= 1, batch mode is enabled with that many sectors being read at a time. ++A value of zero disables batch mode and switches to single read mode. Not all devices support batch mode; in that case ++gpsbabel automatically switches to single read mode.

Under normal circumstances, the larger this number the faster the transfer. ++Reducing read-at-once or even switching to single sector mode might help when you get ++transmission errors/aborts.

first-sector option

++ First sector to be read from the device. ++

The logger's memory is organized in sectors, serially numbered starting at 0. Each sector takes 4096 bytes of data. ++Typical devices hold about 250 sectors. The memory is always filled from sector 0 on, until it is full or the device being ++erased again by the user.

Normally you can safely omit this option. However, it might be useful to read data from erased devices: we observed ++that on erase, only the first two sectors are actually cleared. The following example shows how to read the remaining data: ++

Example 3.37. Command showing how to read data from an erased device

gpsbabel -i skytraq,first-sector=2 -f /dev/ttyUSB0 -o gpx -F out.gpx


last-sector option

++ Last sector to be read from the device (-1: smart read everything). ++

A value of -1 (the default) enables automatic mode, i.e. reading is stopped when an empty sector is ++encountered. ++We observed that sometimes the device doesn't report the correct number of used sectors, which confuses the Windows ++software, so that it might not get all trackpoints. ++In contrast, our algorithm ensures that everything is being read (please report if it doesn't work for you).

dump-file option

++ Dump raw data to this file. ++

Writes raw data as it is read from the logger to the file given as this option's argument ++(additional to decoding it as usual). The resulting binary files can be read and decoded by the skytraq-bin format. ++Mainly useful for debugging/development purposes.

no-output option

++ Disable output (useful with erase). ++

If this option is given, no GPS log data will be read from the device ++(unless "dump-file" is given too; in that case only decoding will be disabled).

SkyTraq Venus based loggers Binary File Format (skytraq-bin)

++ This format can... ++

  • ++ read waypoints ++

  • ++ read tracks ++

This format has the following options: first-sector, last-sector .

Reads the binary format of GPS data loggers based on Skytraq Venus 5 and Venus 6 chipsets. ++This can be used to read raw binary files created with the "dump-file" option of the skytraq format. ++Mainly useful for debugging/development purposes.

first-sector option

++ First sector to be read from the file. ++

last-sector option

++ Last sector to be read from the file (-1: read till empty sector). ++

SubRip subtitles for video mapping (.srt) (subrip)

++ This format can... ++

  • ++ write tracks ++

This format has the following options: video_time, gps_time, gps_date, format .

++ This is a write-only format for geotagging videos. It is used for ++ videomapping, i.e. filming a trip while creating a GPS trace. ++ It will produce a subtitle file in SubRip (.srt) format. ++

++ Unless the video and the GPS trace start at exactly the same time, you ++ will need to synchronize both. For this purpose, film the display of ++ your GPS receiver (or any other device) showing GPS time. (Important: ++ you need precise GPS time for this; local time, especially from an ++ inaccurate clock, will not do for this.) ++

++ Determine the position in the video at which the GPS time is visible ++ (in hours, minutes and seconds from the beginning of the video) and ++ the GPS date and time shown. Specify these as command line options; you ++ will need to do this once for each video file. ++

++ To use these files, choose the same name as for the associated video, ++ changing just the extension to .srt, and place the srt file in the same ++ directory as the video. Open the video in a media player and the GPS ++ coordinates will be shown as subtitles (tested on VLC, your mileage may ++ vary). ++

video_time option

++ Video position for which exact GPS time is known (hhmmss, default is 0:00:00). ++

++ Video position (relative to beginning of video) for which the corresponding ++ GPS timestamp is known. ++

++ Format is hhmmss. If omitted, 0:00:00 (beginning of video) is assumed. ++

++ The GPS timestamp can be set with the gps_time and ++ gps_date options. ++

gps_time option

++ GPS time at position video_time (hhmmss, default is first timestamp of track). ++

++ The time part of the GPS timestamp which corresponds to a known position ++ in the video. ++

++ Format is hhmmss. This option must be used together with ++ gps_date; if one or both are missing, the timestamp of the ++ first GPS trackpoint is used. ++

++ The video position to which the timestamp corresponds can be set with the ++ video_time option. ++

gps_date option

++ GPS date at position video_time (hhmmss, default is first timestamp of track). ++

++ The date part of the GPS timestamp which corresponds to a known position ++ in the video. ++

++ Format is yyyymmdd. This option must be used together with ++ gps_time; if one or both are missing, the timestamp of the ++ first GPS trackpoint is used. ++

++ The video position to which the timestamp corresponds can be set with the ++ video_time option. ++

format option

++ Format for subtitles. ++

++ Format for output subtitles. ++

Table 3.8. Supported format characters for subrip
format chardescription
%sspeed in km/h
%eelevation in meters
%vvertical speed in m/s
%ttimestamp
%lcoordinates
%cpedal cadence
%hheart rate
%groad gradient
\nnewline

++ Default format (used when option isn't specified) is "%s km/h %e m\n%t %l". ++ Suggested format for bicycle video is "'%s km/h %h ❤\n %e m %c rpm". ++

Suunto Trek Manager (STM) .sdf files (stmsdf)

++ This format can... ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: index .

++ This format supports the .sdf files from the Suunto product family ++ 'Suunto Trek Manager', 'Suunto Ski Manager' and 'Suunto Sail Manager'. ++ The contents of the sdf file depends on the used product and can ++ be one route or one track. Thats why when you want to use sdf on the ++ output side you have to use the ++ -r OR the -t option. This will tell ++ GPSBabel which type of data should be written. ++

++ Currently we can read the following file types: ++

4 = M9 TrackLog
5 = Route
28 = X9 TrackLog

++

gpsbabel -i gpx -f some-routes.gpx -r -o stmsdf,index=3 -F single-route.sdf

++ Suunto Website ++

index option

++ Index of route (if more than one in source). ++

++ Convert route number 'index' from source into sdf format. ++

++ We have a lot of more expressive formats thats support more than one route. ++ At this place sdf files are limited to only one single route. With option index ++ you can specify which route from source should be converted. ++

++ Our default index is 1. ++

++ This example will convert route number two and three into separate sdf files: ++

gpsbabel -i gdb -f routes.gdb -r -o stmsdf,index=2 -F route-one.sdf -r -o stmsdf,index=3 -F route-three.sdf

Suunto Trek Manager (STM) WaypointPlus files (stmwpp)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: index .

++This format supports the Suunto Trek Manager (STM) WaypointPlus format. ++This is a simple format with coordinates and a time stamp. Route points ++also have a short name. A single file may only contain one route or one ++track. ++

++Suunto Website ++

index option

++ Index of route/track to write (if more than one in source). ++

++Because the format supports only one route or track, this option may be used ++on output to select a single route or track from a collection of routes and ++tracks read from a more expressive format. If you have, say, a ++gpx file that contains three routes, you may ++use this option to write them one at a time to individual files. ++

gpsbabel -i gpx -f routes.gpx -o stmwpp,index=1 -F route1.txt -o stmwpp,index=2 -F route2.txt -o stmwpp,index=3 -F route3.txt

Swiss Map 25/50/100 (.xol) (xol)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

++ This module reads and writes xml based (.xol) files used by ++ Swiss Map software. ++

++ These files uses the "Swiss national grid" (CS-1903) to store coordinates. ++

Tab delimited fields useful for OpenOffice, Ploticus etc. (openoffice)

++ This format can... ++

  • ++ read and write tracks ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ Tab separated export-all (except geocaching data) file ++ format. Intended to serve as source for number-processing ++ applications like OpenOffice, Ploticus and others. Tab was chosen as ++ delimiter because it is a) supported by both OpenOffice and Ploticus ++ and b) is not ',', so you can use sed -i ++ "s/./,/g" <x>.csv' to adapt it to locales where ',' is ++ used as decimal seperator. Contributed by Tobias Minich. ++

Teletype [ Get Jonathon Johnson to describe (teletype)

++ This format can... ++

  • ++ read waypoints ++

++This format reads the files written by the Teletype GPS devices with the extension of ".way". ++

++ It's not entirely clear exactly which Teletype products are supported or ++ what versions write the format we read. ++

Textual Output (text)

++ This format can... ++

  • ++ write waypoints ++

This format has the following options: nosep, encrypt, logs, degformat, altunits, splitoutput .

This is a simple human readable version of the data file, ++handy for listings of any type of waypoint files. ++

The following command line reads a GPX file with ++Groundspeak extensions and writes a text file with encrypted hints: ++

gpsbabel -i gpx -f 12345.gpx -o text,encrypt -F 12345.txt

nosep option

++ Suppress separator lines between waypoints. ++

++To suppress the dashed lines between waypoints, use this option. ++

encrypt option

++ Encrypt hints using ROT13. ++

++Use this option to encrypt hints from Groundspeak GPX files. ++

logs option

++ Include groundspeak logs if present. ++

++Use this option to include Groundspeak cache logs in the created document. ++

degformat option

++ Degrees output as 'ddd', 'dmm'(default) or 'dms'. ++

++When GPSBabel writes coordinates, this option is consulted to see if it ++should write decimal degrees ('ddd') decimal minutes ('dmm') or degrees, ++minutes, seconds ('dms'). The default is 'dmm'. ++

altunits option

++ Units for altitude (f)eet or (m)etres. ++

++This option should be 'f' if you want the altitude expressed in feet and ++'m' for meters. The default is 'f'. ++

splitoutput option

++ Write each waypoint in a separate file. ++

++ Splits output into separate files for each waypoint by appending a ++ decimal number to the output filename. ++

Example 3.38. Example for splitoutput option to text format

++ If "MyPQ.gpx" contains five waypoints, ++ ++ gpsbabel -i gpx -f MyPocketQuery -o text,split -F blah ++ ++ will result in files named blah1 ... blah5, each containing info ++ from one of those waypoints. ++


TomTom Itineraries (.itn) (tomtom_itn)

++ This format can... ++

  • ++ read and write routes ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ tomtom_itn can be used to read and write TomTom Navigator Itineraries (Routes). ++

TomTom Places Itineraries (.itn) (tomtom_itn_places)

++ This format can... ++

  • ++ read and write routes ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

TomTom POI file (.asc) (tomtom_asc)

++ This format can... ++

  • ++ read and write waypoints ++

++This format is derived from the xcsv ++format, so it has all of the same options as that format. ++

++ With this format you can read and write TomTom ++ Points of Interest - POI (ascii) files. ++ It is a simple text (csv) format with only latitude, longitude and a short name. ++

TomTom POI file (.ov2) (tomtom)

++ This format can... ++

  • ++ read and write waypoints ++

This format can read and write TomTom .ov2 (POI) files, ++as used by the TomTom GO and TomTom Navigator. It has been tested ++with an original TomTom GO running version 5.00 of the TomTom ++software. There may be some records that confuse the input module - ++if you have an example of such a record "in the wild", and you aren't ++restricted from sharing it, we encourage you to post to the ++gpsbabel-misc mailing list to contact a developer.

Note that in addition to the .ov2 file, you will need a ++.bmp file for the icon. It should be 22x22 and 16 colors, and have ++the same name (not including the extension) as the .ov2 file. ++

TopoMapPro Places File (tmpro)

++ This format can... ++

  • ++ read and write waypoints ++

Reads and writes places files for ++use in TopoMapPro places files. As this file ++type can store links other than web links, anything that is not a http ++url will be discarded. Note that this does not do datum conversions, ++so if your input file does not have WGS84/NZGD2000 data, your output ++file won't either. Colour of waypoint icons defaults to red.

TrackLogs digital mapping (.trl) (dmtlog)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

This format has the following options: index .

++ This format can be used to convert files from ++ TrackLogs Digital Mapping. The files ++ have extension .trl and can contain waypoints and tracks. ++

++ We have seen three different types of this format. Two are binary ++ and one is an XML based format. All three types are supported ++ by our reader. ++

++Users should note that this format orders waypoints in reverse order within the file. If direction of travel is important to you, consider using the Reverse filter to retain waypoint order. ++

index option

++ Index of track (if more than one in source). ++

++ Convert track number 'index' from source into dmtlog format. ++

++ The known variants of Tracklog 'digital mapping' files supports only ++ one track per file. If you have more than one track in source ++ (f.e MapSource and many others can do such heavy things), you ++ can specify which track should by used for the conversion. ++

++ The default index is 1 (the first track of a possible list of tracks). ++

++ An example usage you can find at the ignrando format, ++ which uses option index in same manner. ++

U.S. Census Bureau Tiger Mapping Service (tiger)

++ This format can... ++

  • ++ read and write waypoints ++

This format has the following options: nolabels, genurl, margin, snlen, oldthresh, oldmarker, newmarker, suppresswhite, unfoundmarker, xpixels, ypixels, iconismarker .

The U.S. Census Bureau provides online mapping facilities. ++This format is described at: tiger.census.gov. ++Do notice that this format is not the actual Tiger line mapping ++records, but rather the interface to their online mapping ++program.

nolabels option

++ Suppress labels on generated pins. ++

This option tells GPSBabel to not generate labels on the pins. If ++this is true, the description of the incoming waypoints are ignored and not ++placed on the pins.

genurl option

++ Generate file with lat/lon for centering map. ++

++genurl is a convenience option for generating the scaling parameters ++when accessing the Tiger servers. It will output the latitude, longitude, ++height, and width parameters in a form suitable for use in the URL to generate ++a map that will hold all the points to be displayed and is suitably scaled ++and centered. ++

For example:

gpsbabel -i geo -f geocaching.loc -o tiger,genurl=tiger.ctr -F tiger.dat

++may create tiger.ctr with ++

++lat=36.042108&lon=-86.877408&ht=0.161172&wid=0.591771&iwd=768&iht=768

++ ++After uploading tiger.dat to a public server, a request to ++

 http://tiger.census.gov/cgi-bin/mapgen?murl=$THATFILE$(cat tiger.ctr)

++will return a gif file from the tiger server that's suitably scaled. ++ ++

margin option

++ Margin for map. Degrees or percentage. ++

This option specifies a margin around the maps for the genurl options. ++The margin may be specified in either decimal degrees or as a ++percentage.

++This option is most useful for ensuring there is adequate space for ++the label around the markers when generating automatically scaled maps. ++

snlen option

++ Max shortname length when used with -s. ++

++The snlen option controls the maximum length of names generated by the '-s' ++option. It's particularly useful in Tiger maps to avoid the amount of clutter ++generated by potentially lengthy labels on the markers. ++

oldthresh option

++ Days after which points are considered old. ++

This options allows you to control the threshold in days between ++whether a pin is considered "new" (and thus potentially governed by the ++'newmarker' option) or "old" (and thus potentially governed by the ++'oldmarker' option). ++

oldmarker option

++ Marker type for old points. ++

This option specifies the pin to be used if a waypoint has a creation ++time newer than 'oldthresh' days.

The default is "redpin".

newmarker option

++ Marker type for new points. ++

This option specifies the pin to be used if a waypoint has a creation ++time older than 'oldthresh' days.

The default is "greenpin".

suppresswhite option

++ Suppress whitespace in generated shortnames. ++

++When set, this options tells the '-s' smartname generator to not allow ++any spaces in the labels generated for markers. ++

unfoundmarker option

++ Marker type for unfound points. ++

++ Specifies the icon type for unfound geocaches. Default is "bluepin". ++

xpixels option

++ Width in pixels of map. ++

The xpixels argument lets you specify the number of pixels to be ++generated by the Tiger server along the horizontal axis when using the ++'genurl' option.

ypixels option

++ Height in pixels of map. ++

The ypixels argument lets you specify the number of pixels to be ++generated by the Tiger server along the vertical axis when using the ++'genurl' option.

iconismarker option

++ The icon description is already the marker. ++

This options signifies that the icon in the incoming format is to be used ++without change in the generated Tiger output file. Without this option, ++GPSBabel tries to color pins based on their creation time and certain ++Geocaching traits when available.

Universal csv with field structure in first line (unicsv)

++ This format can... ++

  • ++ read and write waypoints ++

  • ++ read and write tracks ++

  • ++ read and write routes ++

This format has the following options: datum, grid, utc, format, filename, fields .

++ Unicsv examines the first line of a file to determine the field ++ order and field separator in that file. On write, it tries to ++ figure out what data it has and writes headers and all the data it can. ++

++ If the first line contains any tabs, the data lines are assumed ++ to be tab separated. Otherwise the fields are assumed to be ++ separated by commas. ++

++ The list of keywords include: ++ 

++      alt =      Elevation (in meters) of the point. Add "ft" or "feet" for feet.
++      arch =     Geocache archived flag
++      avail =    Geocache available flag
++      bng_e =    British National Grid's easting
++      bng =      full coordinate in BNG format (zone easting northing)
++      bng_pos =  full coordinate in BNG format (zone easting northing)
++      bng_n =    British National Grid's northing
++      bng_z =    British National Grid's zone
++      caden =    Cadence
++      comment =  Notes
++      cont =     Geocache container
++      cour =     Heading / Course true
++      date =     Date (yyyy/mm/dd)
++      depth =    Depth (in meters).  Add "ft" or "feet" for feet.
++      desc =     Description
++      diff =     Geocache difficulty
++      ele =      Elevation (in meters) of the point. Add "ft" or "feet" for feet.
++      e/w =      'e' for eastern hemisphere, 'w' for western
++      exported = Geocache export date 
++      found =    Geocache last found date
++      fix =      3d, 2d, etc.
++      gcid =     Geocache cache id
++      geschw =   Geschwindigkeit (speed)
++      hdop =     Horizontal dilution of precision
++      head =     Heading / Course true
++      heart =    Heartrate
++      height =   Elevation (in meters) of the point
++      hint =     Geocache cache hint
++      icon =     Symbol (icon) name
++      lat =      Latitude
++      lon =      Longitude
++      name =     Waypoint name ("Shortname")
++      n/s =      'n' for northern hemisphere, 's' for southern
++      notes =    Notes
++      pdop =     Position dilution of precision
++      placer =   Geocache placer
++      placer_id =Geocache placer id
++      power =    Cycling power (in Watts)
++      prox =     Proximity (in meters).  Add "ft" or "feet" for feet.
++      sat =      Number of sats used for fix
++      speed =    Speed, in meters per second. (See below)
++      symb =     Symbol (icon) name
++      tempf =    Temperature (degrees Fahrenheit)
++      temp =     Temperature (degrees Celsius)
++      terr =     Geocache terrain
++      time =     Time (hh:mm:ss[.msec])
++      type =     Geocache cache type
++      url =      URL
++      utc_d =    UTC date
++      utc_t =    UTC time
++      utm_c =    UTM zone character
++      utm_e =    UTM easting
++      utm =      full coordinate in UTM format (zone zone-ch easting northing)
++      utm_pos =  full coordinate in UTM format (zone zone-ch easting northing)
++      utm_n =    UTM northing
++      utm_z =    UTM zone
++      vdop =     Vertical dilution of precision
++      x =        Longitude
++      x_pos =    Longitude
++      y =        Latitude
++      y_pos =    Latitude
++      z =        Altitude (elevation).  See "elevation".
++

++ We support some enhanced Garmin attributes. They are also available in ++ gpx, gdb, ++ garmin_gpi and partly ++ garmin_txt. These entities are currently ++ not visible in MapSource™ (6.12.4), but are NOT dropped ++ when working with GDB (version 3) or GPX files. ++ 


++   Please note, that these do NOT provide a geocoding service; don't expect
++	to "convert" a street address to a latitude and longitude.
++   
++      addr =     Street address
++      city =     City
++      country =  Country
++      faci =     Facility (not available in GPX)
++      phone =    Phone number
++      post =     Postal code
++      state =    State
++   

++   Fuller spellings (i.e. "longitude") may be used. You can also
++   use keywords with a whitespace instead of an underscore.
++

++   A typical file may be:
++   
++     Name, Latitude, Longitude, Description 
++     GCEBB,35.972033,-87.134700,Mountain Bike Heaven by susy1313
++     GC1A37,36.090683,-86.679550,The Troll by a182pilot & Family
++   

++

++   On the output side unicsv writes fixed number of columns (waypoint index, latitude and longitude)
++   followed by a variable column list depending on internal data.
++

++   With at least ONE valid timestamp in data a unicsv output may look like that:
++   
++     No,Name,Latitude,Longitude,Description,Date,Time
++     1,"GCEBB",35.972033,-87.134700,"Mountain Bike Heaven by susy1313",2003/06/29,09:00:00
++     2,"GC1A37",36.090683,-86.679550,"The Troll by a182pilot & Family",,
++   

++

++For speed, a units specifier can be added to override the default. Here
++are some values, but check parse_speed() in parse.cc for the authoritative
++list.
++
  • m/s, mps: meters per second
  • km/h, kmh: kilometers per hour
  • kt, knots: knots
  • mph, mi/h, mih: miles per hour

++
datum option

++      GPS datum (def. WGS 84).
++    

++   This option specifies the datum to be used on output. Valid values for this 
++   option are listed in Appendix A, Supported Datums.
++
grid option

++      Write position using this grid..
++    

++   This value specifies the grid to be used on write. It is similar to
++   the grid option of garmin_txt (see Table 3.1, “Grid values for garmin_txt”). The only difference is that unicsv does not
++   write a degree sign (°) into the output file.
++

++   Without this option unicsv writes the coordinates as simple numbers like in the samples above.
++
utc option

++      Write timestamps with offset x to UTC time.
++    

++This option specifies the local time zone to use when writing times.  It
++is specified as an offset from Universal Coordinated Time (UTC) in hours.  
++Valid values are from -23 to +23.
++
format option

++      Write name(s) of format(s) from input session(s).
++    

++  When this option is enabled, we generate an additional 'Format' column.
++  The values of this column are filled with names of previous input formats.
++
Example 3.39. Example for unicsv format option to write names of input formats.

++    The next example ...
++    
++      gpsbabel -i gpx -f file1.gpx -i gdb -f file2.gdb -o unicsv,format=y -F result.txt
++    
++    ... could produce following output:
++    
No,Latitude,Longitude,Name,Description,Symbol,Date,Time,Format
1,51.075139,12.463689,"578","578","Waypoint",2005/04/26,16:27:23,"gdb"
2,51.081104,12.465277,"579","579","Waypoint",2005/04/26,16:27:23,"gdb"
3,50.844126,12.408757,"Gosel","Gosel","Exit",2005/02/26,10:10:47,"gpx"
4,50.654763,12.204957,"Greiz",,"Exit",2005/02/26,09:57:04,"gpx"

++  

filename option

++      Write filename(s) from input session(s).
++    

++  When this option is enabled, we write an additional column called 'Filename'.
++  The values of this column are filled with filenames of previous input formats.
++

++  This can be very helpful for locating specific waypoints (i.e. using the position filter)
++  in more than one file.
++
Example 3.40. Example for unicsv filename option to write filenames of input formats.

++    The next example ...
++    
++      gpsbabel -i gpx -f file1.gpx -i gdb -f file2.gdb -o unicsv,filename=1 -F result.txt
++    
++    ... could produce following output:
++    
No,Latitude,Longitude,Name,Date,Time,Filename
1,51.075139,12.463689,"578",2005/04/26,16:27:23,"reference/gdb-sample.gdb"
2,51.081104,12.465277,"579",2005/04/26,16:27:23,"reference/gdb-sample.gdb"
3,50.844126,12.408757,"580",2005/02/26,10:10:47,"reference/gdb-sample.gpx"
4,50.654763,12.204957,"581",2005/02/26,09:57:04,"reference/gdb-sample.gpx"

++  

fields option

++      Name and order of input fields, separated by '+'.
++    

++This option lets you specify the field names of your input file from
++the command line instead of relying on the first line of your input
++file describing the file. Field names are separated by a '+' character.
++The list of field names is exactly that allowed in the first line of a
++unicsv file without this option.
++
Example 3.41. Example for unicsv fields option to describe input file.

++    For example ...
++    
++      gpsbabel -i unicsv,fields=lat+lon+description -f file.csv -o gpx -F file.gpx
++    
++    declares that file.csv has three fields, latitude, longitude, 
++    and description, in that order.
++  

Vcard Output (for iPod) (vcard)

++    This format can...
++    
  • 
++          write waypoints
++        
This format has the following options: encrypt .
The vCard output is intended to be in a format that
++enables waypoints to be viewed with an Apple iPod. This is achieved by
++mapping waypoint fields into vCard fields that can be displayed as
++'Contacts' on the iPod. With the iPod mounted as a hard disk (see your
++iPod manual for instructions), the resulting VCF file should be moved
++into the iPod 'Contacts' folder. As an alternative, Mac OS X users may
++prefer to drag the VCF file into their address book and synchronize
++with the iPod using iSync. 
++
encrypt option

++      Encrypt hints using ROT13.
++    

++By default geocaching hints are unencrypted; use this option to encrypt them.
++
VidaOne GPS for Pocket PC (.gpb) (vidaone)

++    This format can...
++    
  • 
++          read and write tracks
++        
This format has the following options: ver .

++  This format supports the VidaOne GPS for pocket PC GPB file type.
++

++  This is have a very simple binary format which stores only the coordinates 
++  in the tracklog (.gpb) files.
++
ver option

++      Version of VidaOne file to read or write (1 or 2).
++    

++This option specifies the data format version for the input and the output file.
++Valid values are 1 (without altitude) or 2 (with altitude). 1 is the default.
++
Vito Navigator II tracks (vitosmt)

++    This format can...
++    
  • 
++          read and write waypoints
++        
  • 
++          read and write tracks
++        
  • 
++          read and write routes
++        
Vito Navigator II is a Pocket PC GPS application.  This
++format reads a Vito Navigator II .SMT track file and can work in
++either waypoint or track mode.  The speed, heading and Dilution of
++Position data is written in the notes field.
 Support for writing .SMT tracks is very experimental and
++may crash VitoNavigator II on the Pocket PC.
Vito SmartMap tracks (.vtt) (vitovtt)

++    This format can...
++    
  • 
++          read tracks
++        

++  This format reads the binary (.vtt) track logs recorded by
++  
++  VITO SmartMap for Nokia Series 60
++   1.0, a GPS application for smartphones connected to
++  NMEA 0183-compatible Bluetooth GPS receivers. It may work
++  with .vtt files produced by versions of VITO SmartMap
++  for other platforms.
++

++  This format was reverse engineered from a .vtt file.
++  Currently, the coordinates, altitude, and time are
++  available for each point recorded in a track.
++  The course speed and heading fields have been identified,
++  but the units are not certain and so those fields are ignored.
++  The rest of the entry has not yet been decoded. The format
++  uses little-endian byte ordering. The application displays
++  metric units by default. Time is UTC.
++
Table 3.9. Vito SmartMap track file header (8 bytes)
PositionField info
bytes 0-3Probably a version field. Int value is 3 in sample file.
bytes 4-7Number of points in file as int.

Table 3.10. Vito SmartMap track point (32 bytes)
PositionField info
bytes 0-3Decimal latitude multiplied by 20000000 as int.
bytes 4-7Decimal longitude multiplied by 10000000 as int.
bytes 8-11Altitude in meters as float.
bytes 12-13Year, with century, as int.
byte 14Month, ranging 1-12.
byte 15Day of month, ranging 1-31.
byte 16Hour, ranging 0-23.
byte 17Minute, ranging 0-59.
bytes 18-21Decimal second multiplied by 30000000 as int.
bytes 22-25
++        Probably speed in meters per second as float.
++        Ranges 0-~3 in file, seems reasonable since sample
++        file was acquired on foot.
++      
bytes 26-27
++        Probably decimal heading multiplied by something.
++        Ranges between min and max values possible when
++        decoded as integer. Doesn't change when speed field is 0.
++        Doesn't change smoothly, jumps around a bit.
++      
bytes 28-31
++        Status field of some kind. Changes only twice in file.
++        May contain satellite count or PDOP info, as both are
++        reported by the application's GUI.
++      

WiFiFoFum 2.0 for PocketPC XML (wfff)

++    This format can...
++    
  • 
++          read waypoints
++        
This format has the following options: aicicon, aioicon, ahcicon, ahoicon, snmac .
 WFFF is the export format for Aspecto Software's WiFiFoFum 2.0 for Windows Mobile PCs.
It is a simple XML format that is read-only to GPSBabel and stores information about a WiFi stumbling session.
All WiFi-specific elements are written in the description  field, similar to the netstumbler format.
aicicon option

++      Infrastructure closed icon name.
++    

++This option lets you specify an icon for infrastructure closed points.
++
aioicon option

++      Infrastructure open icon name.
++    

++This option lets you specify an icon for infrastructure open points.
++
ahcicon option

++      Ad-hoc closed icon name.
++    

++This options lets you specify an icon for an Ad-hoc, closed, waypoint.
++
ahoicon option

++      Ad-hoc open icon name.
++    

++This options lets you specify an icon for an Ad-hoc, open, waypoint.
++
snmac option

++      Shortname is MAC address.
++    

++  This options lets you specify that the shortname of the waypoint is the MAC address.
++
Wintec TES file (wintec_tes)

++    This format can...
++    
  • 
++          read waypoints
++        
  • 
++          read tracks
++        
This format supports Wintec .tec files, such as appear on the 
++Wintec WBT-202™ data logger.
++

++The WinTec WBT-202 stores tracks and waypoints on an internal
++MICRO-SD Memory card. The log files can be accessed by connecting to an USB
++host and setting the device into a mass storage device (MSD) mode. To enter
++this mode, attach it to the computer, then hold the power button until the 
++GPS and Bluetooth LEDs go out.  It will then behave like an USB Memory stick.
++and individual files containing your tracks will show up on the "disk" with
++names ending in .tes.   You can use GPSBabel to read these files directly
++or copy them to your host computer.
++

++Note that this format is for the TES files on the GPS, it has no relationship
++to the .TK2 files created by Wintec's Time Machine software for Windows.
++

++Despite the physical similarity to the 
++Wintec WBT-201™, this is believed to be a rather
++different product.  While this GPS probably works fine for 
++realtime tracking over the bluetooth or 
++serial lines (once you have appropriate serial drivers), it's expected
++to not work with GPSBabel's GPSBabel WBT 
++Protocol module.
++
Wintec WBT-100/200 Binary File Format (wbt-bin)

++    This format can...
++    
  • 
++          read tracks
++        
File protocol for the Wintec WBT-200™
++and Wintec WBT-201™ (sometimes called the  G-Rays 2™)GPS data loggers. This format reads the binary file format created
++by Wintec's Windows application.

++Wintec WBT-201 
++
Example 3.42. Command showing conversion of a Wintec binary file to GPX
gpsbabel -i wbt-bin -f tracks.bin -o
++gpx -F out.gpx

Wintec WBT-100/200 GPS Download (wbt)

++    This format can...
++    
  • 
++          read waypoints
++        
  • 
++          read tracks
++        
This format has the following options: erase .
Serial download protocol for the 
++Wintec WBT-200™  and
++Wintec WBT-201™ 
++Wintec WBT-1000™ 
++GPS data loggers. Although untested it is expected that this will also support the WBT-100.

++Wintec WBT-201
++
Example 3.43. Command showing WBT-200 download and erase over Bluetooth on Mac OS X
gpsbabel -t -w -i wbt,erase -f /dev/cu.WBT200-SPPslave-1 -o gpx -F out.gpx


++Internally, this is actually a serial device that has a serial/USB adapter
++built into it.  It uses the CP210x chip by Silicon labs.   You will probably
++need a driver for this chip.  The product ships with one for Windows.  
++The Linux 210x driver seems to work fine.  Mac users will need to download 
++the Mac driver for CP210x.
++

++GPSBabel does not try to offer an interface to configure these units. That
++is left to the Windows software that comes with it or tools like the 
++WBT 201 Viewer for Mac OS/X
++and Linux.
++
erase option

++      Erase device data after download.
++    
This option erases the track log from the device after download.
Wintec WBT-201/G-Rays 2 Binary File Format (wbt-tk1)

++    This format can...
++    
  • 
++          read tracks
++        
File protocol for the Wintec WBT-201 / G-Rays 2™
++GPS data logger. This format reads the binary file format created
++by Wintec's Time Machine X application.

++Wintec WBT-201
++
Example 3.44. Command showing conversion of a Wintec binary file to GPX
gpsbabel -w -t -i wbt-tk1 -f tracks.tk1 -o gpx -F out.gpx

XAiOX iTrackU Logger (itracku)

++    This format can...
++    
  • 
++          read waypoints
++        
  • 
++          read tracks
++        
This format has the following options: backup, new .
Serial download protocol for the XAiOX iTrackU BLUETOOTH GPS-RECEIVER SiRF III™ data logger.
Example 3.45. Command showing a download from itracku connected to com14.
gpsbabel -i itracku -f com14 -o gpx -F out.gpx

Use auto: as input filename to let gpsbabel detect the serial port to which the logger is connected.
Example 3.46. Command showing a download from itracku with automatic port detection.
gpsbabel -i itracku -f auto: -o gpx -F out.gpx

backup option

++      Appends the input to a backup file.
++    
Specifies a backup file for the binary logger data. New waypoints from the logger will be appended to an existing 
++backup file. This allows you to create "endless" binary logger files which, for example, could contain the waypoint data of a whole year.
The backup file can be read with gpsbabel by  using the itracku format.
Example 3.47. Download from the data logger while and append the new binary logger data to a backup file. Read the contents of the backup file.
gpsbabel -i itracku,auto,backup=itracku.bak -f dummy -o gpx -F out.gpx
gpsbabel -i itracku -f itracku.bak -o gpx -F out.gpx

new option

++      Only waypoints that are not the backup file.
++    
Will only pass waypoints along to filters and output formats that are not new, i.e. that are not already stored in the 
++backup file. This option can only be used with the backup option.
Using this option allows you to output the waypoints of your latest trip with gpsbabel while keeping an endless log of all waypoints 
++in the backup file.
Example 3.48. Download from the data logger and append the new logger data to a backup file. Output only the new 
++  waypoints.
gpsbabel -i itracku,auto,backup=itracku.bak,new -f dummy -o gpx -F out.gpx

XAiOX iTrackU Logger Binary File Format (itracku-bin)

++    This format can...
++    
  • 
++          read and write waypoints
++        
  • 
++          read and write tracks
++        
This format has the following options: backup, new .
Reads the binary format of the XAiOX iTrackU BLUETOOTH GPS-RECEIVER SiRF III™ data logger.
Example 3.49. Command showing reading an itracku data file.
gpsbabel -i itracku-bin -f itracku.bin -o gpx -F out.gpx

backup option

++      Appends the input to a backup file.
++    

++  Providing a filename to this option will append the input to a backup file.
++
new option

++      Only waypoints that are not the backup file.
++    

++ When used in conjunction with the "backup" option to this format, it
++  will process only waypoints that don't already exist in the backup file.
++
Yahoo Geocode API data (yahoo)

++    This format can...
++    
  • 
++          read waypoints
++        
This format has the following options: addrsep .

++This format reads output from the 
++Yahoo geocoding API.  
++This feature of GPSBabel makes it easy to get geocoded results from 
++Yahoo into your favorite mapping program, GPS receiver, or other format.
++
addrsep option

++      String to separate concatenated address fields (default=", ").
++    

++This option specifies the string GPSBabel should use to separate the parts
++of the street address.  Since most other formats supported by GPSBabel do 
++not support street addresses, the street address fields from the Yahoo file
++are concatenated into the waypoint "notes" field.
++

++The default value for this option is a comma followed by a space (", ").
++

[1] This model does not support transfer of waypoints, tracks, or routes, but may be used with the realtime tracking feature.
[2] This unit uses GPX format, not Garmin protocol.  Therefore one should communicate with it by reading and writing GPX files instead of using this format.  Members of this class of products do not support realtime positioning protocol.
Chapter 4. Data Filters
Table of Contents
Add points before and after bends in routes (bend)
Include Only Points Inside Polygon (polygon)
Include Only Points Within Distance of Arc (arc)
Include Only Points Within Radius (radius)
Interpolate between trackpoints (interpolate)
Manipulate altitudes (height)
Manipulate track lists (track)
Rearrange waypoints by resorting (sort)
Remove all waypoints, tracks, or routes (nuketypes)
Remove Duplicates (duplicate)
Remove Points Within Distance (position)
Remove unreliable points with high hdop or vdop (discard)
Reverse stops within routes (reverse)
Save and restore waypoint lists (stack)
Simplify routes (simplify)
Swap latitude and longitude of all loaded points (swap)
Transform waypoints into a route, tracks into routes, ... (transform)
Validate internal data structures (validate)
 GPSBabel supports data filtering.  Data filters are
++      invoked from the command line via the '-x' option.  It should be
++      noted that data filters are invoked in the internal pipeline at
++      the point that corresponds to their position on the
++      command. This implies that specifying a filter before reading
++      any data ('-x <filter> -f <file>'), despite being
++      legal, will not have any effect. The advantage is that filters
++      can be used intermittently between several variations of input
++      and output functions.  It should also be noted that filtering
++      data from different input types can sometimes produce
++      undesirable results due to differences in the native data
++      formats.
++
 Beware that most filters only apply to a certain kind of
++      data. This is usually indicated below by referring to points,
++      tracks or routes in the first sentence which describes each
++      filter or in the table at gpsbabel.org
++      .
++
Add points before and after bends in routes (bend)
The bend filter modifies each route replacing each point inside a
++curve with two points: one at a given distance in the direction of the
++previous point, and another at the same distance in the direction of
++the next point in the route. It only replaces points where there is a
++change in heading big enough.
When creating a route, points are usually created inside curves or
++intersections. That means that, while navigating that route using a
++GPS unit, the course pointer would aim to the inside of that curve or
++intersection, and only when you have passed that point will the GPS 
++aim to the next waypoint in the route. This behaviour is useful in
++marine navigation but when biking, for instance, it may be a bit late
++to decide where to turn to in an intersection.
This filter tries to solve that creating a waypoint before and after
++where there is a change in direction.That way, the course pointer will
++point to the direction you should turn to ahead in time.
For this filter to work correctly, the route should be simple enough
++that there is only one waypoint inside each curve or intersection.
++Because of that, it is usually a good idea to use the simplify filter
++before this one.
This command line reads route.gpx and replaces each point with other two
++points: one 25 metres before and another 25 metres after the original
++point. It replaces a point only if there is a change of direction
++larger than 5 degrees.
gpsbabel -i gpx -f route.gpx -x
++bend,distance=25,interpolate,minangle=5 -o gpx -F newroute.gpx
++
distance option

++      Distance to the bend in meters where the new points will be added.
++    
Distance in meters to the original point where the new points will be added.
The new points will be created at this distance. The first one in the
++direction of the previous point, ant the second one in the direction
++of the next point in the route.
minangle option

++      Minimum bend angle in degrees.
++    
Minimum curve angle in degrees.
The substitution will only be made if the change in the heading is
++greater than this value. This avoids replacing a point if the GPS unit
++is already pointing in the correct direction, or if the route reaches
++a certain point and goes back the same road.
Include Only Points Inside Polygon (polygon)
 
++The polygon filter includes points if they are inside
++of a polygon.  A polygon file looks like an 
++arc file, except
++that the arc it describes must be a closed cycle.  That is,
++for a simple polygon, the first and last points must be the
++same.  Here's a square:
++
++# A square (not really) polygon
++41.0000       -85.0000
++41.0000       -86.0000
++42.0000       -86.0000
++42.0000       -85.0000
++41.0000       -85.0000
++
 
++Polygons may include islands and holes.  To include an
++island or a hole, just append it to the main polygon.
++
++# A square polygon with a triangular hole
++41.0000       -85.0000
++41.0000       -86.0000
++42.0000       -86.0000
++42.0000       -85.0000
++41.0000       -85.0000
++# The hole begins here
++41.5000       -85.5000
++41.6000       -85.5000
++41.6000       -85.6000
++41.5000       -85.5000
++

++As with the arc filter, you define a polygon by
++giving the name of the file that contains it, using
++the file option.  
++
 
++Note that this filter currently will not work properly
++if your polygon contains one or both poles or if it spans the
++line of 180 degrees east or west longitude.
++
Example 4.1. Using the polygon filter
 
++Suppose you have a polygon file that defines the border of your county, 
++called mycounty.txt.  This command line will give you only the points 
++in your county:
++
gpsbabel -i geo -f 1.loc -x polygon,file=mycounty.txt -o mapsend -F 2.wpt

Example 4.2. Using the polygon and arc filters to find points in or nearly in a 
++polygon

++Because the polygon and arc filters use
++the same file format, you can use them together to find all points that are
++"in or nearly in" a polygon.  This can be useful if your waypoints or the 
++boundaries of your polygon are not quite perfect, so you want to provide a 
++buffer zone around it in case there are points nearby that should be in the 
++polygon but aren't quite.
++

++gpsbabel -i gpx -f points.gpx -x stack,push -x polygon,file=mycounty.txt 
++-x stack,swap -x arc,file=mycounty.txt,distance=1k -x stack,pop,append 
++-x duplicate,shortname -o gpx -F nearmycounty.gpx
++

++This command makes a copy of the points, finds the ones that are in your
++your county, swaps that result with the copy of the original set of points,
++finds the ones from that set that are within 1 km of the border of the county, 
++puts the two lists together, and then filters out any points that appear twice
++(This step is necessary because points inside the county but near the county 
++line will be kept by both the polygon and the arc filter.)
++

file option

++      File containing vertices of polygon.
++    

++This option is required.
++

++This option specifies the name of the file containing the polygon to use for
++filtering.  The format of the file is as described above.
++

++GPSBabel supports converting any route or track to a file usable by this
++filter; simply read it in the normal way and write it using the 
++arc file format.  Afterward, you will 
++need to make sure that the first point and the last point in the 
++file are the same, as the polygon filter depends on that.  You can do so
++with any text editor.
++
exclude option

++      Exclude points inside the polygon.
++    

++When this option is specified, the usual sense of the polygon filter is 
++reversed.   That is, points that are inside the polygon are discarded
++while points that are further away are kept.
++
Include Only Points Within Distance of Arc (arc)
 
++This filter keeps or removes waypoints based on their proximity to an arc, 
++which is a series of connected line segments similar to a route or a track 
++but without any associated data other than the coordinates.  Optionally, it
++can move each non-deleted waypoint over the closest segment of the arc.
++
 
++The arc may defined in a file whose name must be provided with the 
++file, or the tracks or routes that have already been read.  That file contains pairs of coordinates for the 
++vertices of the arc, one coordinate pair per line.  Comments may be
++included by preceding them with a '#' character.  An arc file looks 
++something like this sample:
++
	  
++# Lima Road/SR3 north of Fort Wayne, Indiana 	  
++41.150064468    -85.166207433 	  
++41.150064468    -85.165371895 	  
++41.149034500    -85.165157318 	  
++41.147832870    -85.164771080 	  
++41.146631241    -85.164384842 	  
++41.144270897    -85.163655281 	  
++41.141953468    -85.162882805
++
 
++An arc file may optionally contain gaps in the arc.  You may specify 
++such a gap by inserting a line containing "#break" either on a line by 
++itself or after the coordinates of the starting point of the new arc segment.
++
Example 4.3. Using the arc filter

++Assuming the arc above is in a file called 
++lima_rd.txt, the following command line
++would include only points within one mile of the section of Lima Road 
++covered by the arc.
++
gpsbabel -i geo -f 1.loc -x arc,file=lima_rd.txt,distance=1 -o mapsend -F 2.wpt

file option

++      File containing vertices of arc.
++    

++This option specifies the name of the file containing the arc to use for
++filtering.  The format of the file is as described above.
++

++GPSBabel supports converting any route or track to a file usable by this
++filter; simply read it in the normal way and write it using the 
++arc file format.
++
rte option

++      Route(s) are vertices of arc.
++    

++When this option is specified the routes contains the vertices of the arc.
++If there are several routes then it is assumed that there is a gap between
++each of them.
++
trk option

++      Track(s) are vertices of arc.
++    

++When this option is specified the tracks contains the vertices of the arc.
++If there are several tracks then it is assumed that there is a gap between
++each of them.
++
distance option

++      Maximum distance from arc.
++    

++This option is not required, but if it is not specified the distance 
++defaults to zero miles, which isn't very useful.
++

++This option specifies the maximum distance a point may be from the arc 
++without being discarded.  Points that are closer to the arc are kept, while
++points that are further away are discarded.
++

++Distances may be specified in miles (3M) or kilometers (5K).  If no units
++are specified, the distance is assumed to be in miles.
++
exclude option

++      Exclude points close to the arc.
++    

++When this option is specified, the usual sense of the arc filter is reversed. 
++That is, points that are closer than distance are discarded
++while points that are further away are kept.
++
points option

++      Use distance from vertices not lines.
++    

++When this option is specified, only points that are within the specified 
++distance of one of the vertices of the arc are kept.  This differs from the
++normal mode of operation in that in the normal mode, points that are close to
++the lines between points are also kept.
++

++This option makes the arc filter act like a multi-point version of the
++radius filter.
++
project option

++      Move waypoints to its projection on lines or vertices.
++    

++When this option is specified, each non deleted waypoint is moved over the
++closest segment, or over the nearest point if points option
++is used.
++

++With rte and trk optinos, if
++is possible, altitude, creation_time and microsecond fields of waypoints
++are updated by interpolation.
++

++This is most useful if you are trying to obtain the closest points in
++a road to some places. Or if you want to know the step times on some
++places over the tracks. Also to transform waypoints in Garmin course points
++(see gtrnctr and
++garmin format).
++
Include Only Points Within Radius (radius)
 
++This filter includes or excludes waypoints based on their proximity to a 
++central point.  All waypoints more than the specified distance from the 
++specified point will be removed from the dataset.
++

++By default, all remaining points are sorted so that points closer to the 
++center appear earlier in the output file.
++
Example 4.4. Using the radius filter to find points close to a given point
This example command line would include only points within 1 1/2 miles
++       of N30.000 W 90.000
gpsbabel -i geo -f 1.loc -x radius,distance=1.5M,lat=30.0,lon=-90.0 -o mapsend -F 2.wpt

lat option

++      Latitude for center point (D.DDDDD).
++    

++This option is required.
++

++This option specifies the latitude of the central point in decimal degrees.
++South latitudes should be expressed as a negative number.  Valid values for
++this option are from -90 to 90.
++
lon option

++      Longitude for center point (D.DDDDD).
++    

++This option is required.
++

++This option specifies the longitude of the central point in decimal degrees.
++West longitudes should be expressed as a negative number.  Valid values for
++this option are from -180 to 180.
++
distance option

++      Maximum distance from center.
++    

++This option is required.
++

++This option specifies the maximum distance a point may be from the central
++point in order to remain in the dataset.  Points closer than this distance
++will be kept and points further away will be removed (unless the 
++exclude option is specified.)
++

++Distances may be expressed in miles (3M) or kilometers (4K).  If no units
++are provided, the distance is assumed to be in miles.
++
exclude option

++      Exclude points close to center.
++    

++If this option is included, the action of the radius filter will be reversed:
++points within the given distance will be removed, and points further away
++will be kept.
++
nosort option

++      Inhibit sort by distance to center.
++    

++If this option is specified, the radius filter will not sort the remaining
++points by distance from the center.  They will remain in whatever order they
++were originally.
++
maxcount option

++      Output no more than this number of points.
++    

++This option specifies the maximum number of points that the radius filter may
++keep.  If there are more than this number of points within the specified 
++distance of the center, the more distant points will be discarded even though
++they are within the specified distance.  If this option is not specified, 
++all points are kept regardless of how many there are.
++

++Note that if the nosort option is also specified, this 
++option will instead keep points based on their position within the input
++file rather than on their distance from the center.  This may or may not be
++what you want.
++

++Note, too, that this option may be used with the exclude 
++option, but the results might not be what you expect.  In particular, the 
++results will not be the same as if you had kept all of the points you'd 
++otherwise throw away.  You will still get no more than 
++maxcount points, but they will all be at least 
++distance away from the center.  (And possibly sorted.)
++
asroute option

++      Put resulting waypoints in route of this name.
++    

++This option specifies the name of a route.  If this option is specified, the
++radius filter puts all points that are kept into a route with the given name.
++The order of points in the route is by distance from the center (unless the
++nosort option is also specified.)
++

++Note that this route is not necessarily the most efficient route to visit 
++all of the points.  In fact, for some data sets, it might be the least 
++efficient route.
++
Interpolate between trackpoints (interpolate)

++This filter modifies any tracks so that either the distance or the time
++between consecutive points is no less than the specified interval. Where
++points are missing, the filter fills them in by following a straight 
++line (actually a great circle) between the adjacent points.  You
++must specify either the 
++distance or the time option.
++
Example 4.5. Using the interpolate filter

++This command line reads track.gpx and inserts points wherever two adjacent
++trackpoints are more than 10 seconds apart:
++
gpsbabel -i gpx -f track.gpx -x interpolate,time=10 -o gpx -F newtrack.gpx

++This command reads track.gpx and inserts points wherever two adjacent
++trackpoints are more than 15 kilometers apart:
++
gpsbabel -i gpx -f track.gpx -x interpolate,distance=15k -o gpx -F newtrack.gpx

++This command reads track.gpx and inserts points wherever two adjacent
++trackpoints are more than 2 miles apart:
++
gpsbabel -i gpx -f track.gpx -x interpolate,distance=2m -o gpx -F newtrack.gpx

time option

++      Time interval in seconds.
++    

++This option specifies the maximum allowable time interval between points in the
++track.  If two points in the track are further apart than this value, new
++points will be inserted between them.
++

++This value is always specified in units of seconds.
++

++Either this option or the distance must be specified.
++
distance option

++      Distance interval in miles or kilometers.
++    

++This option specifies the maximum allowable distance between points in the
++track.  If two points in the track are further apart than this value, new
++points will be inserted between them.
++

++This value may be specified in units of miles (3M) or kilometers (5K).  If
++no units are specified, the units are assumed to be miles.
++

++Either this option or the time must be specified.
++
route option

++      Interpolate routes instead.
++    

++If this option is specified, the interpolate filter interpolates routes 
++rather than tracks.  Because route points do not have time stamps, it is an
++error to use this option with the time option.
++
Manipulate altitudes (height)
 
++The height filter allows the correction of altitude values.
++
++At least one popular gps logger does store the ellipsoidal height (sum of the height above mean see level and the height of the geoid above the WGS84 ellipsoid) instead of the height above sea level, as it can be found on maps. 
++
++The height filter allows for the correction of these altitude values. This filter supports two options:   
++
++wgs84tomsl and add.  
++At least one of these options is required, both can be combined.  
++
Example 4.6.  This option subtracts the WGS84 geoid height from every altitude. For GPS receivers like the iBlue747 the result is the height above mean see level.
 gpsbabel -i gpx -f in.gpx -x height,wgs84tomsl -o gpx -F out.gpx
The coordinates and altitude vales must be based an the WGS84 ellipsoid for this option to produce sensible results

Example 4.7.  This options adds a constant value to every altitude.
 gpsbabel -i gpx -f in.gpx -x height,add=10.2f -o gpx -F out.gpx
You can specify negative numbers to subtract the value. If no unit is specified meters are assumed. For feet you can attach an "f" to the value.

add option

++      Adds a constant value to every altitude (meter, append "f" (x.xxf) for feet).
++    

++Adds a constant value to every altitude. You can specify negative numbers to subtract the value.
++

++If no unit is specified, (m)eters are assumed. You can override this by attaching a "f" for feet to the number.
++
wgs84tomsl option

++      Converts WGS84 ellipsoidal height to orthometric height (MSL).
++    

++  Subtracts the WGS84 geoid height from every altitude.
++

++  For GPS receivers like the iBlue747 this corrects the logged altitudes to height above mean sea level.
++
Manipulate track lists (track)

++WARNING: This filter always drops empty tracks.
++

++This filter performs various operations on track data.
++
move option

++      Correct trackpoint timestamps by a delta.
++    

++This option changes the time of all trackpoints. This might be useful if
++your track must be moved by one or more hours because of an incorrect
++time zone.
++
Example 4.8. Time-shifting a track with the track filter

++The following command line will shift all tracks to be one hour later.
++
gpsbabel -t -i gpx -f in.gpx -x track,move=+1h -o gpx -F out.gpx

pack option

++      Pack all tracks into one.
++    
 
++This option causes all tracks to be appended to one another to form a single
++track.  This option does not work if any two tracks overlap in time; in that
++case, consider using the merge option. 
++

++This option is most useful for rejoining tracks that might have
++been interrupted by an equipment malfunction or an overnight stop.
++

++If no other option is given to the track filter, this option is assumed.
++
split option

++      Split by date or time interval (see README).
++    
 The input track will be split into several tracks
++         depending on date of track points. If there is more than one
++         track, use the pack option before before using this.  To
++         split a single tracks into separate tracks for each day and
++         name them, use this:
++      
 gpsbabel -t -i gpx -f in.gpx -x track,split,title="ACTIVE LOG # %Y%m%d" -o gpx -F out.gpx
 If the input has multiple tracks, pack them together before
++splitting them back apart per day thusly: 
     	    gpsbabel -t   -i gpx -f in.gpx  
++     -x track,pack,split,title="ACTIVE LOG # %D"  	
++     -o gpx -F out.gpx
 Additionally you can add an interval to the split
++         option.  With this the track will be split if the time
++         between two points is greater than this parameter. The
++         interval must be numeric and can be int days, hours, minutes
++         or seconds, expressed as one of the character "d", "h", "m",
++         or "s".  If no trailing character is present, the units are
++         assumed to be in seconds.
++
 For example, to split a track based on an four hour
++         interval, use this:
            
++gpsbabel -t 
++     -i gpx -f in.gpx 
++     -x track,pack,split=4h,title="LOG # %c" 
++     -o gpx -F out.gpx
++
sdistance option

++      Split by distance.
++    
 The input track will be split into several tracks
++         if the distance between successive track points
++         is greater than the distance given as a parameter.
++         The distance must be numeric and can be in miles or kilometers,
++         expressed as one of the character "k", or "m".
++	If sdistance is given no parameters, this option has the same 
++	effect as the split option without parameters. If there is more 
++	than one track,
++         use the pack option before before using this.
 For example, to split the track if the distance between
++         points is greater than 100 meters, use this:

++gpsbabel -t 
++     -i gpx -f in.gpx 
++     -x track,pack,sdistance=0.1k" 
++     -o gpx -F out.gpx
++
 The sdistance option can be combined with the split option.
++        The track then will be split only if both time and distance
++        interval exceeds the supplied values. This technique can be used to 
++	filter out gaps from
++        the tracklog.  The gap is kept only if the gps device is without
++        signal for longer time than that given and during that time it moves 
++	a distance over that given.
++        This example splits the track
++        if the device is without signal for at least 5 minutes
++        and during this time moves more than 300 meters:

++gpsbabel -t 
++     -i gpx -f in.gpx 
++     -x track,pack,sdistance=0.3k,split=5m 
++     -o gpx -F out.gpx
++
merge option

++      Merge multiple tracks for the same way.
++    
 
++This option puts all track points from all tracks into a single track 
++and sorts them by time stamp.  Points with identical time stamps will be
++dropped.
++
Example 4.9. Merging tracks with the track filter
 
++Suppose you want to merge tracks recorded with two different GPS devices 
++at the same time.  To do that, use this command line:
++
gpsbabel -t -i gpx -f john.gpx -i gpx -f doe.gpx -x track,merge,title="COMBINED LOG" -o gpx -F john_doe.gpx

name option

++      Use only track(s) where title matches given name.
++    

++With the name option you can filter out a track by title.
++

++The comparison is always non-case-sensitive. Wildcards are allowed.
++
start option

++      Use only track points after this timestamp.
++    

++This option is used along with the stop to discard 
++trackpoints that were recorded outside of a specific period of time.  
++This option specifies the beginning of the time period.
++

++If this option is not specified, the time period is assumed to begin at the
++dawn of time or January 1, 1970, whichever was later.  The time for this 
++option is expressed in UTC. 
++

++The value of this option must be in the form of YYYYMMDDHHMMSS, but it is
++not necessary to specify the smaller time units if they are not needed.  
++That is, if you only care about points logged between 10 AM and 6 PM on a
++given date, you need not specify the minutes or seconds.
++
Example 4.10. Extracting a period of time with the track filter

++To get only the parts of a track that were mapped on 20 July 2005
++between 10 AM and 6 PM, use this command line:
++
gpsbabel -t -i gpx -f in.gpx -x track,start=2005072010,stop=2005072018 -o gpx -F out.gpx 

stop option

++      Use only track points before this timestamp.
++    

++This option is used in conjunction with the start option to 
++discard all trackpoints outside of a given period of time.  This option 
++defines the end of the time period.
++

++If this option is not specified, the time period is assumed to end at the 
++end of civilization as we know it or the year 2038, whichever comes first.
++The time for this option is expressed in UTC.
++

++See the start option for the format of this value and an 
++example of usage.
++
title option

++      Basic title for new track(s).
++    
 
++This option specifies a title for tracks generated by the track filter.
++By default, the title of the new track is composed of the start time of 
++the track appended to this value.
++

++If this value contains a percent (%) character, it is treated as a format 
++string for the POSIX strftime function, allowing custom time-based 
++track names. 
++
fix option

++      Synthesize GPS fixes (PPS, DGPS, 3D, 2D, NONE).
++    

++This option sets the GPS fix status for all trackpoints to the specified
++value.  Valid values for this option are PPS, DGPS, 3D, 2D, or NONE.
++

++This option is most useful when converting from a format that doesn't 
++contain GPS fix status to one that requires it.
++
course option

++      Synthesize course.
++    

++This option computes (or recomputes) a value for the GPS heading at each 
++trackpoint.  This is most useful with trackpoints from formats that don't 
++support heading information or for trackpoints synthesized by the 
++interpolate
++filter.  The heading at each trackpoint is simply the course from the
++previous trackpoint in the track.  The first trackpoint in each track
++is arbitrarily assigned a heading of 0 degrees.
++
speed option

++      Synthesize speed.
++    

++This option computes a value for the GPS speed at each trackpoint.
++This is most useful with trackpoints from formats that don't support
++speed information or for trackoints synthesized by the 
++interpolate
++filter.

++The speed at each trackpoint is the average speed from the
++previous trackpoint (distance divided by time).  The first trackpoint 
++in each track is assigned a speed of "unknown."
++

++The unit of speed is meters per second.
++
seg2trk option

++      Split track at segment boundaries into multiple tracks.
++    
trk2seg option

++      Merge tracks inserting segment separators at boundaries.
++    
segment option

++      segment tracks with abnormally long gaps.
++    
faketime option

++      Add specified timestamp to each trackpoint.
++    

++This option assigns a time value to each trackpoint.
++

++The value of this option must be in the form of fYYYYMMDDHHMMSS+SS.
++

++The parameter f (force) is optional and means that the time value of each trackpoint is replaced.
++If f is not specified, the time value of each trackpoint is only replaced when the trackpoint contains no time value.
++

++YYYYMMDDHHMMSS is the pattern for the timestamp and is required.
++

++The plus sign is the delimiter between the timestamp and the step time in seconds.
++The first trackpoint receives the time value of the timestamp and
++each following trackpoint receives the timestamp incremented by the step time.
++The specification of the steptime is optional.
++

++The parameter was added because some software products (e.g. garmin training center)
++require a time value for each trackpoint.
++
Example 4.11. Replace time values of a track

++Replace all time values with new time values.
++Start at the 5 th of July, 2010 at 8 PM and
++increment 2 seconds between each trackpoint:
++
gpsbabel -i kml -f in.kml -x track,faketime=f20100705200000+2 -o gtrnctr -F out.tcx

Example 4.12. Add time values to a track

++Add a time value to a trackpoint, if the trackpoint contains no time value.
++Start at the 6 th of May, 2010 at 6 AM and
++increment 5 seconds between each trackpoint:
++
gpsbabel -i kml -f in.kml -x track,faketime=20100506060000+5 -o gtrnctr -F out.tcx

discard option

++      Discard track points without timestamps during merge.
++    
 
++This option is used in conjunction with the merge option to discard track points with missing
++timestamps instead of aborting with the "Found track point at lat,lon without time!" error.
++
Example 4.13. Merging tracks with missing timestamps with the track filter
 
++Suppose you want to merge tracks that may have missing timestamps.  To do that, use this command line:
++
gpsbabel -t -i gpx -f john.gpx -f doe.gpx -x track,merge,discard -o gpx -F john_doe.gpx

minimum_points option

++      Discard tracks with fewer than these points.
++    

++Eliminates any remaining tracks with fewer than this number of trackpoints.
++

++This step is performed last by this filter and is used to clean up earlier
++simplifications that may have left tracks with so few points as to be 
++useless, such as a track taken while stationary but with GPS wander.
++
Rearrange waypoints by resorting (sort)

++This filter sorts waypoints into alphabetical order by the selected field.
++You must specify exactly one of the options.
++
gcid option

++      Sort by numeric geocache ID.
++    

++If the data contains Groundspeak geocache IDs, this option causes the 
++waypoints to be sorted in alphabetical order by geocache ID.
++

++This option is not valid in combination with any other option.
++
shortname option

++      Sort by waypoint short name.
++    

++This option causes the waypoints to be sorted in alphabetical order by 
++short name.
++

++This option is not valid in combination with any other option.
++
description option

++      Sort by waypoint description.
++    

++This option causes the waypoints to be sorted in alphabetical order by 
++description.
++

++This option is not valid in combination with any other option.
++
time option

++      Sort by time.
++    

++This option causes the waypoints to be sorted in chronological order by 
++creation time.
++

++This option is not valid in combination with any other option.
++
Remove all waypoints, tracks, or routes (nuketypes)

++There are three main types of data that GPSBabel deals with:
++waypoints, tracks, and routes.   The nuketypes filter allows
++removing all the data of any or all of those three types.
++
Example 4.14. Filtering data types with nuketypes

++If you have a GPX file that contains routes, tracks, and
++waypoints and you want a GPX file that contains only tracks,
++you may use this filter to remove the waypoints and the routes 
++with this command:
++
gpsbabel -i gpx -f bigfile.gpx -x nuketypes,waypoints,routes -o gpx -F tracksonly.gpx

waypoints option

++      Remove all waypoints from data stream.
++    

++This option causes the nuketypes filter to discard all waypoints that are not 
++associated with a track or route.
++
tracks option

++      Remove all tracks from data stream.
++    

++This option causes the nuketypes filter to discard all track data.
++
routes option

++      Remove all routes from data stream.
++    

++This option causes the nuketypes filter to discard all route data.
++
Remove Duplicates (duplicate)
 
++The duplicate filter is designed to remove duplicate points based on their 
++short name (traditionally a waypoint's name on the GPS receiver), and/or 
++their location (to a  precision of 6 decimals).  This filter supports two 
++options that specify how duplicates will be recognized, 
++shortname and location.  
++Generally, at least one of these options is required.  
++
Example 4.15. Using the duplicate filter to suppress points with the same 
++         name and location

++  This command line removes points that have duplicate short names
++  and duplicate locations.  The result would be a 
++  gpx file that more than likely 
++  contains only unique points and point data.
++  
 gpsbabel -i gpx -f 1.gpx -f 2.gpx -x duplicate,location,shortname -o gpx -F merged_with_no_dupes.gpx

shortname option

++      Suppress duplicate waypoints based on name.
++    

++This option is the one most often used with the duplicate filter.  This 
++option instructs the duplicate filter to remove any waypoints that share
++a short name with a waypoint that has come before.  This option might be
++used to remove duplicates if you are merging two datasets that were 
++each created in part from a common ancestor dataset.
++
location option

++      Suppress duplicate waypoint based on coords.
++    

++This option causes the duplicate filter to remove any additional waypoint 
++that has the same coordinates (to six decimal degrees) as a waypoint that 
++came before.  This option may be used to remove duplicate waypoints if the 
++names are not expected to be the same.  It also might be used along with the
++shortname option to remove duplicate waypoints if the names 
++of several unrelated groups of waypoints might be the same.
++
all option

++      Suppress all instances of duplicates.
++    

++When this option is specified, GPSBabel will remove all instances of a
++duplicated waypoint, not just the second and subsequent instances.  If
++your input file contains waypoints A, B, B, and C, the output file will
++contain waypoints A, B, and C without the all option, 
++or just A and C with the all option.
++
Example 4.16. Using the duplicate filter to implement an "ignore list."

++This option may be used to implement an "ignore list."  In the following 
++example, the duplicate filter is used to remove a list of waypoints to be
++ignored from a larger collection of waypoints:
++
gpsbabel -i gpx -f waypoints.gpx -i csv -f to_ignore.csv -x duplicate,shortname,all -o gpx -F filtered.gpx

correct option

++      Use coords from duplicate points.
++    

++This option is used to change the locations of waypoints without losing any 
++of the other associated information.  When this option is specified, the 
++latitude and longitude from later duplicates will replace the latitude and
++longitude in the original waypoint.
++

++As an example, this option may be used to adjust the locations of "puzzle" 
++geocaches in a Groundspeak pocket query:
++
Example 4.17. Using the duplicate filter to correct the locations of "puzzle"
++geocaches
gpsbabel -i gpx -f 43622.gpx -i csv -f corrections.csv -x duplicate,shortname,correct -o gpx -F 43622-corrected.gpx

++After this command is run, the waypoints in the output file will have all 
++of the descriptive information from 43622.gpx, but 
++waypoints that were also found in corrections.csv 
++will have their coordinates replaced with the coordinates from that file.
++

Remove Points Within Distance (position)
 
++This filter removes points based on their proximity to each other.  A 
++point is removed if it is within the specified distance of a point that 
++has come before.
++
Example 4.18. Using the position filter to suppress close points

++The following command removes multiple points that are within 
++one foot of each other, leaving just one.
++
gpsbabel -i geo -f 1.loc -f 2.loc -x position,distance=1f -o mapsend -F 3.wpt

distance option

++      Maximum positional distance.
++    

++This option specifies the minimum allowable distance between two points.  If 
++two points are closer than this distance, only one of them is kept.
++

++Distances may be expressed in feet (30f) or meters (10m).  If no unit is 
++specified, the distance is assumed to be in feet.
++
all option

++      Suppress all points close to other points.
++    

++This option causes the position filter to remove all points that are within
++the specified distance of one another, rather than leaving just one of them.
++

++This option may be used to entirely remove clusters of points.
++
time option

++      Maximum time in seconds beetween two points.
++    

++  Specifies the maximum time in seconds between any two points. If the 
++  time difference is larger than what's specified here, the points will 
++  not be discarded.
++

++  This is useful if you have multiple tracks of the same course and you'd
++  like the filter to consider the tracks the same.
++
Remove unreliable points with high hdop or vdop (discard)

++This filter is used to "fix" unreliable GPS data by discarding points
++that are believed to be unreliable.  You may specify an 
++HDOP and/or VDOP above a specified limit, a minimum number of satellites
++that must have been in view for a fix to be considered, or both.
++

++HDOP and VDOP are measures of the best possible horizontal or vertical precision for a given configuration of GPS satellites.   Higher numbers indicate a higher dilution of precision and therefore mathematically less useful.
++

++
Example 4.19. Using the discard filter for HDOP and VDOP. 
 gpsbabel -i gpx -f in.gpx -x discard,hdop=10,vdop=20,hdopandvdop -o gpx -F out.gpx


++

++You may specify a minimum number of  satellites.  
++

++
Example 4.20. Using the discard filter to require at least three satellites. 
 gpsbabel -i gpx -f in.gpx -x discard,sat=3 -o gpx -F out.gpx


++
 Contributed by Tobias Minich and Serge Droz. 
hdop option

++      Suppress points with higher hdop.
++    

++This option specifies the maximum allowable Horizontal Dilution of 
++Precision (HDOP).  By default, any point with an HDOP in excess of 
++this value will be discarded regardless of its VDOP, but see 
++hdopandvdop.
++
vdop option

++      Suppress points with higher vdop.
++    

++This option specifies the maximum allowable Vertical Dilution of 
++Precision (VDOP).  By default, any point with an VDOP in excess of 
++this value will be discarded regardless of its HDOP, but see 
++hdopandvdop.
++
hdopandvdop option

++      Link hdop and vdop supression with AND.
++    

++If this option is used, only points that exceed both the maximum 
++allowable HDOP and the maximum allowable VDOP will be discarded.  This
++option requires that both the hdop and 
++vdop options be specified.  
++
sat option

++      Minimium sats to keep points.
++    

++This option specifies the minimum required number of satellites.
++
fixnone option

++      Suppress points without fix.
++    

++  This option is similar to the 'sat' option.   There are times when
++  some GPSes will know how many satellites are in view, but not yet computed
++  a valid fix.  This option allows you to discard those points.
++
fixunknown option

++      Suppress points with unknown fix.
++    

++  This option is similar to the 'sat' option. Some GPSes will log
++  points with a fix value of 'unknown'.
++  This option allows you to discard those points.
++
elemin option

++      Suppress points below given elevation in meters.
++    

++This option drops waypoints with an altitude lower than the specified 
++value (in meters).   Although GPS altitude isn't very accurate, 
++GPS devices may log faulty waypoints from time to time, such as when 
++near tall buildings.  Elevation values that are way off may signify such waypoints.  Use this option to the filter to toss known rogue points.
++
elemax option

++      Suppress points above given elevation in meters.
++    

++This option drops waypoints with an altitude higher than the specified value (in meters).   See elemin for an explanation why this may be useful.
++
matchname option

++      Suppress points where name matches given name.
++    

++This option discards points that have shortnames that match the 
++provided regular expresision.
++
Example 4.21. Discarding specific point by regular expression

++For example geocaches typically have names starting with GC followed
++by an alphanumeric sequence of variable length.  To remove all six character
++long IDs that between (and including) GC1000 and GC2FFF, you could use
++

++gpsbabel -i geo -f geocaching.loc -x discard,matchname=GC[1-2]...
++
++to discard all GCs followed by exactly three characters.
++

matchdesc option

++      Suppress points where description matches given name.
++    

++Like matchname, but instead matches on the description.
++
matchcmt option

++      Suppress points where comment matches given name.
++    

++Like matchname, but instead matches on the comment.
++
matchicon option

++      Suppress points where type matches given name.
++    

++Like matchname, but instead matches on the icon description.
++
Reverse stops within routes (reverse)
 The reverse filter is used to reverse tracks and routes.
++	It's mostly useful for those few formats where track/route
++	sequence matters and there isn't a way to reverse them using
++	the program itself.
 The reversal is performed in the laziest way possible.
++        Timestamps are kept with the original waypoints so the
++        resulting track or route will have the interesting
++        characteristic that time runs backwards.  This tends to make
++        Magellan Mapsend, in particular, do a weird thing and place
++        each waypoint on a separate day.
++
 Additionally, if you're using this to reverse a route
++         that navigates, say, an exit ramp or a one way street, you
++         will be in for unpleasant ride. application cares about
++         timestamps
++
Save and restore waypoint lists (stack)
 
++This filter is designed to solve advanced problems that involve shuffling 
++multiple lists of waypoints, tracks, or routes.  
++

++The stack filter can be used to save the current state of the entire
++collection of data.  That state is placed on top of a stack of collections,
++so you can simultaneously have as many stored collections of data as you
++can fit in your computer's memory.
++
 
++ The stack filter can be used in conjunction with other
++ filters to implement a "union" or "logical or" functionality.
++ The basic idea is to use the stack to store copies of the
++ original list of waypoints, then use the 'swap' function to
++ replace each copy with a filtered list.  Finally, append all
++ of the filtered lists to create one big list, which is then
++ output.  The following example finds a list of all points
++ that are either inside county A or inside county B.  Any
++ points that are inside both counties are duplicated (but the
++ duplicates can be removed with the DUPLICATE filter; see
++ above.)
++
           
++gpsbabel -i gpx -f in.gpx 
++         -x stack,push,copy 
++         -x polygon,file=county_a.txt 
++         -x stack,swap 
++         -x polygon,file=county_b.txt 
++         -x stack,pop,append 
++         -o gpx -F out.gpx
++
 This example reads a large list of waypoints and
++         extracts the points within 20 miles of each of two cities,
++         writing the waypoint descriptions into two different PalmDoc
++         files and exporting all of the points to the GPS receiver:
++
           
++gpsbabel -i gpx -f indiana.gpx 
++         -x stack,push,copy 
++         -x radius,lat=41.0765,lon=-85.1365,distance=20m 
++         -o palmdoc,dbname=Fort\ Wayne -F fortwayne.pdb 
++         -x stack,swap 
++         -x radius,lat=39.7733,lon=-86.1433,distance=20m 
++         -o palmdoc,dbname=Indianapolis -F indianapolis.pdb 
++         -x stack,pop,append 
++         -o magellan -F fwaind.wpt
++
push option

++      Push waypoint list onto stack.
++    

++This is one of three "primary" options to the stack filter.
++

++When this option is specified, the current state is pushed onto the top of
++the stack.  By default, the current state is then cleared, but the 
++copy option can be used to cause it to be saved.
++
pop option

++      Pop waypoint list from stack.
++    

++This is one of three "primary" options to the stack filter.
++

++This option "pops" the collection of data from the top of the stack.  
++By default, the saved state replaces the current state, but see the 
++discard and append options for 
++alternatives.
++
swap option

++      Swap waypoint list with <depth> item on stack.
++    

++This is one of three "primary" options to the stack filter.
++

++When this option is specified, the current state is swapped with a saved
++state from the stack.  By default, it is swapped with the top of the stack,
++but the depth can be used to specify a different saved
++state.
++
copy option

++      (push) Copy waypoint list.
++    

++This option is only valid when used with the push option.
++When this option is specified, a copy of the current state is pushed onto 
++the stack but the current state is left unchanged.  Otherwise, the push 
++operation clears the current data collection.
++
append option

++      (pop) Append list.
++    

++This option is only valid in conjunction with the pop.  
++When it is specified, the topmost collection of data from the stack is
++appended to the current collection of data.
++
discard option

++      (pop) Discard top of stack.
++    

++This option is only valid when used with the pop option.
++When this option is specified, the popped state is discarded and the current
++state remains unchanged.
++
replace option

++      (pop) Replace list (default).
++    

++This option is only valid when used with the pop option.
++This is the default behavior of the pop option, so you 
++should never need to specify it, but it is included for the sake of 
++readability.  When this option is specified, the popped state replaces 
++the current state.
++
depth option

++      (swap) Item to use (default=1).
++    

++This option is only valid when used along with the swap
++option.  If specified, it indicates which item on the stack should be
++swapped with the current state.  The default value is 1, which corresponds
++to the top of the stack.
++
Simplify routes (simplify)
 
++The Simplify filter is used to simplify routes and tracks for use with 
++formats that limit the number of points they can contain or just to 
++reduce the complexity of a route.
++

++The filter attempts to remove points from each route until the number 
++of points or the error is within the given bounds, while also attempting 
++to preserve the shape of the original route as much as possible.  
++
 
++The quality of the results will vary depending on the density of points 
++in the original route and the length of the original route.
++
 
++For example, suppose you have a route from Street Atlas 2003 that you 
++wish to use with a Magellan GPS receiver that only supports up to 50 points 
++in a route:
++
gpsbabel -r -i saroute -f RoadTrip.anr -x simplify,count=50 -o magellan  -F grocery.rte
count option

++      Maximum number of points in route.
++    

++This option specifies the maximum number of points which may appear in the
++simplified route.  For example, if you specify "count=50", all resulting
++routes will contain 50 points or fewer.  
++

++You must specify either this option or the error option.
++
error option

++      Maximum error.
++    

++This option specifies the maximum allowable error that may be introduced
++by removing a single point. Used with the length
++and crosstrack methods, the value of this option is a distance,
++specified in miles by default.  You may also specify the distance in 
++kilometers by adding a 'k' to the end of the number.
++For the relative method it is a dimensionless quantity.
++
 
++How the error is determined depends on whether the length,
++crosstrack, or relative method is used.
++If you are using the length method, the error is the change in the length of
++the route introduced by removing a point.  If you are using the crosstrack
++method, the error is the distance from the point to the line that results if
++that point is removed. If you are using the relative method, the error is the
++ratio between the crosstrack error and the horizontal accuracy (derived from
++HDOP data).
++
crosstrack option

++      Use cross-track error (default).
++    

++This option instructs GPSBabel to remove points that have the smallest 
++overall effect on the overall shape of the route.  Using this method, the
++first point to be removed will be the one that is closest to a line drawn 
++between the two points adjacent to it.
++

++If neither this option nor the length option is specified,
++this is the default.
++
length option

++      Use arclength error.
++    

++This option instructs GPSBabel to simplify by removing points that cause the
++smallest change in the overall length of the route first.  
++
relative option

++      Use relative error.
++    

++Similar to the crosstrack method, but the error introduced by
++removing a point is set into relation to its associated horizontal accuracy,
++determined as 6m * HDOP. If there is timestamp information, the distance to the interpolated point between
++the two neighboring points is used instead of the distance to their connecting line.
++

++The effect of the relative method is similar to a combination of
++the crosstrack method with the discard filter: points are removed preserving the
++overall shape of the route (track), but preferably those that are unreliable.
++
Swap latitude and longitude of all loaded points (swap)

++   Simple filter to swap the coordinate values (latitude and longitude) of all
++   points. This can be helpful for wrong defined/coded data. Or if you think, you can use
++   one of our xcsv formats, but latitude and longitude are in opposite order.
++
Transform waypoints into a route, tracks into routes, ... (transform)

++  This filter can be used to convert GPS data between different data types.
++

++  Some GPS data formats support only some subset of waypoints, tracks,
++  and routes.  The transform filter allows you to convert between these
++  types.  For example, it can be used to convert a pile of waypoints (such
++  as those from a CSV file) into a track or vice versa.
++

++  The following example show you how to create a route from a waypoint table.
++
gpsbabel -i csv -f waypts.txt -x transform,rte=wpt -o gpx -F route.gpx

++  Only the first letter of option value decides which transformation will be done.
++  Depending on the used option it can be only 'W' for waypoints, 'R' for routes or
++  'T' for tracks.
++
wpt option

++      Transform track(s) or route(s) into waypoint(s) [R/T].
++    

++This option selects the destination type of this filter to be waypoints.  
++Choose this when you want to convert tracks or routes into waypoints.
++
Example 4.22. Converting a track to a sequence of waypoints

++Say you you have a KML file that contains a track but you want to convert it to a CSV file that can contain only waypoints, perhaps to import into a spreadsheet.  Use the following command:
++
gpsbabel -i kml -f blah.kml -x transform,wpt=trk -o csv -F blah.txt

rte option

++      Transform waypoint(s) or track(s) into route(s) [W/T].
++    

++This option selects the destination type of this filter to be routes.  Choose this when you want to convert tracks into waypoints routes.  A single route will be created in the sequence they appear in the input.
++
Example 4.23. Converting a pile of waypoints to a GPX route

++Say you you have a data file that came from CSV file that you want to convert  
++to a GPX route that can be loaded into Mapsource.  Use the following command:
++
gpsbabel -i csv -f blah.txt -x transform,rte=wpt -o gdb -F blah.gdb

trk option

++      Transform waypoint(s) or route(s) into tracks(s) [W/R].
++    

++This option selects the destination type of this filter to be tracks.  
++Choose this when you want to create tracks from a list of waypoints or routes. 
++A single track will be created in the sequence they appear in the input.
++
Example 4.24. Converting a pile of waypoints to a GPX track

++Say you you have a data file that came from CSV file that you want to convert  
++to a GPX track that can be loaded into Mapsource.  Use the following command:
++
gpsbabel -i csv -f blah.txt -x transform,trk=wpt -o gdb -F blah.gdb

rptdigits option

++      Number of digits in generated names.
++    

++This option lets you configure how many digits GPSBabel uses for numbering generated route point names.
++

++When GPSBabel creates route points during the transformation process these points are sequentially numbered and named "RPTxxx" where xxx represent the number. By default GPSBabel uses 3 digits for these numbers. Rationale: This way a large number of route points can be uniquely named while the generated names are limited to 6 characters. This limitation is imposed by specific GPS-devices.
++

++Using this option GPSBabel can be configured to use less or more digits for the generated names. This option is best used in conjunction with the rptname option.
++
Example 4.25. Convert a GPX track to a GPX route, deleting the original track, using 2 digits for the generated numbers.
gpsbabel -i gpx -f track.gpx -x transform,wpt=trk,del,rptdigits=2 -o gpx -F route.gpx

rptname option

++      Use source name for route point names.
++    

++With this option you can decide to let GPSBabel name generated route points according to their source track name.
++

++GPSBabel creates route points during the transformation process named "RPTxxx" where xxx is a numeric part.

++Using this option GPSBabel can be configured to replace the "RPT" part of the generated names by the name of the source track during the transformation process. This is especially usefull if several differently named tracks are contained in the source file which should each be transformed into routes.
++
Example 4.26. Convert a GPX track to a GPX route, deleting the original track, naming the generated points like the original track name.
gpsbabel -i gpx -f track.gpx -x transform,wpt=trk,del,rptname=y -o gpx -F route.gpx

del option

++      Delete source data after transformation.
++    

++This option, when used in connection with the wpt, rte, or trk options, tells
++GPSBabel to delete the source data after conversion.  This is most useful if 
++you are trying to avoid duplicated data in the output.
++
Example 4.27. Convert a GPX track to GPX waypoints, tossing the original track
gpsbabel -i gpx -f blah.gpx -x transform,wpt=trk,del -o gpx -F converted.gpx

Validate internal data structures (validate)

++  This filter can be used to check internal data structures for validity.  The output of the filter is identical to the input, but if corruption is found a fatal error will be issued.
++
checkempty option

++      Check for empty input.
++    

++This option will cause a fatal error if there are no waypoints, no route waypoints and no track waypoints, i.e. the reader didn't produce anything.
++
debug option

++      Output debug messages instead of possibly issuing a fatal error.
++    

++This option will output verbose messages reporting the state of the internal data structures holding waypoints, routes and tracks.  Detected problems will normally produce a fatal error, but with this option in effect no error will be thrown allowing continued processing. 
++
Appendix A. Supported Datums

++Some formats in GPSBabel support multiple datums.  For example, the 
++datum option to the 
++garmin_txt format allows you to specify
++a datum for the output file.  
++

++The following is a list of the datums supported by GPSBabel.
++
AdindanCuba NAD27La ReunionQornoq
AFGCyprusLiberia 1964Quatar National
Ain-El-AbdDjakarta(Batavia)LuzonRome 1940
Alaska-NAD27DOS 1968Mahe 1971S-42(Pulkovo1942)
Alaska-CanadaEaster lsland 1967Marco AstroS.E.Asia_(Indian)
Anna-1-AstroEgyptMasirah Is. NahrwanSAD-69/Brazil
ARC 1950 MeanEuropean 1950MassawaSanta Braz
ARC 1960 MeanEuropean 1950 meanMerchichSanto (DOS)
Asc Island 58European 1979 meanMexico NAD27Sapper Hill 43
Astro B4Finnish NauticalMidway Astro 61Schwarzeck
Astro Beacon EGandajika BaseMindanaoSicily
Astro pos 71/4Geodetic Datum 49MinnaSierra Leone 1960
Astro stn 52GhanaMontjong LoweS. Am. 1969 mean
Australia Geo 1984Greenland NAD27NahrwanSouth Asia
Bahamas NAD27Guam 1963Naparima BWISoutheast Base
Bellevue IGNGunung SegaraNorth America 83Southwest Base
Bermuda 1957Gunung Serindung 1962N. America 1927 meanTananarive Obs 25
Bukit RimpahGUX1 AstroObservatorio 1966Thai/Viet (Indian)
Camp_Area_AstroHerat NorthOld EgyptianTimbalai 1948
Campo_InchauspeHjorsey 1955Old Hawaiian_meanTokyo mean
Canada_Mean(NAD27)Hong Kong 1963Old Hawaiian KauaiTristan Astro 1968
Canal_Zone_(NAD27)Hu-Tzu-ShanOld Hawaiian MauiUnited Arab Emirates
Canton_Island_1966IndianOld Hawaiian OahuViti Levu 1916
CapeIranOmanWake Eniwetok 60
Cape_Canaveral_meanIreland 1965OSGB36WGS 72
Carribean NAD27ISTS 073 Astro 69Pico De Las NievesWGS 84
CarthageJohnston Island 61Pitcairn Astro 67Yacare
Cent America NAD27KandawalaS. Am. 1956 mean(P)Zanderij
Chatham 1971Kerguelen IslandS. Chilean 1963 (P)Sweden
Chua AstroKertau 48Puerto Rico 
Corrego AlegreL.C. 5 AstroPulkovo 1942 
Appendix B. Garmin Icons

++Following is a list of the valid values for the 
++garmin deficon option.
++These values are also used internally by the 
++GDB,
++BCR,
++Mapsource,
++PCX, and
++PSITrex 
++formats.
++
ATVContact, GlassesHunting AreaNumber 0, GreenScales
AirportContact, GoateeIce SkatingNumber 0, RedScenic Area
Amusement ParkContact, Kung-FuInformationNumber 1, BlueSchool
AnchorContact, PandaIntersectionNumber 1, GreenSeafood
Anchor ProhibitedContact, PigIntl freeway hwyNumber 1, RedSeaplane Base
Animal TracksContact, PirateIntl national hwyNumber 2, BlueShipwreck
Asian FoodContact, RangerItalian foodNumber 2, GreenShopping Center
Bait and TackleContact, SmileyLarge Ramp intersectionNumber 2, RedShort Tower
Ball ParkContact, SpikeLarge exit without servicesNumber 3, BlueShower
BankContact, SumoLetter A, BlueNumber 3, GreenSki Resort
BarControlled AreaLetter A, GreenNumber 3, RedSkiing Area
BeachConvenience StoreLetter A, RedNumber 4, BlueSkull and Crossbones
BeaconCoverLetter B, BlueNumber 4, GreenSmall City
BellCoveyLetter B, GreenNumber 4, RedSmall Game
Big GameCrossingLetter B, RedNumber 5, BlueSoft Field
Bike TrailDamLetter C, BlueNumber 5, GreenSquare, Blue
BlindDanger AreaLetter C, GreenNumber 5, RedSquare, Green
Block, BlueDeliLetter C, RedNumber 6, BlueSquare, Red
Block, GreenDepartment StoreLetter D, BlueNumber 6, GreenStadium
Block, RedDiamond, BlueLetter D, GreenNumber 6, RedState Hwy
Blood TrailDiamond, GreenLetter D, RedNumber 7, BlueSteak
Boat RampDiamond, RedLetterbox CacheNumber 7, GreenStreet Intersection
Border Crossing (Port Of Entry)Diver Down Flag 1LeveeNumber 7, RedStump
Bottom ConditionsDiver Down Flag 2LibraryNumber 8, BlueSummit
BowlingDockLightNumber 8, GreenSwimming Area
BridgeDot, WhiteLive TheaterNumber 8, RedTACAN
BuildingDrinking WaterLocalizer Outer MarkerNumber 9, BlueTall Tower
Buoy, WhiteDropoffLocationless (Reverse) CacheNumber 9, GreenTelephone
CampgroundElevation pointLodgeNumber 9, RedTide/Current PRediction Station
CarEvent CacheLodgingOil FieldToll Booth
Car RentalExitMan OverboardOpen 24 HoursTracBack Point
Car RepairExit without servicesMarinaOval, BlueTrail Head
CemeteryFast FoodMedical FacilityOval, GreenTree Stand
ChurchFirst approach fixMicro-CacheOval, RedTreed Quarry
Circle with XFishing AreaMile MarkerParachute AreaTriangle, Blue
Circle, BlueFishing Hot Spot FacilityMilitaryParkTriangle, Green
Circle, GreenFitness CenterMineParking AreaTriangle, Red
Circle, RedFlagMissed approach pointPharmacyTruck
City (Capitol)Flag, BlueMovie TheaterPicnic AreaTruck Stop
City (Large)Flag, GreenMulti-CachePin, BlueTunnel
City (Medium)Flag, RedMulti-CachePin, GreenU Marina
City (Small)Food SourceMuseumPin, RedU stump
City HallForestNavaid, AmberPizzaUS hwy
CivilFurbearerNavaid, BlackPolice StationUltralight Area
Coast GuardGambling/casinoNavaid, BluePost OfficeUnknown Cache
Contact, AfroGas StationNavaid, GreenPost OfficeUpland Game
Contact, AlienGeocacheNavaid, Green/RedPrivate FieldVHF Omni-range
Contact, Ball CapGeocache FoundNavaid, Green/WhitePuzzle CacheVOR-DME
Contact, Big EarsGeographic place name, Man-madeNavaid, OrangeRV ParkVOR/TACAN
Contact, BikerGeographic place name, landNavaid, RedRadio BeaconVirtual cache
Contact, BlondeGeographic place name, waterNavaid, Red/GreenRamp intersectionWater Hydrant
Contact, BugGhost TownNavaid, Red/WhiteRectangle, BlueWater Source
Contact, CatGlider AreaNavaid, VioletRectangle, GreenWaterfowl
Contact, ClownGolf CourseNavaid, WhiteRectangle, RedWaypoint
Contact, DogGround TransportationNavaid, White/GreenReefWebcam Cache
Contact, DreadlocksHeliportNavaid, White/RedResidenceWeed Bed
Contact, Female1HornNon-directional beaconRestaurantWinery
Contact, Female2HotelNullRestricted AreaWrecker
Contact, Female3HouseNumber 0, BlueRestroomZoo
Appendix C. GPSBabel XCSV Style Files
Table of Contents
Introduction to GPSBabel Styles
Style file overview
Internal Constants
Global Properties of the File
GPSBabel Behavior Directives
Defining the Layout of the File
Defining Fields Within the File
Examples
Miscellaneous Notes
Introduction to GPSBabel Styles

++Often it is desirable to add a new file format for "one-off" work (perhaps
++you want to export something to a spreadsheet or graphing program) or to read
++a format that GPSBabel does not yet support.   For suitably simple formats,
++this can be done by a user with no programming experience by providing a 
++GPSBabel style file.
++

++For a format to be described by a style file, it must be predictable and 
++generally readable by humant.  Formats with binary or unreadable content 
++are not good fits for this scheme.  It should have:
++
A fixed header at the beginning, if it has any at all. This is called a 'prologue'.
Waypoints that are grouped by fixed separators, often a newline.  In style file parlance, this is called a 'record'.
Traits of that waypoint described in that record.  In the style files, these are called 'fields' and examples may include longitude or a name.
Fields that are grouped by fixed separators, often a comma or a tab.  In the style files, this is called the field separator. Fields may be enclosed by characters, such as a double quote.
A fixed footer at the end, if it has any at all.  This is called the 'epilogue'.

++

++Once you have created a style file that describes the file format you have
++or want, you must tell GPSBabel to use the xcsv format and have the xcsv 
++format use that file.  If you created a new style file called 
++"mystyle.style" and you want to write the  waypoints from
++a GPX file named "mine.gpx" to it, you would issue a command like:
++
gpsbabel -i gpx -f mine.gpx -o xcsv,style=mystyle.style -F mine.new

++You might then examine mine.new to see if it met
++your expectations.  If not, you could continue to tweak 
++mystyle.style until it did, rerunning the above
++command each time.  If 'mystyle' is a format 
++that describes a popular program or is likely to be of use to others, you can
++then share mystyle.style with other GPSBabel users.
++Send it along with a coherent description to the GPSBabel-misc mailing 
++list for consideration to be included in a future version.
++
Style file overview

++The first and foremost important step is understanding how the style
++file is laid out itself.  The format is:
++
DIRECTIVE<whitespace>VALUE

++Where <whitespace> is one or more spaces or tabs.  There should
++be no spaces or tabs at the beginning of the line; all directives start
++at the left edge in column zero.
++

++An example style format is shown here:
++


++

++# Format: MS S&T 2002/2003

++# Author: Alex Mottram

++#   Date: 12/09/2002

++#

++

++DESCRIPTION 		Microsoft Streets and Trips 2002-2006

++EXTENSION               txt

++

++#

++# FILE LAYOUT DEFINITIIONS:

++#

++FIELD_DELIMITER		TAB

++RECORD_DELIMITER	NEWLINE

++BADCHARS		,"

++

++PROLOGUE	Name	Latitude	Longitude	Description	URL	Type	Container	Diff	Terr

++

++#

++# INDIVIDUAL DATA FIELDS, IN ORDER OF APPEARANCE:

++# NOTE: MS S&T ONLY IMPORTS DATA, IT DOESN'T 

++#       EXPORT THIS ANYWHERE SO WE CAN HAVE OUR 

++#       WAY WITH THE FORMATTING. 

++#

++IFIELD	SHORTNAME, "", "%s"		# Name

++IFIELD	LAT_DECIMAL, "", "%f"		# Latitude

++IFIELD	LON_DECIMAL, "", "%f"		# Longitude

++IFIELD	DESCRIPTION, "", "%s"		# Name 2 (Big Description)

++IFIELD	URL, "", "%s"			# URL

++IFIELD	GEOCACHE_TYPE, "", "%s"		# Geocache Type

++IFIELD	GEOCACHE_CONTAINER, "", "%s"	# Geocache Type

++IFIELD	GEOCACHE_DIFF, "", "%3.1f"	# Geocache Type

++IFIELD	GEOCACHE_TERR, "", "%3.1f"	# Geocache Type

++

++Each of these lines will be explained in the following sections.
++
Internal Constants

++A few internal constants are defined in the XCSV parser to make the style
++file simpler.  They may or may not be used and are optional in most cases. 
++Note that only certain style file directives map these constants.
++

++
Style ConstantMaps to Char(s)
COMMA,
COMMASPACE,<space>
SINGLEQUOTE'
DOUBLEQUOTE"
COLON:
SEMICOLON;
NEWLINE\n
CR\r
CRNEWLINE\r\n
TAB\t
SPACE<space>
HASH#
PIPE|
WHITESPACEsee below

++
WHITESPACE

++The WHITESPACE constant has special properties.  When reading data, 
++WHITESPACE refers to sequential runs of SPACES and/or TABS.  When
++writing data, WHITESPACE is always a single SPACE.
++

++For example, the following line:
++
SOME_NAME       30.1208 -91.1365    SOME OTHER NAME
++

++Parses into the following data fields: 
++
SOME_NAME,30.1208,-91.1365,SOME,OTHER,NAME
++
COMMENTS

++Anything after a hash (#) on a line is not parsed.  For example:
++
#THIS ENTIRE LINE IS A COMMENT.
++#FIELD	LAT_DECIMAL, "", "%f"   THIS ENTIRE LINE IS A COMMENT
++FIELD LAT_DECIMAL, "", "%f"  # ONLY THIS SENTENCE IS A COMMENT.
++
Global Properties of the File

++There are a few available directives to describe general traits of the 
++file being described and not specific data within the file itself.
++
DESCRIPTION

++This is the description of the file format being described. This text
++appears in the help screens and in menus used by the various GUI wrappers.
++
EXTENSION

++This directive gives the filename extension generally associated with
++this file.
++
ENCODING

++Describes the character set used by this format.  The value given
++must be one listed by 'gpsbabel -l'.    example:
++
   ENCODING          UTF-8	# Use UTF-8 for input and output.
++
DATUM

++This value specifies the GPS datum to be used on read or write. Valid values for this 
++option are listed in Appendix A, Supported Datums.
++
   DATUM             European 1950
++
DATATYPE

++Specifies the kind of data we have to read or write.
++

++By default all data are seen as waypoint data. With DATATYPE you are now able to bind
++a specific type to this format. Possible values are WAYPOINT, ROUTE or TRACK.
++
   DATATYPE          ROUTE # route-only format
++
GPSBabel Behavior Directives

++There are a few available directives to control some of the internal 
++processing functions of GPSbabel.
++
SHORTLEN

++   This sets the maximum allowed shortname length when using the internal
++   shortname synthesizer.
++

++   example:
++
   SHORTLEN	16	# shortnames will be at most 16 characters long.
++
SHORTWHITE

++   This tells the shortname synthesizer whether or not to allow whitespace
++   in the synthesized shortnames.  Allowed values are zero and one.
++

++   example:
++
   SHORTWHITE	0	# Do not allow whitespace in shortname.
++   SHORTWHITE   1	# Allow whitespace in shortname.
++
Defining the Layout of the File

++The first few directives define the layout the physical file itself:
++
FIELD_DELIMITER

++   The field delimiter defines the character(s) that separate the fields in 
++   the rows of data inside the XCSV file.  Common field delimiters are commas 
++   and tabs. (referred to as "comma separated values" and "tab separated 
++   values")
++

++   examples: 
++
   FIELD_DELIMITER    COMMA
++   FIELD_DELIMITER    ~
++

++   The directive FIELD_DELIMITER is parsed for STYLE CONSTANTS as defined in 
++   the table above.
++
FIELD_ENCLOSER

++   The field encloser defines the character(s) that surround the field values.
++   Common field enclosers are single and double quote marks. Many styles will
++   leave this directive unset. If set, it will be applied to all fields.
++

++   examples: 
++
   FIELD_ENCLOSER    DOUBLEQUOTE
++   FIELD_ENCLOSER    SINGLEQUOTE
++

++   The directive FIELD_ENCLOSER is parsed for STYLE CONSTANTS as defined in 
++   the table above.
++
RECORD_DELIMITER

++   The record delimiter defines that character(s) that separate ROWS of 
++   data (FIELDS) in the XCSV file.  The most common record delimiters
++   are NEWLINE and CR (carriage return).
++

++   examples:
++
   RECORD_DELIMITER    NEWLINE
++   RECORD_DELIMITER    |
++

++   The directive RECORD_DELIMITER is parsed for STYLE CONSTANTS as defined 
++   in the table above.
++
BADCHARS
   
++   Bad characters are things that should *never* be written into the XCSV
++   file as data on output.  GPSBabel automatically includes any non-blank
++   FIELD_DELIMITER and FIELD_ENCLOSER and RECORD_DELIMITER characters as
++   BADCHARS by default.
++

++   examples: 
++
  BADCHARS    COMMA
++  BADCHARS    ~|
++

++   The directive BADCHARS is parsed for STYLE CONSTANTS as defined in the 
++   table above.
++
PROLOGUE

++   A prologue is basically constant data that is written to the output
++   file BEFORE any waypoints are processed.  PROLOGUE can be defined 
++   multiple times in the style file, once for each "line" before the data 
++   begins.  This is commonly used in XCSV files as a "header" row.  
++

++   examples: 
++
  PROLOGUE	OziExplorer Waypoint File Version 1.1
++  PROLOGUE	WGS 84
++  PROLOGUE	Symbol,Name,Latitude,Longitude
++
EPILOGUE

++   An Epilogue is the same as a prologue, except this data is written at 
++   the END of the file.  See the examples for PROLOGUE above.
++
Defining Fields Within the File

++A field defines data.  There are two different classifications of FIELDS,
++IFIELD (file input) and OFIELD (file output).  In the absence of any OFIELDS,
++IFIELDS are use as both input and output.  The existence of OFIELDS is 
++primarily to allow more flexible mapping of GPSBabel data to output data 
++(say, for instance, to map the internal GPSBabel "description" variable to 
++two or more fields on output).  For all practical purposes, IFIELDS and 
++OFIELDS are defined the same way in the style file.
The following per-field options are defined:
++
  • 
++   "no_delim_before" is supported on in OFIELD tags to specify that this
++   field should be written without a field delimiter before it.  It's
++   useful for limited field concatenation.
++
  • 
++   "absolute" is supported on OFIELD tags for lat and lon to indicate
++   that only absolute values (never negative) are to be printed.
++
  • 
++   "optional" is supported only OFIELD tags and indicates that the
++   field may or may not be available in the source data.  If the
++   field is absent, no trailing field separator is written.
++
    
++   This attribute is most useful when paired with "no_delim_before" as
++   it allows you to concatenate fields without concern for whether those
++   fields are actually populated or not.
++

++There are several different types of fields that may be defined.  Each field 
++consists of three pieces of information: the FIELD TYPE, a DEFAULT VALUE, and 
++a PRINTF CONVERSION (for output).  In many cases, not all pieces are used,
++but all 3 pieces are required.   Additionally, an fourth field is supported
++that modifies the behaviour of the field being described.
++

++FIELDS should be defined in the style file in the logical order that they
++appear in the data, from left to right.  This is the order in which they are
++parsed from input and written to output.
++

++The fields used by the XCSV parser are as follows:
++
IGNORE

++   IGNORE fields are, guess what, ignored on input.   Internally, IGNORE 
++   fields are treated as CHARACTER data, and as such, require a printf 
++   conversion for a character array.  
++

++examples:
++
   IFIELD IGNORE,"","%14.14s"   # (writes a 14 character blank field)
++   IFIELD IGNORE,"","%s"        # (writes a blank field on output)
++
CONSTANT

++   CONSTANT fields are, of course, constant.  They are ignored on input, 
++   however they write CONSTANT data on output.  As such, they require a 
++   DEFAULT VALUE and a printf conversion for a character array. 
++

++examples:
++
   IFIELD CONSTANT,"FFFFFF","%s"   # (writes "FFFFFF" in the field)
++   IFIELD CONSTANT,"01/01/70","%s" # (a constant date field)
++
INDEX

++   An INDEX field is used ONLY on output.  The INDEX constant defines a field 
++   that, at output, contains the sequence number of the waypoint being 
++   written, starting at 0.  An index is managed internally as an INTEGER 
++   and requires an INTEGER printf conversion.  An INDEX has one special
++   property.  The DEFAULT VALUE of the index is added to the index 
++   on each iteration (to allow indexes starting at 1, 100, etc..).   
++

++examples:
++
   IFIELD INDEX,"0","%04d"     # (Starts counting at zero)
++   IFIELD INDEX,"","%04d"      # (Starts counting at zero)
++   IFIELD INDEX,"1","%04d"     # (Starts counting at one)
++
SHORTNAME

++   A SHORTNAME is generally the waypoint name of the data being processed.  
++   SHORTNAME maps directly to the GPSBabel variable ->shortname.  A SHORTNAME 
++   is CHARACTER data and requires a character array printf conversion.
++

++example:
++
   IFIELD SHORTNAME,"","%s"
++
DESCRIPTION

++   A DESCRIPTION is generally a long description of the waypoint.  A 
++   DESCRIPTION maps to the GPSBabel variable ->description and is otherwise 
++   handled exactly like a SHORTNAME.
++

++examples:
++
   IFIELD DESCRIPTION,"","%s" 
++
NOTES

++   NOTES are generally everything else about a waypoints. NOTES map to the 
++   GPSBabel variable ->notes and is otherwise handled exactly like a 
++   SHORTNAME.
++
URL

++   URL is a URL for the waypoint.  URL maps to the GPSBabel variable 
++   ->url and is otherwise handled exactly like a SHORTNAME.
++

++example:
++
   IFIELD URL,"","%s"
++
URL_LINK_TEXT

++   URL_LINK_TEXT is a textual description of where a URL points.  
++   URL_LINK_TEXT maps to the GPSBabel variable ->url_link_text and 
++   is otherwise handled exactly like a SHORTNAME.
++

++example:
++
   IFIELD URL_LINK_TEXT,"","%s" 
++
ICON_DESCR

++   ICON_DESCR is a textual description of an icon type for a waypoint.
++   ICON_DESCR maps to the GPSBabel variable ->icon_desc and is otherwise 
++   handled exactly like a SHORTNAME.
++

++example:
++
   IFIELD ICON_DESCR,"","%s" 
++
LAT_DECIMAL

++   LAT_DECIMAL defines LATITUDE in DECIMAL format.  Note that this is a PURE 
++   signed decimal format (i.e. -91.0000).  This data is handled internally as 
++   a DOUBLE PRECISION FLOAT and requires a FLOATING POINT printf conversion.
++

++example:
++
   IFIELD LAT_DECIMAL,"","%f"
++
LON_DECIMAL

++   See LAT_DECIMAL, except LON_DECIMAL defines LONGITUDE.
++
LAT_INT32DEG

++   LAT_INT32DEG defines LATITUDE in what I call INT32DEGREES.  This value is 
++   a signed LONG INTEGER and requires a LONG INTEGER printf conversion.
++   (This format is only used by some DeLorme products.)
++

++example:
++
   IFIELD LAT_INT32DEG,"","%ld"
++
LON_INT32DEG

++   See LON_INT32DEG except LON_INT32DEG defines LONGITUDE.
++
LAT_DECIMALDIR / LAT_DIRDECIMAL

++   LAT_DECIMALDIR and LAT_DIRDECIMAL  define LATITUDE in DECIMAL format 
++   with the added bonus of a 'N/S' or 'E/W' direction character.  This data 
++   is handled internally as a DOUBLE PRECISION FLOAT and a single 
++   CHARACTER and requires a FLOATING POINT as well as a CHARACTER printf 
++   conversion.  The only difference between the two is whether the directional
++   character appears before (LAT_DIRDECIMAL) or after (LAT_DECIMALDIR) the
++   decimal number.
++

++examples:
++
   IFIELD LAT_DECIMALDIR,"","%f %c"     #  (writes 31.333 N)
++   IFIELD LAT_DIRDECIMAL,"","%c %f"     #  (writes N 31.333)
++
LON_DECIMALDIR / LON_DIRDECIMAL

++   Same as LAT_DECIMALDIR / LAT_DIRDECIMAL except LON_ defines LONGITUDE.
++
LAT_DIR / LON_DIR

++   LAT_DIR returns the single character 'N' or 'S' depending on the 
++   hemisphere of the latitude.  LON_DIR returns 'E' or 'W' depending on
++   the hemisphere of the longitude.
++
LAT_HUMAN_READABLE

++   LAT_HUMAN_READABLE defines LATITUDE in a human-readable format.  This 
++   format is probably the most expressive format.  It is similar to 
++   LAT_DECIMALDIR in that it requires multiple printf conversions, but it
++   is far more flexible as to the contents of those conversions.  On read,
++   the printf conversions are ignored and GPSBabel attempts to determine the
++   latitude and longitude based on what is in the file.
++

++examples:
++
++   #  (writes N 31 40.000)
++   IFIELD LAT_HUMAN_READABLE,"","%c %d %f"   
++   #  (writes "31 deg 40.000 min N")
++   IFIELD LAT_HUMAN_READABLE,"","%d deg %f min %c"
++   #  Note that this string will confuse the reading routine due 
++   #  to the letter "n" in "min" and the letter "e" in "deg."
++   # (writes 31 40 00.000N)
++   IFIELD LAT_HUMAN_READABLE,"","%d %d %f%c" 
++
MAP_EN_BNG

++   MAP_EN_BNG converts coordinates from/to British National Grid (BNG).
++

++   The only supported order of the items is: Map,Easting,Northing.
++   During output all coordinates have to be located within this limited area.
++

++examples:
++
++   IFIELD MAP_EN_BNG,"","%s%5d %5d"   #  (writes i.e. "SJ00001 00001")
++   IFIELD MAP_EN_BNG,"","%s %d %d"    #  (writes i.e. "TQ 888 999")
++
LON_HUMAN_READABLE

++   See LAT_HUMAN_READABLE except LON_HUMAN_READABLE defines LONGITUDE.
++
LATLON_HUMAN_READABLE

++   LATLON_HUMAN_READABLE is like LAT_HUMAN_READABLE and LON_HUMAN_READABLE
++   except that it reads and writes both latitude and longitude as a single 
++   field.  On write, the same format specifier is used for both coordinates.
++   On read, GPSBabel does exactly the same thing it does for 
++   LAT_HUMAN_READABLE or LON_HUMAN_READABLE.
++

++example:
++
   IFIELD LATLON_HUMAN_READABLE,"","%c %d %f"
++           # (writes "N 31 40.126 W 85 09.62" as a single field)
++
LAT_NMEA

++   Defines the latitude in the format used by the NMEA standard which is
++   degrees multiplied by 100 plus decimal minutes.
++

++example:
++
   IFIELD  LAT_NMEA, "%f", "%08.3f"     # (writes  3558.322)
++
LAT_DDMMDIR

++Derived from the LAT_NMEA latitude format, with degrees * 100 plus decimal 
++minutes, but using an additional specifier to position the  'N' or 'S' instead of a leading minus sign (or 
++absence thereof) to give direction from zero.
++

++
 IFIELD LAT_DDMMDIR, "%f", "%08.3f%c" # (writes "5334.192S" giving -53.56987 degrees latitude)
++

++
LON_NMEA

++   Defines the longitude in the format used by the NMEA standard which is
++   degrees multiplied by 100 plus decimal minutes.
++

++Example:
++
   IFIELD  LON_NMEA, "%f", "%010.3f"  # (writes -08708.082)
++
LON_DDMMDIR

++Derived from the LON_NMEA longitude format, with degrees * 100 plus decimal minutes, but using an additional character format character to position the
++'E' or 'W' instead of a leading minus sign (or absence thereof) to give direction from zero.
++

++Example:
++
 IFIELD LON_DDMMDIR, "%f", "%010.3f%c" # (writes "01232.745W" giving -12.54575 degrees
++longitude)
++
LAT_10EX / LON_10EX

++   Defines the latitude or longitude in the format used i.e. by TomTom Navigator
++   itinerary files. It is degrees multiplied by 10 power X. X have to be replaced with
++   a valid decimal value. A factor of 10000 would be generated by LAT_10E5 as shown
++   in the examples below.
++

++examples:
++
   IFIELD  LAT_10E5, "%f", "%.f"       # (writes  3558322)
++
   IFIELD  LON_10E5, "%f", "%.f"       # (writes -8708082)
++
UTM
A location in UTM has several components: a zone, a northing, and an easting.   The UTM format specifier is the most common representation of these.
++
example: 
++IFIELD UTM, "", "%s" # writes 6S 519045 3984035  -the easting is first by convention.
UTM_EASTING
This is the decimal component representing the easting
++
example: 
++IFIELD UTM_EASTING, "", "%.0f"  # outputs 519045
++
UTM_NORTHING

++This is the decimal component representing the northing
++
example: 
++IFIELD UTM_NORTHING "", "%.0f"  # outputs 3984035
++
UTM_ZONE
The UTM zone.
++
example: 
++IFIELD UTM_ZONE "", "%d"  # outputs 6
++
UTM_ZONEC

++The UTM Zone character.
++
example: 
++IFIELD UTM_ZONEC "", "%c"  # outputs S
++

++The full UTM zone and latitude band.
++
example: 
++IFIELD UTM_ZONEF "", "%d%c"  # outputs 6S
++
ALT_FEET

++   ALT_FEET is the position's ALTITUDE in FEET.  This value is treated as 
++   a SIGNED DOUBLE PRECISION FLOAT and requires a FLOATING POINT printf 
++   conversion.
++

++example:
++
   IFIELD ALT_FEET,"","%.0f"
++
ALT_METERS

++   ALT_METERS is identical to ALT_FEET with the exception that the altitude
++   is in METERS.
++
HEART_RATE

++   Heart rate, measured in beats per minute.  Only valid for units with 
++   heart rate monitor features (i.e. Garmin Forerunner 301).
++

++example:
++
   IFIELD HEART_RATE,"","%d"
++
CADENCE

++   Cadence in revolutions per minute.  Only valid for units with 
++   heart rate monitor features (i.e. Garmin Edge 305).
++

++example:
++
   IFIELD CADENCE,"","%d"
++
POWER

++   Cycling power in Watts.  Only valid for units with power meter
++   features (i.e. Garmin Edge 305).
++

++example:
++
   IFIELD POWER,"","%.1f"
++
TEMPERATURE

++   Temperature in degrees Celsius.
++

++example:
++
   IFIELD TEMPERATURE,"","%.1f"
++
TEMPERATURE_F

++   Temperature in degrees Fahrenheit.
++

++example:
++
   IFIELD TEMPERATURE_F,"","%.1f"
++
EXCEL_TIME

++   EXCEL_TIME is the waypoint's creation time, if any.  This is actually
++   the decimal days since 1/1/1900 and is handled internally as a DOUBLE
++   PRECISION FLOAT and requires a FLOATING POINT printf conversion.
++

++example:
++
   IFIELD EXCEL_TIME,"","%11.5f"
++
TIMET_TIME

++   TIMET_TIME is the waypoint's creation time, if any.  This is actually
++   the integer seconds since 1/1/1970 (let's not start the holy war) and
++   is handled internally as a LONG INTEGER and requires a LONG INTEGER
++   printf conversion.
++

++example:
++
   IFIELD TIMET_TIME,"","%ld"
++
TIMET_TIME_MS

++   TIMET_TIME_MS is the same as TIMET_TIME, but expressed in milliseconds.
++   It too is handled internally as a LONG INTEGER and requires a LONG INTEGER
++   printf conversion.
++

++example:
++
   IFIELD TIMET_TIME_MS,"","%ld"
++
YYYYMMDD_TIME

++   YYYYMMDD_TIME is the waypoint's creation time, if any.  It's a single
++   decimal field containing four digits of year, two digits of month, 
++   and two digits of date.   Internally it is a LONG INTEGER and thus
++   requires a LONG INTEGER printf conversion.
++

++example:
++
   IFIELD YYYYMMDD_TIME,"","%ld"
++
GMT_TIME

++   GMT_TIME is the waypoint's creation time, in UTC time zone.  It uses the
++   strptime conversion format tags.  
++

++example:
++
   IFIELD GMT_TIME,"","%m/%d/%Y %I:%M:%D %p"
++

++   Search the web for 'strptime man page' for details strptime, but one 
++   such page can be found at
++http://www.die.net/doc/linux/man/man3/strptime.3.html
++
LOCAL_TIME

++ LOCAL_TIME is the waypoint's creation time, in the local
++ time zone.  It uses strptime conversion format tags.  See GMT_TIME for a
++ reference.
++

++example:
++
   IFIELD LOCAL_TIME,"","%y-%m-%d"
++
HMSG_TIME

++   HMSG_TIME parses up to three time parts and am/pm string to add
++   this value to the previously parsed *_TIME field that contains 
++   only a date.  On output, will print the time in UTC.
++

++example:
++
   IFIELD HMSG_TIME,"","%d:%d:%d %s"
++
HMSL_TIME

++   HMSG_TIME parses up to three time parts and am/pm string to add
++   this value to the previously parsed *_TIME field that contains 
++   only a date.  On output, will print the time in local time.
++

++example:
++
   IFIELD HMSL_TIME,"","%dh%dm"
++
ISO_TIME

++   ISO_TIME is the waypoint's creation time, in ISO 8601 format, 
++   which include time zone information. 
++   It is expected to be in the format yyyy-mm-ddThh:mm:sszzzzz
++   where zzzzzz is the local time offset or the character Z
++   for UTC time.
++   On output, UTC 'Z' time zone will always be used.
++

++example:
++
   IFIELD ISO_TIME,"","%s"
++
ISO_TIME_MS

++   ISO_TIME_MS is much like ISO_TIME, but expresses milliseconds at the
++   end of the timestamp.
++   It is thus in the format yyyy-mm-ddThh:mm:ss.SSSzzzzz
++   where 'SSS' is milliseconds and zzzzzz is the local time offset 
++   or the character Z for UTC time.
++   On output, UTC 'Z' time zone will always be used.
++

++example:
++
   IFIELD ISO_TIME_MS,"","%s"
++
NET_TIME

++  Microsoft dot net represents times in 100 nanoscond intervals since midnight
++  Jan 1/0001 GMT, giving absurdly large numbers like 633943150010000000 for 
++  mid-November, 2009.  NET_TIME is how to represent those in GPSBabel.
++

++example:
++
   IFIELD NET_TIME,"","%f"
++
GEOCACHE_DIFF

++   GEOCACHE_DIFF is valid only for geocaches and represents a DOUBLE 
++   PRECISION FLOAT.  This is the geocache "difficulty" rating as defined by
++   Groundspeak.  A "three and a half star" cache would therefore be "3.5"
++

++example:
++
   IFIELD GEOCACHE_DIFF,"","%3.1f"
++
GEOCACHE_TERR

++   GEOCACHE_TERR is valid only for geocaches and represents a DOUBLE 
++   PRECISION FLOAT.  This is the geocache "terrain" rating as defined
++   by Groundspeak.  A "three and a half star" cache would therefore be "3.5"
++

++example:
++
   IFIELD GEOCACHE_TERR,"","%3.1f"
++
GEOCACHE_CONTAINER

++   GEOCACHE_CONTAINER is valid only for geocaches and is heavily influenced
++   by the Groundspeak container types.   Examples would include "Micro" 
++   and "Virtual".
++

++example:
++
   GEOCACHE_CONTAINER,"","%s"
++
GEOCACHE_TYPE

++   GEOCACHE_TYPE is valid only for geocaches and is heavily influenced
++   by the Groundspeak cache types.   Examples would include "Event cache" 
++   and "Multi-Cache".
++

++example:
++
   GEOCACHE_TYPE,"","%s"
++
GEOCACHE_PLACER

++   GEOCACHE_PLACER is a string containing the name of the placer of a 
++   geocache.   
++

++example:
++
   GEOCACHE_PLACER,"","%s"
++
GEOCACHE_ISAVAILABLE

++   GEOCACHE_ISAVAILABLE is a string containing "True" or "False" 
++   indicating whether a geocache is currently available or not.  
++

++example:
++
   GEOCACHE_ISAVAILABLE,"","%s"
++
GEOCACHE_ISARCHIVED

++   GEOCACHE_ISARCHIVED is a string containing "True" or "False" 
++   indicating whether a geocache has been archived.   
++

++example:
++
   GEOCACHE_ISARCHIVED,"","%s"
++
GEOCACHE_LAST_FOUND

++   A long integer in format YYYYMMDD containing the last time this geocache
++   was found.
++

++example:
++
   GEOCACHE_LAST_FOUND,"","%ld"
++
GEOCACHE_HINT

++   The hint for this geocache.   No additional transformation (such as rot13)
++   will be performed on this string.
++

++example:
++
   GEOCACHE_HINT,"","%s"
++
PATH_DISTANCE_MILES

++   PATH_DISTANCE_MILES outputs the total length of the route or track from
++   the start point to the current point, in miles.  This and the altitude
++   could be used to create an elevation profile.  PATH_DISTANCE_MILES is
++   a DOUBLE PRECISION FLOAT.
++

++   PATH_DISTANCE_MILES is not valid as an input field.
++

++   PATH_DISTANCE_MILES is only meaningful if the data comes from a track
++   or a route; waypoint data will generate essentially meaningless output.
++

++example:
++
   PATH_DISTANCE_MILES,"","%f"
++
PATH_DISTANCE_KM

++   PATH_DISTANCE_KM is like PATH_DISTANCE_MILES except it outputs the 
++   length in kilometers. 
++
PATH_DISTANCE_METERS

++   PATH_DISTANCE_METERS is like PATH_DISTANCE_MILES except it outputs the 
++   length in meters. 
++
PATH_SPEED

++   Speed in meters per second. Gpsbabel does NOT calculate this data by 
++   default; it is read from the input file if present.  (If not present,
++   it may be calculated with the track
++   filter.)
++

++example:
++
   PATH_SPEED,"","%f"
++
PATH_SPEED_KPH

++   Like PATH_SPEED but means kilometers per hour.
++

++example:
++
   PATH_SPEED_KPH,"","%.1f"
++
PATH_SPEED_MPH

++   Like PATH_SPEED but means miles per hour.
++

++example:
++
   PATH_SPEED_MPH,"","%.1f"
++
PATH_SPEED_KNOTS

++   Like PATH_SPEED but means knots (nautical).
++

++example:
++
   PATH_SPEED_KNOTS,"","%.1f"
++
PATH_COURSE

++   Course in degrees.  Gpsbabel does not calculate this data by default; 
++   it is read from the input file if present.  (If not present, it may be
++   calculated with the track filter.)
++

++example:
++
   PATH_COURSE,"","%f"
++
GPS_HDOP / GPS_VDOP / GPS_PDOP

++   GPS horizontal / vertical / positional dilution of precision 
++   parameters. Needs float conversion.
++

++example:
++
   GPS_HDOP,"","%f"
++
GPS_SAT

++   Number of satellites used for determination of the position. Needs
++   integer conversion.
++

++example:
++
   GPS_SAT,"","%d"
++
GPS_FIX

++   Type of fix (see GPX spec or track
++filter). Needs string conversion.
++

++example:
++
   GPS_FIX,"","%s"
++
TRACK_NEW
If '1', it indicates that this trackpoint is the first point of a new track.  Needs integer conversion.
example:
IFIELD TRACK_NEW,"","%d"
TRACK_NAME
The name of the track currently being operated on.  Needs string conversion.
example:
TRACK_NAME, "", "%s"
ROUTE_NAME
The name of the route currently being operated on.  Needs string conversion.
example:
ROUTE_NAME, "", "%s"
STREET_ADDR
Street address including house number.  Notice that this is not used for any geocoding, it's merely textual description associated with a position.
example:
STREET_ADDR, "", "%s"
CITY
The name of a city. Sometimes part of "Points of Interest".   This is simple textual data associated with a position, no geocoding will be done..
example:
CITY, "", "%s"
COUNTRY
The name of a country associated with a position.
example:
COUNTRY, "", "%s"
FACILITY
The name of a facility to associate with a position.
example:
FACILITY, "", "%s"
PHONE_NR
A phone number associated with a position.  This is just textual data attached for convenience.
example:
PHONE_NR, "", "%s"
POSTAL_CODE
A postal code to associate with a position.  It is freeform text and is not used by GPSBabel for any geocoding or such.
example:
POSTAL_CODE, "", "%s"
FILENAME
The name of the input file from where the points were loaded. This field is available only on output.
example:
OFIELD FILENAME, "", "%s"
FORMAT
The name of the input format from where format the points came. This field is available only on output.
example:
OFIELD FORMAT, "", "%s"
Examples

++Here is one example style file from the GPSBabel source.
++


++# gpsbabel XCSV style file

++#

++# Format: Garmin POI

++# Author: Robert Lipe

++# Date: 10/07/2005

++# Reference: http://forums.groundspeak.com/GC/index.php?showtopic=110641&st=0&#entry1752204

++#

++DESCRIPTION Garmin POI database

++#

++#

++# FILE LAYOUT DEFINITIIONS:

++#

++FIELD_DELIMITER COMMA

++RECORD_DELIMITER NEWLINE

++BADCHARS COMMA

++SHORTLEN 24

++

++#

++# INDIVIDUAL DATA FIELDS, IN ORDER OF APPEARANCE:

++#

++IFIELD LON_HUMAN_READABLE, "", "%08.5f"

++IFIELD LAT_HUMAN_READABLE, "", "%08.5f"

++IFIELD SHORTNAME, "", "%s"

++IFIELD DESCRIPTION, "", "%s"

++

++OFIELD LON_DECIMAL, "", "%08.5f"

++OFIELD LAT_DECIMAL, "", "%08.5f"

++OFIELD SHORTNAME, "", "%-.24s"

++OFIELD GEOCACHE_TYPE, "", " %-.4s", "no_delim_before,optional"

++OFIELD GEOCACHE_CONTAINER, "", "/%-.4s ", "no_delim_before,optional"

++OFIELD GEOCACHE_DIFF, "", "(%3.1f", "no_delim_before,optional"

++OFIELD GEOCACHE_TERR, "", "/%3.1f)", "no_delim_before,optional"

++OFIELD DESCRIPTION, "", "%-.50s"

++

++When used on a Groundspeak Pocket Query, it will output lines that
++look like:
++


++-76.76234,38.39123,GC5370 Loca/Virt (1.0/1.0),Dude.. Wheres my Limo??

++-90.42345,38.55234,GCC8B Trad/Regu (2.0/2.0),Sweet Reward

++-90.81456,38.62456,GC3091 Trad/Regu (1.5/2.0),Matson Hill

++

++that are suitable for Garmin's POI loader.
++

++For additional examples, please see the 
++*.style files in the 
++style/ subdirectory of the GPSBabel source tree or at the online source..
++
Miscellaneous Notes
Default Values
   
++Default values are supported for any output fields that contain pure 
++   character data output such as URL and NOTES.  Default values are only
++   written on output and are not used to supplement missing input.  When 
++   using default values your mileage will vary greatly depending on the 
++   input formats used to populate waypoint data.
++
Glossary
Terms that are used in conjunction with GPSBabel.
G
Geocaching
GPS based "paper chase", see 
++          http://en.wikipedia.org/wiki/Geocaching
I
Itinerary
same as a Route (e.g. used by TomTom)
P
Points of Interest (POI)
a collection of gas stations, post boxes, shops and
++          like.
R
Route
a list of geopoints (often with names) connected in
++          a specific order. Usually a collection of geopoints
++          defining the route you want to pass while traveling,
++          created by PC software, or generated inside a GPS device.
++          They can be composed of existing waypoints, or new
++          "routepoints" might be generated.
T
Track
a collection of geopoints recorded by your GPS
++          device while traveling -- "breadcrumb trails". The order
++          of trackpoints within the track is important. Usually a
++          trackpoint doesn't have a name or comment, but a
++          timestamp. This distinguishes a trackpoint from a
++          waypoint.
W
Waypoints
are geopoints that are not necessarily connected to
++          other points, and their order is unimportant. They can be
++          entered before, while or after you actually visit the
++          place and might have tags like name, comment and the
++          like. Usually used to mark special locations as your
++          home, a hotel or a geocache.

+\ No newline at end of file
diff -Nru gpsbabel-1.7.0+ds/debian/patches/series gpsbabel-1.7.0+ds/debian/patches/series
--- gpsbabel-1.7.0+ds/debian/patches/series	2020-08-07 13:36:01.000000000 +0000
+++ gpsbabel-1.7.0+ds/debian/patches/series	2020-08-14 02:57:31.000000000 +0000
@@ -9,3 +9,4 @@
 0009-Drop-mac-libusb-libusb.h-dependency.patch
 618.patch
 620.patch
+auto-1.6.0+ds-3+rpi1-1edcf7f4aaa58679f27b343c3ef2291ab331699f-1564383990