gpxqgistime
When I import a GPX file in QGIS (as a vector as track points) and I check the time attribute it appears to be 4 hours later than it should be. Interestingly when I take this same GPX file and use GPSBabel to convert it to a CSV file I find that the time listed in the CSV is the correct time.
So am I doing something wrong or is this a bug in QGIS.
Thanks for the help.
David
ptrv/gpx2spatialite does this remarkably well, saving timestamps for all points and deriving speed and length data for tracks. It also won't import duplicate tracks, so you can feed it a huge pile for GPX files and it will munge them appropriately.
Update: usage examples, as requested:
Initialize new database:
gpx2spatialite_create_db db.sqlite
Add a single gpx file:
gpx2spatialite -d db.sqlite -u user file.gpx
(If username user does not exist in the database, will query if you wish to create it. The database is built with tracks/waypoints/routes assigned to one or more users.)
Add all of the gpx files in folder/:
gpx2spatialite -d db.sqlite -u user folder/
Usage: it's a spatial database, with table tracklines holding the tracks as polylines, trackpoints containing the individual points (with time, elevation, etc), and waypoints for any defined waypoints. There are also numerous indices, some world city definitions and possibly also embedded SLD styling information I haven't yet explored. As a trivial example, here's a map of how my hometown (Toronto) is defined through ~7 years of track logs:
By using lines at 75% transparency, the most frequently-travelled routes become darker.
Does it help to insert points into the way geometry?
Sometimes ways don't get rendered if all points of the way are outside the current window.
[EDIT 2] from user19425 I can't seem to add a separate comment, possibly because this is a closed question. But anyway thanks Joost, that worked. Are you aware if this is a tracked bug?
Best Answer
You can open the GPX file in a text editor.
Testing with my device, QGIS uses the same UTC format as written in the GPX file.
http://www.topografix.com/gpx_manual.asp#time
The universal CSV driver of GPSbabel is able to add the local UTC offset to the data. But this value is not from the GPS unit:
http://www.gpsbabel.org/htmldoc-development/fmt_unicsv.html
Playing around with GPSBabel and the timezone declared in my Windows system settings, GPSbabel must take this offset value from the OS, unless stated in the utc option explicitely. Daylight saving time is respected, looking at the date given with the time stamp, and not the current date.
Rather strange, and undocumented...