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-03-04 23:49:03
|
Robert, thanks for looking it over. > > FIXME: Although not required it seems > > ...required by whom/what? By the schema, i.e. GpxExtensionsv3.xsd, gpx.xsd (1.1), TrackPointExtensionv1.xsd. > Aren't you removing the very data you're trying to test here? I don't think the TrackPointExtensions element should be a child of the wpt element, I think it should only be a child of a trkpt element. The schema doesn't actually make this restriction, but it would seem like that was the intent from the name. There is heartrate and cadence data to test under some of the trkpts. Note that the hr and cad from the following wpt will NOT be recognized by the existing gpx reader, which is looking for /gpx/*trk/trkseg/trkpt*/extensions/gpxtpx:TrackPointExtension/gpxtpx:hr and /gpx/*trk/trkseg/trkpt*/extensions/gpxtpx:TrackPointExtension/gpxtpx:cad. Our code already assumes the assumption I want to make which was restated above. > <wpt lat="51.506172000" lon="-0.035187000"> > <ele>0.137000</ele> > <time>2008-08-20T07:04:48Z</time> > <name>LAP001</name> > <cmt>LAP001</cmt> > <desc>LAP001</desc> > <extensions> > <gpxtpx:TrackPointExtension> > <gpxtpx:hr>111</gpxtpx:hr> > <gpxtpx:cad>151</gpxtpx:cad> > </gpxtpx:TrackPointExtension> > </extensions> > </wpt> so with -o gpx,garminextensions these are going to get dropped. Without the reference change the test would fail. Steve On 3/4/2013 10:22 AM, Robert Lipe wrote: > > > > On Mon, Mar 4, 2013 at 8:25 AM, tsteven4 <tst...@gm... > <mailto:tst...@gm...>> wrote: > > Here is a proposed patch for review to help Angel. > > > Nice. > > To work it will require usage of the garminextensions option, i.e. > > gpsbabel -i gpx -f input.gpx -x position,distance=1.5m -o > gpx*,garminextensions* -F output.gpx > > It almost works without the garminextensions option but >> // FIXME: If we pass elements from an optional declared >> namespace, e.g. gpxx, gpxtpx, or h through with fprint_xml_chain, >> we won't have declared the namespace. >> // This is a schema violation. > > > At one time, I experimented with triggering garminextensions on output > if we saw the namespace decl on input. > > The gpx reader has difficulty with elements that are not passed > through who have parents that are. Previously the following > elements fell into this category: > gpxtpx:atemp > gpxtpx:hr > gpxtpx:cad > > > Those were definitely afterthoughts in our world. It doesn't surprise > me at all that they have bad side effects. > > i) the atemp/hr/cad data is placed in the waypoint by the reader > as it is today. This makes it available for writers without using > xml chains or garmin fs data. > > > Those are definitely elements that are useful to convert to/from other > formats, so keeping them out of Garmin-specific data makes sense. I > think power and depth also fall into that category, but let's chip > away at this. > > > FIXME: Although not required it seems > > ...required by whom/what? > > Index: reference/track/gpx_garmin_extensions.gpx > =================================================================== > --- reference/track/gpx_garmin_extensions.gpx (revision 4338) > +++ reference/track/gpx_garmin_extensions.gpx (working copy) > @@ -17,12 +17,6 @@ > <name>LAP001</name> > <cmt>LAP001</cmt> > <desc>LAP001</desc> > - <extensions> > - <gpxtpx:TrackPointExtension> > - <gpxtpx:hr>111</gpxtpx:hr> > - <gpxtpx:cad>151</gpxtpx:cad> > - </gpxtpx:TrackPointExtension> > - </extensions> > </wpt> > <trk> > <name>2008-08-20T07:04:47Z</name> > Aren't you removing the very data you're trying to test here? > > Overall, this looks good to me, Steve. With this in place, we can > turn our attention to removing the OLDGPX stuff. That should be a > process of visually inspecting the before and after hunks and ensuring > we've at least tried to deliver party. > > Thanx for tackling this. It was an icky problem. > > RJL |