Re: [Gpsbabel-code] [Gpsbabel-misc] Gpsbabel and 1.4.2 and 1.4.4 incorrectly handling gpxtpx extens
Brought to you by:
robertl
From: Robert L. <rob...@gp...> - 2013-03-04 17:22:24
|
On Mon, Mar 4, 2013 at 8:25 AM, tsteven4 <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 |