Lightroom: Geotag always placing photo on last location in track

  • 1
  • Problem
  • Updated 2 years ago
  • (Edited)
Every picture taken in a 3 week time span is always auto tagged to the last location in a track of a GPX file.
As a test I've manually trimmed some locations of the GPX file to make the latest location different and then the next latest location would be used for every picture, this is a horrible bug and should not be present in such software.
Photo of maurice ampt

maurice ampt

  • 5 Posts
  • 0 Reply Likes
  • frustrated

Posted 2 years ago

  • 1
Photo of Paul Plak

Paul Plak

  • 138 Posts
  • 19 Reply Likes
oh, glad I don't have any photo series to tag right now ... this is a nightmare when you have come back from a few days travel photography
Photo of maurice ampt

maurice ampt

  • 5 Posts
  • 0 Reply Likes
Imagine if it happens after three weeks of travel... Just be happy all you'll be doing is imagining, sadly, I am not...
Photo of John R. Ellis

John R. Ellis, Champion

  • 3697 Posts
  • 968 Reply Likes
This frequently happens when you're traveling in another time zone or your camera's clock wasn't set correctly. Since camera's typically don't record time zone in photos in a standard way, you need to use the Set Time Zone Offset command to tell LR how to match the time zone of the photos with the UTC (GMT) times that are recorded in the GPX track log.  See here for details on how to do that: https://helpx.adobe.com/lightroom/help/maps-module.html
Photo of lhiapgpeonk

lhiapgpeonk

  • 48 Posts
  • 4 Reply Likes
But the GPX trck log is interpreted as being set in your current time zone (computer time zone) So if you record a track in the UK in winter (UTC) and load the track later on in a Germany localized computer it will +1 all timestamps.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3697 Posts
  • 968 Reply Likes
Another way to think about it: Times in the track log are specified in UTC, but photos generally don't have any time zone. So LR always assumes that capture times are in the time zone of the computer running LR.  If that assumption is wrong, then you have to use the Set Time Zone Offset command.

This isn't a failing of LR, it's a failing of the EXIF standard to allow time zones to be optionally recorded by cameras.
Photo of lhiapgpeonk

lhiapgpeonk

  • 48 Posts
  • 4 Reply Likes
If the time zone offset is optional (in EXIF), why can't LR evaluate it when found? It has to parse different RAW formats differently anyway, hasn't it?
(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 3697 Posts
  • 968 Reply Likes
There are at least a couple of ways that some cameras optionally record time zone in metadata, none of which are widely used by manufacturers.  Given lack of standardized, widespread use, I'm guessing that Adobe wouldn't give this a high priority.

Some record it in an non-standard field in the EXIF section; but that field isn't universally applicable, since it is in units of whole hours, whereas 1.5 billion people live in time zones with offsets that aren't an integral number of hours. I think a few devices record capture time in a standardized field in the XMP section, which does allow for full time zones.

Another possible improvement would be to infer the local time zone from the track log.  The combination of UTC time plus a physical location can be used to determine the time zone and whether daylight savings time is in effect. (The world-wide definition of time zones is amazingly ill-documented and changes every year; but there is an open-source database that seems to be the most accurate available.)

But even if LR inferred the time zone correctly from the track log, LR would still see its Set Time Zone Offset command used frequently, since so many people forget to set their camera's clock to local time.   

Devices with built-in GPS (smartphones, etc.) typically also automatically update their clocks correctly. But the track-log time zone problem isn't an issue for these devices, since the GPS info is recorded directly in the metadata.
Photo of maurice ampt

maurice ampt

  • 5 Posts
  • 0 Reply Likes
Ah, yes, totally forgot to mention that, I did that as well, but it still doesn't work
And even if I didn't do that, then I'd expect them to be offset by 7 hours in my case and not that they all take the last entry. (over three weeks there is plenty of data to make it work even if I forgot to set the timezone.
Thank you for your response though, very valid remark!
Photo of John R. Ellis

John R. Ellis, Champion

  • 3697 Posts
  • 968 Reply Likes
If the track log is in reverse chronological order (e.g. one generated by at least one model of DeLorme Inreach), then LR will scrunch all of the photos to the end.  See this post for how to reverse the track log: https://forums.adobe.com/message/7852100#7852100. The GPX "standard", such as it is, doesn't really say much about the order of track points.

If that's not the issue, upload a track log and a sample pic to Dropbox (or similar) and post the sharing link here.  I can figure out what's going on and suggest a workaround.
Photo of maurice ampt

maurice ampt

  • 5 Posts
  • 0 Reply Likes
That might very well be the problem! Thanks.
I thought of that as a potential cause but I dismissed it thinking that it should be a standard...
I will try this tonight in about 12 hours and report back, thanks again for the reply!
Photo of maurice ampt

maurice ampt

  • 5 Posts
  • 0 Reply Likes
You are my hero John R. Ellis,
It was indeed the order of the GPS locations,
I had used GPSBabel to convert from Google's KML to GPX already, all I had to do was reverse the order using the filter option in GPSBabel and it worked!
Thanks a lot, but still a shame this poses a problem for a piece of software like this...