Opened 13 years ago

Closed 12 years ago

#551 closed defect/bug (fixed)

Bad time format in gpx output

Reported by: mvglasow Owned by: kazer
Priority: major Milestone: version 0.2.0
Component: port/wince Version: git master
Severity: Keywords:


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:

<trkpt lat="45.495918" lon="9.112960">
<trkpt lat="45.495792" lon="9.112985">
<trkpt lat="45.495892" lon="9.112880">
<!-- remaining trkpts omitted -->

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).


Attachments (1)

vehicle_wince.diff (640 bytes) - added by mvglasow 13 years ago.
vehicle_wince.c diff

Download all attachments as: .zip

Change History (7)

comment:1 Changed 13 years ago by mvglasow

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

comment:2 Changed 13 years ago by 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...

Changed 13 years ago by mvglasow

vehicle_wince.c diff

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by kazer

  • Component changed from core to port/wince
  • Owner changed from KaZeR to kazer
  • Status changed from new to assigned

comment:5 Changed 13 years ago by 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...

comment:6 Changed 12 years ago by kazer

  • Milestone set to version 0.2.0
  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.