Closed tsteven4 closed 10 months ago
gpsbabel -i gpx -f reference/track/gpx_subsecond-sample.gpx -o gpx -F x.gpx
produces trkpts like:
<trkpt lat="49.794688000" lon="9.834015000"> <ele>289.200</ele> <time>2011-07-02T17:47:25.200Z</time> <speed>13.818100</speed> <name>trkpt-2011-07-02T17:47:25.000Z</name> <fix>3d</fix> <type>T</type> </trkpt>
The gpx 1.0 schema requires the fix element to be after the type element:
<xsd:sequence> <!-- elements must appear in this order --> ... <xsd:element name="urlname" type="xsd:string" minOccurs="0"/> <xsd:element name="sym" type="xsd:string" minOccurs="0"/> <xsd:element name="type" type="xsd:string" minOccurs="0"/> <!-- Accuracy info --> <xsd:element name="fix" type="gpx:fixType" minOccurs="0"/> <xsd:element name="sat" type="xsd:nonNegativeInteger" minOccurs="0"/>
The type element is printed by fprint_xml_chain. This also violates the gpx 1.1 schema when using "-o gpx,gpxver=1.1"
fixed in #1191
gpsbabel -i gpx -f reference/track/gpx_subsecond-sample.gpx -o gpx -F x.gpx
produces trkpts like:
The gpx 1.0 schema requires the fix element to be after the type element:
The type element is printed by fprint_xml_chain. This also violates the gpx 1.1 schema when using "-o gpx,gpxver=1.1"