GPS data loaded from track log wildly inaccurate

Report · Oct 03, 2025

I was recently on a walking holiday in Tuscany, Italy. I took a lot of photos. I have an app, Geotag2 Pro, installed on my iPhone which logs times and GPS locations. When I got home I loaded the photos into Lightroom Classic (14.5.1 on macOS) and told Lightroom to apply the tracklog. To be fair the results were all in Tuscany, but all over the place. Photos taken a couple of minutes apart were miles apart on the map.

I contacted GeoTag support for advice and they told me to download their tagging app which I did and used on copies of my Tuscany photos. I then created a separate Lightroom Catalog with just those copies. The results were much, much better; there were a few anomolies but they could be explained by the way the Geotag 2 Pro works and if their logging app can't place a photo in a reasonable place in the time line, it doesn't do anything to it.

Has anyone else experienced this problem, or have any ideas for improving the situation? The Geotag logging app seems to work better but does involve an extra step and it takes a lot longer than using Apply Tracklog in Lightroom.

I'm looking forward to any feedback.

Jack

Report · Oct 03, 2025

What version NUMBER of MacOS?

Report · Oct 03, 2025

Ventura 13.7.8.

I've got an Intel iMac 2019 and I can't instal above Ventura.

Report · Oct 03, 2025

Sounds like @johnrellis is the person who might know the answer.

Report · Oct 03, 2025

"Photos taken a couple of minutes apart were miles apart on the map."

Many people, including me, use LR's Auto-Tag command to assign GPS coordinates to photos from GPX track logs, and I don't recall seeing any similar reports over the years. Normally, Auto-Tag uses smooth interpolation of a photo's position, using the track points immediately preceding and following the photo's capture time; so I wouldn't expect to see wild disparities in location for photos taken close together in time.

I think the most effective way to troubleshoot this is to share a GPX tracklog and a few of the photos that are getting placed incongruously. Maybe there's a LR bug lurking, or maybe there's some other explanation.

Report · Oct 04, 2025

I've attached some files. _DSC9546.NEF is a photo. Screenshot1 is the Lightroom map module showing where that photo has been placed by Apply Tracklog. The group of 3 locations above that is the Tuscany town of Radda in Chianti which is where these pictures belong. The location below with 27 photos is Siena which is where we were heading. Screenshot2 is the same as Screenshot1 with the photo correctly located. The tracklog is in the folder as well.

The link below is to a Dropbox folder.

https://www.dropbox.com/scl/fo/ivy5uf1mmzy6060zwv4h9/AF4AxBuj0FWCluAmFq5LVJc?rlkey=uj3togt3ohryheezp...

Report · Oct 04, 2025

Looked at this and you are dealing with a time zone offset issue. If you dial in a 6 hour offset in the tracklog in Lightroom it tags correctly. I think that the timezone is not set correctly in the gpx track file:  or the timezone is not set correctly in your camera.

Report · Oct 04, 2025

I live in the UK, we are currently in British Summer Time which is 1 hour earlier than GMT. when I travel to Italy I need to adjust my watch by 1 hour. Geotag 2 detects a change in time zone and warned me to check the time on the camera, and told me what time to set it to. There is no possibility of the camera, phone and computer having a discrepancy of 6 hours.

If it is as you say a time zone issue then it's with Lightroom. The Geotag2 desktop app applied the log correctly.

Report · Oct 04, 2025

The gpx file has times in UTC timecodes (that's the gpx standard). You can see the correct coordinates in the gpx file are between these two points:

On google maps that is these coordinates: https://www.google.com/maps/place/43%C2%B019'05.7%22N+11%C2%B019'46.1%22E/@43.318241,11.3268891,1125...

On the piazza San Giovanni right next to the Duomo Di Sienna.

The Raw file indicates it was taken on 2025-09-23T09:20:23.11 in the local timezone. You can see that that appears to be correct with the two points above, however the gpx file uses the UTC description (that's what the Z at the end of the timecodes means) so that actually makes the time 2 hours off in the file! Italy in summer is two hours difference from the UTC standard (UTC is basically GMT).

Was it 9:20 am local time when you took that picture? If so the coding in the gpx file is wrong indeed. If it was actually 11:20am when you shot the picture the time coding in the gpx file is correct.

I discovered where the 6 hours come from. That is the timezone on my computer which is in the UTC/GMT-6:00 timezone. So the offset for you is going to be different. The problem is that Lightroom assumes that when you import an image, it was taken in the timezone your computer is set to. So with the (apparently wrong timezone coding in the gpx file and the fact that I am in the USA Denver region, that results in a 6 hour offset. For you in Britain, it should be a 1 hour offset that you need to dial in.

So I think there are one and maybe two issues. One, the assumption that Lightroom makes that imported images are taken in the timezone set in your computer and two: the gpx might be incorrectly time coded (depending on what local time you actually shot the image).

The lightroom issue is unfortunately a long standing issue with timezone support in Lightroom. It is caused by the absence of any standard to record timezones in camera but terribly annoying for sure and the assumption that Lightroom makes is not necessarily bad in general but is terrible for anybody (like us both apparently) that travels a lot. Daylight savings time (or summer/winter time) complicates that even further. I constantly have to correct for timezones, summer/winter time and more as cameras are just not smart enough to deal with this correctly. They really should be recording time in the raw files in UTC format but no camera that I have does that. They all just put the time in in whatever you set in the clock. So had you imported the images while still in Italy, everything would be working fine (apart from the two hour error in the gpx file), but since you imported while in Britain, you got the timecode offset.

Report · Oct 04, 2025

And a further comment. I noticed that the gpx file contains nonstandard tags like this: . The  tag might indicate that it is offset by 7200 seconds which of course is two hours, which is the timezone offset in Italy vs UTC. So that is where the two hours offset is coming from I described above. The  is something that is not part of the gpx file standard that your geotagger app is doing. It should just write the times in UTC instead. Not sure why that app is doing that. None of the gpx files I have contain tags like that.

Report · Oct 04, 2025

I don't use time zones on my camera. I tried it a few years ago and loaded the pictures into Adobe Bridge, the result was chaotic (Bridge did have a bug at that time), but anyway I now set the camera to the local time when I go abroad. Whatever the time is in the picture would be when I took it, local time.

I'll pass your comments to Geotag 2 support and see what they have to say.

Thank you for your support. I think in future I'll use the Geotag 2 desktop app to add the GPS data to the photos before I load them into Lightroom, that seems to work correctly.

Thanks again.

Report · Oct 04, 2025

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

I don't agree with Jao's analysis. The issue is not caused by setting the wrong time-zone offset in the Map module. Rather, the capture time recorded in the photo doesn't match up with the track points in the track log where the photo was actually taken. Changing the track log's time-zone offset in the Map module won't assign the correct coordinates to the photo, since its capture time is about 23 hours 20 minutes later than the track points in the track log closest to the actual location.

Unless the camera's clock was set wrong by 23 hours 20 minutes, I don't know what accounts for this discrepancy. LR is operating correctly with this photo and track log.

* * *

Jack said the photo was taken at Radda in Chianti. Google Street View shows the photo was taken in Radda in Chianti at coordinates 43.4871447, 11.3756591:

https://www.google.com/maps/place/53017+Radda+in+Chianti+Province+of+Siena,+Italy/@43.4871447,11.375...

(This is much different than where Jao indicated in Siena.) The closest points in the track log to the Street View coordinates are:

Here's LR's Map showing that portion of the track log along with coordinates provided by Google Street View:

The two times displayed in Map by hovering over the track points are in the time zone of the computer running LR, which is BST = UTC+1 in this case. They correspond to the UTC times recorded for those points in the track log, 7:57:25Z and 8:03:26Z.

Italy is in Central European Summer Time (CEST, UTC+2), so those trackpoint date/times are:

2025:09:22 9:57:25 UTC+2

2025:09:22 10:03:26 UTC+2

The capture time recorded in the photo is 2025:09:23 09:20:23.11 (with no time zone recorded or used by LR). It is about 23 hours and 20 minutes later than the track points (CEST). This indicates the issue wasn't caused by setting the wrong day in the camera or picking the wrong hourly time-zone offset in the Map module.

* * *

When you invoke the Map module's Auto-Tag, it assumes the photo's capture time is in the time zone of the computer running LR. So when you apply Auto-Tag to the photo on a computer running in BST (UTC+1) , it assumes the photo was taken 2025:09:23 08:20:23 UTC.

The two closest track points to that date/time are:

LR (and most geotagging apps) use simple linear interpolation based on the times to estimate the coordinates. Here's an Excel table showing manually computed linear interpolation compared to the results produced by Auto-Tag -- they're nearly identical:

This demonstrates that Auto-Tag is producing the expected results for that photo and track log.

Report · Oct 04, 2025

I forgot to ask: What are the dates/times shown in LR for nearby photos in Radda in Chianti that had correctly assigned GPS coordinates?

Report · Oct 04, 2025

Great sleuthing John! It is quite funny that at the coordinates that are closest to the same date and time, you find a small square with parked cars behind a church so I didn't even question it or check street view. But yeah 23 hours and 20 minutes off is exactly right and Lightroom is doing the exact right assignments with that file and that gpx track. The issue is not caused by a timezone offset even though that is still something people should remember if you are auto-tagging in a different timezone than where you shot the images. So in this case, either the timecodes in the gpx file are completely wrong, or the camera's date and time was set completely wrong. I would suspect the camera must have been off as the gps app on the phone would normally get the correct date and time and timezone from the local cell tower and therefore should always have the correct date and time. It is weird though that the app Jack used to tag somehow does do the correct assignments even with this enormous time difference. That really should not be possible with that raw file and that gpx file. but perhaps it autoshifts the time when you give it a bunch of images at a time with the same timespan as the gpx track?

P.S. to Jack, the gpx track contains what is likely exactly your address in Glasgow. perhaps don't leave the file on dropbox or delete the points for October 3rd in the last two segments. These files are just xml text files that you can edit in any text editor. Just delete the last two track segments on October 3rd.

Report · Oct 05, 2025

Thanks guys

You advice and insights are much appreciated.

I can confirm the camera's clock was set at the correct local time in Tuscany, might be a couple of seconds out, no more.

The photo I sent you was taken in Radda at 9:20.

Why would Map module's Auto-Tag make any assumptions about when a photo was taken? It has a capture time on the camera and date / times on the gpx file, why doesn't it simply match the pair since both should be within the same time zone (if appropriate) and should be synched? It trying to adjust for the time on the computer doesn't make any sense, especially if no time zone is set on the camera.

Report · Oct 05, 2025

"The photo I sent you was taken in Radda at 9:20."

For the other photos taken in Radda that LR correctly located on the map, what does LR show in the Metadata panel for their full capture date/time?

Report · Oct 05, 2025

LR shows the capture times correctly in all cases.

Report · Oct 06, 2025

A big mistake on my part: Jao was wrong about the location of the photo but quite correct in his second instruction to set the tracklog time offset to 1 hour.

When you do that:

then LR's Auto-Tag correctly tags the location of the photo:

I misread the contents of the .gpx file for 2005:09:23. I apologize for the confusion.

The Geotag Photos Pro desktop app uses the method I described in option 1 above, assuming the camera clock was set to the time zone of the GPS track. The app also offers a Fix Camera Time command, which accomplishes the same end as LR's Set Tracklog Time Offset.

Report · Oct 05, 2025

"Why would Map module's Auto-Tag make any assumptions about when a photo was taken? It has a capture time on the camera and date / times on the gpx file, why doesn't it simply match the pair since both should be within the same time zone (if appropriate) and should be synched? It trying to adjust for the time on the computer doesn't make any sense, especially if no time zone is set on the camera."

Here are the issues to be considered:

- The GPX standard records times in UTC, not local time. (The time zones annotated in your .gpx file are non-standard.)

- As Jao discussed before, most non-phone cameras don't record time zones with the capture date/times.

- Many (most?) people forget to change their camera clocks when they travel, fixing the capture times when they import the photos into LR. I'm often geotagging my photos in LR based on a wearable GPS device, and I often forget to change my clock, so the capture times are often off (e.g. by 1 - 3 hours).

So to match a time-zone-less capture date/time in a photo with the UTC entries in a GPX track log, LR needs to know or guess the time zone of the camera's clock and/or be able to translate the UTC log entries to a time zone. Some options:

1. LR could assume the camera clock is properly set to local time where the photo was taken. It could use a well-maintained open-source package to translate the GPS coordinates in the track log to time zones and then translate the log's UTC times to local time. This is harder than you might think. The boundaries of time zones are often complicated, and the politically defined rules for daylight savings time (summer time) vary widely and change over the years. When the Map module was implemented over 15 years ago, the package had lots of errors in its data files. But it's gotten much better in recent years but it's still not 100% correct, especially in parts of the world that are popular with "world travelers".

With this method, a user who forgot to change their clock would get incorrect matches and might not notice immediately.

But another source of error would occur at time-zone boundaries. I've often driven across the boundary between MST (Utah) and PST (Nevada). If I'm taking photos on a road trip, a single track log could contain entries for 09:00 MST and 09:00 PST, separated by an hour of driving. Which should be used to match a time-zone-less camera time of 09:00? While a less-common edge case, people cross time zone boundaries all the time in some parts of the world. LR should handle this edge case gracefully.

2. After importing photos into LR, the user could give a Map module command to specify their time zone or to specify the time zones of the track log. This isn't much different than the Map module's Set Tracklog Time Offset.

3. (The current behavior) LR can assume the camera clock is in the same time zone as the computer running LR. This handles the most common case when the photos were taken in that time zone, and it handles the case when they were taken in another time zone but the user forgot to change the clock. But it obviously fails when the user travels, correctly changes the clock, and then imports the photos with the computer in another time zone.

The current behavior is far from ideal (and the documentation in the UI and the help is horrible), but it has the virtue of simplicity compared to option 1.

Report · Oct 05, 2025

Ok.

The app I use displays the iPhone time in big bold letters and instructs you to synchronize the camera with that. It's desktop app tags the photos correctly. In future I'll just use that before importing the photos into LR.

Report · Oct 04, 2025

I do this all the time with track logs created using Gaia GPS (excellent app unfortunately bought out by outside magazine so probably will not be excellent for much longer) and have never seen more than a few feet of inaccuracy simply caused by the accuracy of the GPS. What do these track logs look like? Are they perhaps far apart in time just sporadically taking points, or like normal track logs every 30 seconds or so. If far apart, the interpolation algorithm that is used will matter tremendously, whether it sticks to a coordinate in the track log that is closest in time (nearest neighbor interpolation) or does a linear interpolation between two track points straddling the image in time. If the track log is very sparse (a point only every 10 minutes for example), these two methods will give wildly different results. No clue what Lightroom does but I would be surprised if it wasn't an interpolation method.

Report · Oct 04, 2025

I use Geotag 2 Pro which I have configured to record a GPS location every minute and to treat anything within 50 yards of that as the same location. The app can create track logs which Lightroom can use. It also has a desktop app that will apply the GPS location directly to the photos. I downloaded the same photos as before and used the desktop app to apply the tracklog before creating a Lightroom catalog just for those photos. The results were far, far more accurate, some being out by the few feet as you described above.

This particular trip involved about 250 photos taken over a week, Lightroom applied the GPS data in a few seconds, the desktop app took a few minutes to do the same thing. I'm wondering if Lightroom works simply on the time and does not include the date, which I would agree would be a strange omission.

I used the tracklog within Lightroom several times already and the results have been fine, the differences this time is the number of photos involved and the trip was over a number of days and not just one.