Living with a Garmin:

More GPX

Closer study of the GPX file format

The GPX format is a subset of XML. XML is a markup language and therefore simple in concept. 30 years ago, we were comfortable with word-processors where you typed [bold]bold[/bold] like this and [italic]italic[/italic] like this.
However somewhere along the way, the wrong people got involved and XML became very tricky to actually do right. A shame because it infiltrates much of modern computing, far and away from the narrow interest of GPS stuff. It is also a data-centric language and highly organised. So this would be good XML (in the right context):

Titles and Authors only exist in Books, and Books only exist in Bookshops.
This data-centric organisation is very apparent in GPX files.
Here's the meat of a very simple GPX file - NB I leave some headers and footers out for now -
(this was generated by Google Maps and GmapToGPX which is another very useful free tool):

It doesn't get much simpler than this. (It's just a fragment of course - the full file goes on for pages.)
Compared with the example above - Comments occur within Trackpoints, Trackpoints within Track Segments, Track Segments within Tracks.
You can see (even without looking at the Name) that it's a Track by observing that everything is wrapped in [trk] [/trk] tags.
You can see that each Trackpoint - apart from the first 2 - consists of a simple pair of co-ordinates, no more, no less.
The first two have (optional) Comment fields that can be displayed (optionally) in the GPS where and when appropriate.
The [trkseg] tags indicate that the enclosed [trkpt]s are to be treated consecutively, to form a continuous Track.
(Two or more [trkseg]s would indicate a broken track, due maybe to tree cover - but in fact at least 1 [trkseg] is always required, as a wrapper for the [trkpt]s.)
The whole is enclosed, with some header lines that I haven't shown here, in a pair of [gpx] tags and an [?xml] header, and the result is a file that Mapsource is completely happy with.

Here is the sort of thing that Bikely used to put out:
Note: fairly recently, Bikely has altered its output to a Track, see example further down here.

Still pretty simple. This time you can see its a Route. See the [rte] [/rte] wrapper tags?
See how, unlike the earlier example, each point has a Name. Programs often auto-name their points sequentially like this - so you have to watch out for that when loading multiple Routes into the GPS - the names sometimes need to be altered. (This is a job that GPSBabel can do.) (Name conflicts only occur with Waypoints - it is possible to load multiple Routes with identically-named Routepoints but most GPX conversions create a (somewhat spurious) set of Waypoints as well. If you strip out the [Wpt] sections - or simply take care not to load the Waypoints to the GPS - then you don't need to rename the Routepoints.)
In some files, there is all sorts of other information enclosed between the [rtept] wrappers, none of which is actually needed by the GPS, though some might be used if its there. Here. for example, the [ele] height information is spurious (even though it is true enough to say that a 'Point' should be defined by 3 co-ordinates, not 2).
The above Bikely file is not acceptable to Mapsource - but its nothing to do with the spurious information, which is not a problem - however Mapsource is sensitive to the orderin which these properties are presented in the script. Having Point name before elevation is what breaks the example above - this simple modification below - with no alteration to the headers - is completely acceptable to Mapsource:
(shorter version, elevations before names)

and so, in fact, is this (no names at all):

(Please remember all these examples so far omit certain essential header and wrapper information.)
To be fair, Mapsource was only being standards-compliant in rejecting the 1st version - however it has to be said that most other GPS programs are not so picky.
In any case, its all academic because Bikely now exports:

This is as you can see now a Track file and is acceptable to Mapsource as it stands (because, like the previous example, there are no Names before the [ele] tags for each Point).

Now, a quick glance at the much richer GPX that Mapsource itself generates - this is just 3 routepoints ...

All that spurious code - you can see why the GPS has limits on the number of waypoints!!

By way of contrast - how simple can a GPX file be, and still be viable?

Well - this simple, actually:

(This defines a point in a field just west of Buckingham.)
To be really pedantic, a 'point' like this without an elevation is assumed to be on the Earth's surface - a more strict definition of a point would require 3 coordinates - this is where the [ele] tags come in.

Bear in mind that none of the examples so far have included the necessary headers and wrappers that define it as a GPX file - perhaps its time to come clean and add these to the minimal code above -
this is the line above all wrapped up as a fully viable .gpx file:

This is all it takes to open in EasyGPS, or in Memory Map, and correctly place a Waypoint.
It won't open in Mapsource, nor in Bikely - but for two very different reasons.
Mapsource requires more header information and specifically 'namespace', 'creator' and 'version' defined in the [gpx] tag - this works:

Other variations in the [gpx] tag can be used with Mapsource, some work, some don't, Mapsource itself would create headers something like this:

To go back to our simple but viable complete file (reprinted from above):

The reason Bikely won't open this is simply because it doesn't deal in Waypoints - only in Routepoints or Trackpoints.
So although the example above won't work in Bikely, this next outrageous example which even naughtily omits the [xml] header, will work, because it is a single Routepoint as opposed to a Waypoint:

This 1-point 'Route' file displays like this in Bikely:

though Bikely would re-export it as this 1-point 'Track' with corrected headers:

So - enough of the headers and wrappers -
the three basic minimalist gpx layouts (for Waypoint, Route and Track) look like this:

Typically in practice, GPX files may include two or all three of the above, and a single file may include multiple Routes or Tracks provided each has a unique Name. Named Route or Track Points don't have to be unique at all - in theory at least - because they are after all non-essential attributes. In practice though, non-unique point names can sometimes cause difficulties - Mapsource has trouble with them, Bikely doesn't. Tracks can (and often do) include multiple Track Segments, which do not have to be named but are simply taken in sequence. At least one Segment is required, to contain the Track Points.

Since in practice Waypoints and Routepoints invariably have nested attributes (usually a Name, at the very least), the notation for each point needs to be expanded to allow these to be included -
This is the same Route again (middle of the 3 boxes above) with the more usual notation:

This is a line between two minor road junctions not far from the single Waypoint shown earlier.
1-point Route and Track files are fully viable, but I have shown minimal 2-point files above.

It is important to understand that both Routes and Tracks are interpreted in the order in which the points are listed in the gpx code - any Names, or Timestamps, are not used in any way to re-order the points.
Here are a couple of examples to illustrate this.
First up, 4 Points with sequential Timestamps and Names, joined as a Route (with the 1st Point re-used as a Start/Finish point - incidentally this is not a good idea in practice, the GPS can get very confused!):

Now I transpose the points H3 and H4 - the Route now goes H1-H2-H4-H3-H1:

Note the Timestamps and Names are both out of sequence but nevertheless, this Route will not go H2-H3 it will go H2-H4-H3. A Track file would behave in exactly the same way.
In Bikely:

Francis Cooke

Google Maps

Basic stuff:
Living with a Garmin: Etrex Basic Setup
Living with a Garmin: Battery Runtime and Etrex Jitter
Living with a Garmin: The Waypoints Limitation
Living with a Garmin: Declutter the Page Sequence
Living with a Garmin: Living with Metroguide Maps
Living with a Garmin: Waypoint Naming (for direct-style routes)
Living with a Garmin: Waypoint Naming and the Dakota 20
Living with a Garmin: Colour your Tracks and Routes
Top 5 GPS Tips (pdf) reprint of Arrivee article published Feb 2007
Some GPS FAQs web version of Arrivee article published Nov 2008
Dakota 20 review reprint of Arrivee article published Feb 2010
More Garmin essays - not-so-basic:
Living with a Garmin: Full Reset
Living with a Garmin: Track, Route or Autoroute
Living with a Garmin: Three Ways to Beat the Waypoint Limit
Living with a Garmin: Three Ways to Beat the Trackpoint Limit
Living with a Garmin: Less is More
Living with a Garmin: Add Contours to your GPS Maps
Living with a Garmin: Struggling with GPX  &...  More GPX
Living with a Garmin: Screens you don't see every day
Living with a Garmin: Downgrade your Mapsource
Living with a Garmin: Put an OSM Map on your Garmin
">Living with a Garmin: GPS Soak Test files to test your GPS waypoint capacity
OpenStreetMap and Mapsource Add OSM to your Mapsource collection
A Google Maps Workflow Create, Edit, Save, Share and Export a route