Bad time format in gpx output

[mvglasow]

The time format in GPX output does not conform to the xsd_dateTime format since the time is represented as hhmmss rather than hh:mm:ss. Strangely, the first waypoint (and only the first) has the correct format but all the following have the faulty one. For example:

<trkseg>
<trkpt lat="45.495918" lon="9.112960">
	<time>2010-02-20T19:01:38Z</time>
	<course>0.0</course>
	<speed>0.00</speed>
	<extensions>
		<navit:profilename>car</navit:profilename>
	</extensions>
</trkpt>
<trkpt lat="45.495792" lon="9.112985">
	<time>2010-02-20T190148.052Z</time>
	<course>0.0</course>
	<speed>0.00</speed>
	<extensions>
		<navit:profilename>car</navit:profilename>
	</extensions>
</trkpt>
<trkpt lat="45.495892" lon="9.112880">
	<time>2010-02-20T190149.051Z</time>
	<course>0.0</course>
	<speed>0.00</speed>
	<extensions>
		<navit:profilename>car</navit:profilename>
	</extensions>
</trkpt>
<!-- remaining trkpts omitted -->
</trkseg>

The resulting GPX file will work for JOSM but, when uploading to OSM, only the first waypoint will get imported while the others will be rejected due to the bad <time> (OSM will report it as missing).

References: ​http://www.topografix.com/gpx/1/1/gpx.xsd ​http://books.xmlschemata.org/relaxng/ch19-77049.html

[mvglasow]

btw, build 2952 on WinCE (WM2003SE, Mitac Mio 168RS)

[mvglasow]

Some research into the code produced the following results:

vehicle.c contains the code for writing the log; the time-related part begins at line 450. If we cannot get attr_position_time_iso8601 from the vehicle (which is the case if we never had a fix), then the system time is used. Apparently this happened for the first trkpt. The code for transforming the system time formats it correctly, hence that trkpt gets valid data.

With the second trkpt apparently I had a fix and the time obtained from the GPS receiver was used (through attr_position_time_iso8601). This code is in vehicle_<source>.c, <source> being the GPS source. Here, vehicle_wince.c crudely returns the string from the NMEA message, the result of which we see in the following trkpts. I took a look at vehicle_android.c for curiosity, and here a correctly formatted string seems to get returned.

Looking further into the code to see if changing the wince code would possibly break anything else, I found that navit.c also reads attr_position_time_iso8601 and passes it to iso8601_to_secs() in util.c. That function seems to expect a correctly formatted string and will return garbage (read: a seemingly correct but numerically wrong) value if passed a timestamp without colons.

So I would conclude that navit internally expects the long iso8601 format (with colons); the short one will break a couple of things.

Patch to follow...

[mvglasow]

vehicle_wince.c diff

[mvglasow]

Here's the patch. Unfortunately I have no build environment yet, but if someone can build the wince version for me, I can test if that resolves the bug.

[mvglasow (2)]

User MBitter applied the patch (manually, as he claims the regular way did not work for him, but neither of us has tracked that down) and sent me the compiled EXE. I have since successfully used his compiled version to make tracks and upload them into OSM; now I'm just hoping to see that patch appear in the trunk build soon...

[kazer]

Patch applied in r3378 ​http://navit.svn.sourceforge.net/viewvc/navit?view=rev&revision=3378, thank you!