Re: [Gpsbabel-code] [Gpsbabel-misc] Gpsbabel and 1.4.2 and 1.4.4 incorrectly handling gpxtpx extens
Brought to you by:
robertl
From: tsteven4 <tst...@gm...> - 2013-02-24 18:39:10
|
I fixed a number of little issues with the new gpx writer, but the case Angel is interested in still fails as it did in 1.4.4. To this point I have been concentrating on restoring missing functionality with the new gpx writer as opposed to fixing long standing bugs. We do have, and have had for some time, a conflict with unrecognized elements we attempt to pass through and the existing partial support for some recognized elements and their children, e.g. Garmin TrackPointExtensions. I can manually construct sample gpx files to test from the schema, but perhaps it would be better to have sample files from a real device. Can you provide short sample(s) containing elements form the Garmin extensions for test? It would be nice to have samples that demonstrate the Garmin WaypointExtensions, RouteExtensions, TrackExtensions and TrackPointExtensions. The TrackPointExtension in http://www8.garmin.com/xmlschemas/GpxExtensionsv3.xsd seems to have been replaced by http://www8.garmin.com/xmlschemas/TrackPointExtensionv1.xsd. Our existing code refers to the later schema for TrackPointExtensions and the former for the other extensions. Steve P.S. Robert, best wishes for a speedy and complete recovery. On 2/21/2013 11:12 PM, Robert Lipe wrote: > Moved to list instead of list administrator. PLEASE, people, quit > doing that. The list administrator is an audience of one that > doesn't have access to every configuration, sometimes travels, > sometimes disappears for a while without a lot of notice (I'm having > surgery to remove my Plantar Fascia and the associated Fibroma that's > residing on it in the morning, I can't personally support all the > many millions of GPSBabel users, etc....) > > We've always placed more effort in READING proprietary extensions over > writing proprietary extensions. Maybe that's a Stallman-like act of > passive aggression, but it just makes more sense to move your data OUT > of proprietary formats than to help put them in. But a case of > reading GPX, filtering, and then writing GPX doesn't really hold up to > that ethics test. The reality is that it looks like we've screwed up > the gpxtpx:TrackPointExtension and have *never* actually written it > correctly. Garmin's GPX (at least used to) change a lot from device > to device and from firmware rev to firmware rev and we really never > got on the treadmill of *which* garmin extensions were safe to use. > > Additionally, there's all kinds of stuff like > http://www8.garmin.com/xmlschemas/GpxExtensionsv3.xsd (which isn't > actually the XSD referenced in the sample file I have...) saying that > temperature is stored in a different tag for a trackpoint than a > waypoint (what!?!?!) and our writer just doesn't cope with that. > > It looks like Garmin as at least slowed down on cranking out the GPX > mutations, but the doc I'm looking at doesn't match the sample files > I'm looking at which, for example, contain hear rate. Our GPX writer > try to warp around Garmin extensions, but frankly, they do a poor job > of capturing the current versions via a combination of neglect and > just incompetence. I'm working on making the GPX writer WAY easier > to work on, but this is an area for someone that's meticulous about > staring at sample files, writing tests, and making largely mechanical > changes in gpx.cc to improve things. Any takers? For example, > there's a TrackPointExtension in > http://www8.garmin.com/xmlschemas/GpxExtensionsv3.xsd > > This would be a good area for someone with attention to detail, > willing to collect a few sample files to deterimine what's actually > relevant, and work through test cases, etc. could contribute a lot to > the project. The *code* isn't actually that hard and a partnership > between someone taking the time to figure out "yeah, they don't > actually discuss heart rate and cadence in the spec, but the following > market leading units spit them into trackpoints and waypoint" could > really help a code guy sling those bits. > > > I've made a horrible mess out of gpx.cc trying to make this work > better (I've succeeded in some ways, but failed in others, so I'm not > committing it) but I have to leave it for a while right now and I > should shift my focus to rearranging my body so I can walk effectively > again. > > If any of you are really interested in driving the state of our Garmin > Extensions writer - and you don't actually have to BE a coder, though > the ability to read code would help - this is an invitation to step > forward. > > > On Thu, Feb 21, 2013 at 5:07 AM, Angel J. Garcia Adeva > <ang...@eh... <mailto:ang...@eh...>> wrote: > > Hi all, > > I've noticed recently that gpsbabel behaves weird when dealing > with some > garmin extensions (heart rate in my case) in gpx files. Typically, > each > node in my input gpx file looks like this: > > <trkpt lat="42.86463333333333" lon="-2.7025183333333334"> > <ele>573.6</ele> > <time>2013-02-20T20:55:18.16</time> > <extensions> > <gpxtpx:TrackPointExtension> > <gpxtpx:hr>92</gpxtpx:hr> > </gpxtpx:TrackPointExtension> > </extensions> > </trkpt> > > Since my gps unit has a very high acquisition rate (that's a > matter for > another question to the forum some other day...), I usually filter > them > to get more manageable files. The command I use is: > > gpsbabel -i gpx -f input.gpx -x position,distance=1.5m -o gpx -F > output.gpx > > The problem is that the resulting node looks like this: > > <trkpt lat="42.864633333" lon="-2.702518333"> > <ele>573.600000</ele> > <time>2013-02-20T20:55:18.160Z</time> > <extensions> > <gpxtpx:TrackPointExtension> > 92 > </gpxtpx:TrackPointExtension> > </extensions> > </trkpt> > > I guess everybody notices the missing <gpxtpx:hr></gpxtpx:hr> pair > surrounding the heart rate extension. > > I have tried directly converting a gpx file into another gpx file > without any filtering and all the options of the gpx module that I > thought were relevant (garminextensions, gpxver, and even > humminbirdextensions); the result, unfortunately, is always the same. > > I'd really appreciate if anybody could shed some light on this issue. > > Thanks in advance. > > Best, > > Angel > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Gpsbabel-misc mailing list http://www.gpsbabel.org > Gps...@li... > <mailto:Gps...@li...> > To unsubscribe, change list options, or see archives, visit: > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > _______________________________________________ > Gpsbabel-code mailing list http://www.gpsbabel.org > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-code |