Saving Tracks in Mapsoure and Time diffs.

[+lakedawgs]

Hello,

I am trying to learn how to Geocode photos for a trip we are about to take. I am working with GPicSync.

Using my NUVI 750 or my 60C I will download the tracks to Mapsource (ver. 6.15.3) I can see the tracks and verify the time the track was recorded is correct. I then save the tracks as a GPX file for use with GPicSync and the time on the track points is off a few hours. I have verified this by looking at the GPX file in Notepad. I have also used EasyGPS to download and save my tracks and same thing.

 

What am I missing. My computer, GPS and camera are all synced to the same time. Time zone and DST are correct. It is not a problem with GPicSync because I have proved the error is there once I save the tracks to a GPX file, have not even used GPicSync yet (of course when I do I get a time error between the photo and the tracks)

 

Any help is appreciated.

Matt Anderson

Mr. Lakedawgs

[Ken in Regina]

Hi Matt,

 

I'm not sure I understand the issue so perhaps you can clarify.

 

Are you saying that when you check the timestamps on the trackpoints in Mapsource they are correct?

 

And then, when you save that track as a .GPX file and look in the .GPX file, the timestamps on the trackpoints are not wrong?

 

If so, how much are they off by? Is it the same offset from UTC as your "local" time zone? Eg. if you are on North American Central time your offset from UTC might be -6 hours.

 

...ken...

[Ken in Regina]

Okay, I just did a quick test and here's what's happening. Mapsource is saving the track file with the timestamps set to UTC. If you look at the timestamps in each entry in the .GPX file you will see a capital "Z" is the last character of each timestamp. That stands for "Zulu" which is just another way of indicating UTC.

 

I looked through Mapsource and I can't find any way to override that. I expect that's because the track files are created using UTC in the first place, so Mapsource is just saving the .GPX file to mirror the data as it already exists in the track file. When you view the timestamps in the Track Properties in Mapsource you are being fooled because Mapsource simply adjusts the display in the Track Properties to your local time zone setting on your PC (that's a Preference setting in Mapsource).

 

You can look in your geotagging program and see if you can tell it to make an adjustment. If you can, just set it to the same offset from UTC as the "local" time zone where the pics were taken.

 

...ken...

[+lakedawgs]

OK, I understand what you are saying.

I think there is a way to adjust in the Geotagging program. I will try that tonight.

The program gives me an error of about 4500 seconds (about an hour and 15 minutes) between the photo and the track points.

 

You have at least given me a place to start.

THANKS,

Matt

[Bob Morphew]

In GPicSync you need to specify the time offset from UTC so you could just try running it with only one or two pictures and your full GPX file. Look at the pictures on Google Earth and see if they are in the right location. Change the UTC offset until the pictures are correctly located then run the full batch of pictures.

 

I set the "Geocode if time difference is less than" to 2500 seconds to cover the case where my bike is parked for about 30 minutes while I wander around taking pictures, and the GPS is OFF. Usually the time difference is within a few seconds if I keep my GPS running.

 

BTW, you can re-run GPicSync several times and it just re-writes the GPS coords. I don't use the "Backup Pictures" option.

 

Bob

Edited March 19, 2009 by Bob Morphew

[+EScout]

Lakedawgs:

Your town is in EDT. IN GPicSync, use -4 hrs for the UTC offset, assuming your camera time is set to your local time (daylight savings time.) Or, you can set your camera time to UTC and not make an adjustment since GPSrs keep their track logs time in UTC.

 

If you are taking a car trip just keep your Nuvi turned on while driving, stopping and taking photos. You can also carry it with you on short hikes (change to offroad setting.)

 

You do not need to process your Nuvi track log file called "current.gpx." Just open it in GPicSync and you are ready to geotag. See my link below for my tutorial on using Nuvi track logs.

[Bob Morphew]

... since GPSrs keep their track logs time in UTC. ....

When I look at my tracklogs in Mapsource they are definitely in LOCAL time - not UTC. When I compare the trackpoint time/location with the JPG "Time Taken/Location" the times match.

 

Yet I understand that it makes a difference if you put the wrong UTC offset in GPicSync when Geocoding, so this suggests it needs to know hwo to match the JPG and the GPX times, but they seem to be the same.

 

Where exactly is the UTC time in the tracklog? My GPS knows my offset from UTC and it displays the correct local time.

 

Thanks

Bob

[Ken in Regina]

Hi Bob,

 

If you look back at my previous post you'll see that I already explained that.

 

In MapSource preferences you tell it how you want to view the time. You can either tell it to use the PC's internal setting (usually set to your local time zone) or you can force a specific offset from UTC. This is how MapSource will always display times.

 

That means, specifically, that you will never see UTC displayed in MapSource unless you set the time display preference to use an offset from UTC AND you set the offset to zero.

 

All of the above applies also to your GPS. It will display times as you tell it to. But it saves the timestamps in the tracklog as UTC.

 

Right now, you are viewing the Track Properties in MapSource and you are seeing MapSource display the timestamps exactly as you told it to .. in your case, probably defaulting to use your PC's time zone setting.

 

If you doubt this, look at the track log itself. Do not use MapSource to view Track Properties. If your device saves the tracklog in a GPX file you can view it with Notepad or whatever your favorite text editor is. You'll see that the time entries are all in UTC.

 

When you save a tracklog from MapSource to a GPX file, MapSource puts a "Z" as the last character in the timestamp to indicate that the time is "Zulu", or UTC.

 

...ken...

Edited March 20, 2009 by Ken in Regina

[+EScout]

Re post #7,

I had a reply, but I am editing it out because Ken said it better.

Edited March 20, 2009 by EScout

[+lakedawgs]

OK, I realized my mistake last night and you are right EScout. I made the foolish mistake of putting in -5UTC as opposed to -4UTC. We were -5UTC here in Indiana until we switched time zones last year.

 

GPicSync is working fine only problem I am having is I cannot seem to get the mapping to show up in Google Maps. I have confirmed that the pics and the kml file are in the right folder on the web, I just keep getting a 'file not found error by Google Maps when I paste the url into the search box.

http://www.lakedawgs.com/geocode2/geocode/doc-web.kml

Here is one of my test pics to confirm I have the address correct.

http://www.lakedawgs.com/geocode2/geocode/dsc02308.jpg

 

Any GPicSync users have this problem before. I have tried a couple of different syncs with the same results. Everything works fine in Flickr, but we want to use Google Maps for a Route 66 caching trip this summer.

http://www.flickr.com/photos/36413628@N07/...order_by=recent

 

Thanks to all,

Matt

[Bob Morphew]

Hi Bob, ... If you look back at my previous post you'll see that I already explained that. ....

I read your post when you first made it but it didn't sink in fully. After re-reading and going into Mapsource Preferences I see that I misunderstood the Time Options page as well.

 

I get it now .... eventually! Thanks for your patience in re-explaining it.

 

Bob

[Ken in Regina]

Hi Bob,

 

No problem. That is one of the hardest things for computer users to get our heads around .. that the data we see on the screen might not actually be the "real" data as it exists in a file on the computer. We have so many different preferences that we can set to tell the computer how we want things displayed. And very often we don't even know some of those preferences exist because the defaults usually are perfect for what we need.

 

Mostly it doesn't matter. But in cases like this it can really screw with our heads.

 

...ken...