Getting Garmin Software (VIRB Edit, etc.) to Work with Your GPX Files
“  If the intercom doesn't seem to be working please push the bell  ” — detail of the front wall of this house — -- Kyoto, Japan -- Copyright 2008 Jeffrey Friedl, http://regex.info/blog/ -- This photo is licensed to the public under the Creative Commons Attribution-NonCommercial 4.0 International License http://creativecommons.org/licenses/by-nc/4.0/ (non-commercial use is freely allowed if proper attribution is given, including a link back to this page on http://regex.info/ when used online)
Nikon D700 + Nikkor 24-70mm f/2.8 @ 38mm — 1/200 sec, f/6.3, ISO 1800 — map & image datanearby photos
“  If the intercom doesn't seem to be working
please push the bell
 ”
— detail of the front wall of this house in Kyoto, Japan—

I've recently started futzing with video on my bike rides, having posted a few on Lovely Bicycle Ride Revisiting Uji Countryside Photographed Five Years Ago the other day, including this fast descent down some twisty mountains and into the flats.

I had some trouble getting Garmin software (VIRB Edit, Garmin BaseCamp, and Garmin Connect) to work with my GPX files, or as Garmin has lately taken to re-brand in their own silly name, G-Metrix data files.

When trying to import GPX files, I'd get a terse, frustrating Failed to read file or ... is not a valid GPX file and could not be opened message. After much experimenting I found that in each <trkpt> element, Garmin requires the <ele> to come before the <time>. Get anything out of order and it bails.

I ran a little script to ensure <ele> came first, and they were imported without complaint.

What's most shocking to me about this is that Garmin isn't wrong. I've been working with GPX files for more than a decade, and it never even occurred to me that the various order-can't-possibly-matter sup-parts of a <trkpt> might actually be required in a specific order, but inexplicably, that's how the GPX standard was written:

<xsd:sequence>
  <-- elements must appear in this order -->
  <xsd:element name="ele" type="xsd:decimal" minOccurs="0"/>
  <xsd:element name="time" type="xsd:dateTime" minOccurs="0"/>
</xsd:sequence>

This restriction on ordering seems utterly nonsensical... I'd guess it's because whoever created the standard was simply lazy as a software engineer. In any case, the standard is the standard.

It turns out that other artificial orders are mandated, such as the metadata summary requiring the author (if there is one) before the copyright (if there is one). I always thought that the GPX standard was a bit wonky as far as XML standards go, but this puts it into the decidedly bizarre category.

Anyway, as much as Garmin continues to deserve the world's ire for design in both hardware and software that pushes new limits in just how poor a user experience one can endure, in this issue they are technically not wrong. Yes, it'd be nice if they were generous in what they read, but I'm sure their own G-Matrix files are standard conforming, and considering that their software is free, working with their own stuff seems to be a reasonable lower bar.


Leave a comment...


All comments are invisible to others until Jeffrey approves them.

Please mention what part of the world you're writing from, if you don't mind. It's always interesting to see where people are visiting from.


You can use basic HTML; be sure to close tags properly.

Subscribe without commenting