Nikon D700 + Nikkor 24-70mm f/2.8 @ 38mm — 1/200 sec, f/6.3, ISO 1800 — map & image data — nearby 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.
Thanks Jeffrey. You are right about Garmin’s software and UI. I have a similar but different issue with Virb Edit and G-Metrix from my Edge 800. I can import the data in Virb Edit (the latest version) but it doesn’t update in the video. It did work in a previous version of Virb Edit about a year ago showing that Garmin’s upgrade is more like a downgrade. Have you come across this issue before? Garmin Support are utterly incapable of even understanding the issue despite multiple emails, screenshots etc. All they do is send me a link to the Virb App which doesn’t work with the Virb Basic.
I don’t know what you mean by “doesn’t update in the video”, but I suspect the root of whatever issue you’re facing lies in your not fully realizing just how pathetic Garmin software engineers are (or, how brilliant they are, if you look at software as a tool to generate stress). It’s so frustrating to try to use their software that I gave up. Different aspects of the system treat timezones differently, so they get confused. And if you can sort that all out and want to apply the tracklog to a slew of 5-minute video files, you have to manually associate the tracklog to each video and manually position one frame to the tracklog. It’s just moronic. —Jeffrey
Well, I came here for regex info and snarky comments, and apparently you’re all out of regex info… so…
The issues with the data import requiring things in order are most likely because the guys (who originally put this stuff together for Garmin) were old school embedded control guys who cut their teeth before XML was a mainstream thing.
I’ll wager dollars to donuts that the importer basically used as a record delimiter,
read the next two lines, looked to see if ele and time were present and then stuffed them into whatever before seeking to the next sequence. if ele and time were not in order, fail!
In other words, it was never really meant to be an xml import parser- that’s way too much work.
I wrote code in that era, and in general no one worried about the difference between “looks like XML” and “is XML”, because under the hood we just turned it back into flat files and went about our business.
As with every protocol innovation, theory and practice take a while for people to grok.
Often, the guys writing the PC tools were no better than the guys writing the embedded stuff.
It’s way easier to grab a line and stuff it somewhere (with a die-if-wrong string error check) than to take an extra 20 minutes to sort things within records, and it’s almost 5PM and it’s late and it SEEMS to work. I mean really, who bothers to check for silly edge conditions or use external libraries in the closed source world?
Good software has been the exception rather than the rule for five decades.
Perhaps my presentation was messy, so to be clear let me say that I don’t fault Garmin for adhering to the spec. Garmin software is pathetic by most metrics, but in this respect I don’t fault them. I’m just surprised that the spec would be written like this, so part of me faults whoever wrote the spec, while at the same time I realize that there could be valid reasons that are just not apparent to me. But yeah, this particular issue aside, Garmin software is horrible. —Jeffrey