Thread: [Gpsbabel-code] gpx xml element attribute version mismatch bug
Brought to you by:
robertl
From: tsteven4 <tst...@qw...> - 2010-10-24 22:03:07
|
gpsbabel remembers the xsi_schema_location from a read and uses it on a write, but does not remember the gpx version. gpx.c has a comment: > /* > * Our handling of schemaLocation really is weird. > * If we see we have a "normal" GPX 1.1 header, on read, > * flip our default on write to use that and don't append > * it to the rest... > */ This can result in the xml element attributes version, xmlns and xsi:schemaLocation referencing different gpx versions. This can be demonstrated by converting a version 1.1 gpx file to gpx: gpsbabel -i gpx -f reference/expertgps.gpx -o gpx -F test.gpx The xml element of then input file, expertgps.gpx is > <gpx > version="1.1" > creator="ExpertGPS 1.3.7 - http://www.topografix.com" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="http://www.topografix.com/GPX/1/1" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd"> The xml element of the output file, test.gpx is > <gpx > version="1.0" > creator="GPSBabel - http://www.gpsbabel.org" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="http://www.topografix.com/GPX/1/0" > xsi:schemaLocation="http://www.topografix.com/GPX/1/1 > http://www.topografix.com/GPX/1/1/gpx.xsd"> Also, it appears the static variable gpx_version is never used. It is set in gpx.c and the related file garmin_device_xml.h. I realize that I could have forced the output version by using the gpxver option, i.e. gpsbabel -i gpx -f reference/expertgps.gpx -o gpx,gpxver="1.1" -F xx.gpx However, this would the user to know the input file gpx version. This test was run with code checked out today using Mac OS X 10.6.4. Is any bug tracking system other than this mailing list in use for gpsbabel? Best Regards, Steve |
From: Robert L. <rob...@gp...> - 2010-10-28 13:30:34
|
On Sun, Oct 24, 2010 at 5:03 PM, tsteven4 <tst...@qw...> wrote: > gpsbabel remembers the xsi_schema_location from a read and uses it on a > write, but does not remember the gpx version. gpx.c has a comment: > It reads schema loc to handle additional extension schemas. Version was to be triggered by the option on the GPX writer. This can result in the xml element attributes version, xmlns and > xsi:schemaLocation referencing different gpx versions. This can be > demonstrated by converting a version 1.1 gpx file to gpx: gpsbabel -i gpx -f reference/expertgps.gpx -o gpx -F test.gpx > Yes, converting 1.1 to 1.0 generally doesn't work. Also, it appears the static variable gpx_version is never used. It is set > in gpx.c and the related file garmin_device_xml.h. > It was an idea that I started but didn't finish. > I realize that I could have forced the output version by using the gpxver > option, i.e. > gpsbabel -i gpx -f reference/expertgps.gpx -o gpx,gpxver="1.1" -F xx.gpx > However, this would the user to know the input file gpx version. > In the wild, GPX 1.1 is still relatively rare, probably because of its incompatibilities with 1.0. The mixing of 1.0 and 1.1 is full of all kinds of hazards that I just don't have my head around. If you have merge files of different GPX versions and both use extensions (the extension scheme is different for 1.0 and 1.1) what's a sensible thing to output? Converting unknown extensions is problematic. Is any bug tracking system other than this mailing list in use for gpsbabel? > This is it. When we had a bug tracking system, it was consistently filled with nonsense. You've seen the consistently poor reports we get on the list; the bug tracker was far worse. RJL |
From: tsteven4 <tst...@qw...> - 2010-10-29 11:47:48
|
My preference would be to avoid unwanted conversions. If the user does not explicitly set an output version, and we know the input version, then we should use it. The bold row shows the difference from the current operation. This would require that we know if the gpxver option was specified or not, the value of gpx_wversion alone, which may have been supplied by the default, would not be sufficient. I am not sure if this information is available. input version requested output version output version unknown unspecified 1.0 unknown 1.0 1.0 unknown 1.1 1.1 1.0 unspecified 1.0 *1.1 * *unspecified * *1.1 * 1.0 1.1 1.1, problematic 1.1 1.0 1.0, problematic 1.0 1.0 1.0 1.1 1.1 1.1 mixed 1.0 1.0, problematic mixed 1.1 1.1, problematic mixed unspecified 1.0, problematic Steve On 10/28/10 7:30 AM, Robert Lipe wrote: > > > On Sun, Oct 24, 2010 at 5:03 PM, tsteven4 <tst...@qw... > <mailto:tst...@qw...>> wrote: > > gpsbabel remembers the xsi_schema_location from a read and uses it > on a write, but does not remember the gpx version. gpx.c has a > comment: > > > It reads schema loc to handle additional extension schemas. Version > was to be triggered by the option on the GPX writer. > > This can result in the xml element attributes version, xmlns and > xsi:schemaLocation referencing different gpx versions. This can > be demonstrated by converting a version 1.1 gpx file to gpx: > > > gpsbabel -i gpx -f reference/expertgps.gpx -o gpx -F test.gpx > > > Yes, converting 1.1 to 1.0 generally doesn't work. > > Also, it appears the static variable gpx_version is never used. > It is set in gpx.c and the related file garmin_device_xml.h. > > > It was an idea that I started but didn't finish. > > I realize that I could have forced the output version by using the > gpxver option, i.e. > gpsbabel -i gpx -f reference/expertgps.gpx -o gpx,gpxver="1.1" -F > xx.gpx > However, this would the user to know the input file gpx version. > > > In the wild, GPX 1.1 is still relatively rare, probably because of > its incompatibilities with 1.0. > > The mixing of 1.0 and 1.1 is full of all kinds of hazards that I just > don't have my head around. If you have merge files of different GPX > versions and both use extensions (the extension scheme is different > for 1.0 and 1.1) what's a sensible thing to output? Converting > unknown extensions is problematic. > > Is any bug tracking system other than this mailing list in use for > gpsbabel? > > > This is it. When we had a bug tracking system, it was consistently > filled with nonsense. You've seen the consistently poor reports we > get on the list; the bug tracker was far worse. > > RJL |