

  {extends file="main.tpl"}
    <!DOCTYPE head PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><head xmlns="http://www.w3.org/1999/xhtml">
  {block name=title}GPSBabel development:Route and Track Modes{/block}
  {block name=body}{literal}
                       
  <div xmlns="http://www.w3.org/1999/xhtml" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Route and Track Modes</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="Advanced_Usage.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Usage</th><td width="20%" align="right"> <a accesskey="n" href="inifile.html">Next</a></td></tr></table><hr /></div><div xmlns="http://www.w3.org/1999/xhtml" class="sect1"><div class="titlepage"><div><div><h2 class="title" ><a id="Route_And_Track_Modes"></a>Route and Track Modes</h2></div></div></div><p> Most formats supported by GPSBabel will make a reasonable attempt to work
         transparently with waypoints, tracks, and routes.  Some
         formats, like <a class="link" href="fmt_garmin.html" title="Garmin serial/USB protocol (garmin)">garmin</a> and <a class="link" href="fmt_magellan.html" title="Magellan SD files (as for Meridian) (magellan)">magellan</a> require the <em class="parameter"><code>-t</code></em> flag to work with tracks and
         <em class="parameter"><code>-r</code></em> to work with
         routes. <em class="parameter"><code>-w</code></em> 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:</p><p><strong class="userinput"><code> gpsbabel -t -r -w -i magellan -f com1:  -o gpx -F backup.gpx</code></strong></p><p> 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.</p><p> 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.
	 </p><p> 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.
</p><p> The presence of <em class="parameter"><code>-s</code></em> 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
         <em class="parameter"><code>-s</code></em> when tracks or
         routes are present.
</p></div><div xmlns="http://www.w3.org/1999/xhtml" class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="Advanced_Usage.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="Usage.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="inifile.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Advanced Usage </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Working with predefined options</td></tr></table></div>
  
      {/literal}{/block}
  