Skip to main content
D
DerekB9544115
Participating Frequently
February 8, 2026
Question

Auto-tag selected photos to GPS track log not working correctly in 15.1.1

  • February 8, 2026
  • 7 replies
  • 68 views

First I will describe my normal workflow which has worked correctly for many years in previous versions of LR classic; then I will describe what has happened in 15.0 and in 15.1.1

Previous workflow:

  1.  Record GPS track log with my sports watch (Coros Apex) while taking photos. Sometimes two or three track logs are recorded on one day.
  2. in LR classic, Select all images taken that day 
  3. load a track log to the map module of LR classic
  4. Auto-tag selected photos
  5. The photos will be correctly distributed along the track log according to the capture time.  Photos that are not within the time of that track log will not be GPS tagged.
  6. load another track log from later that day and repeat the process.  Images taken later in the day will be correctly tagged to the second track log.

What happened in LR classic 15.0 and also after I updated to 15.1.1:

All the photos taken that day were tagged to the beginning of the track log, including some photos which were taken later in the day and should not have been tagged as their capture time was after the end of the selected track log.

    7 replies

    johnrellis
    johnrellis
    Genius
    February 10, 2026

    [View this post in your web browser. It contains formatting and images that don't appear in email.]

     

    ​@drtonyb When hovering over the track, a tooltip shows the time at that point. This time is not corrected by the Time Zone Offset. 

     

    I thought there was a bug report filed about this, but I can’t find it.  I only found this reference to that behavior from two years ago:

    I don’t have much experience yet with the new forum’s search for older content, so I don’t know if I’m hallucinating about an older bug report.


    Regardless, it’s annoying.  For the issue in this thread, I used the clunky Garmin Basecamp app to let me examine individual trackpoints displayed on the map.

    johnrellis
    johnrellis
    Genius
    February 9, 2026

    ​@Rikk Flohr_Photography, ​@Sameer K, I just submitted a long post explaining the Map module’s behavior observed in this thread, and forum says, “Your post has been submitted. It will be published after a review by our moderators.”

     

    Is there a process established for timely review of such posts?  Should we be splitting our posts up into bite-sized chunks to avoid this infelicity?

    Sameer K
    Community Manager
    Sameer KCommunity Manager
    Community Manager
    February 10, 2026

    Thanks for the tag. I couldn’t find anything pending for review. Is the message posted already? If yes, please share the link to your response, and I’ll share this with the team for review and possibly share what triggered the review from moderators. 

     

    Thanks!

    Sameer K

    johnrellis
    johnrellis
    Genius
    February 9, 2026

    [View this post in your web browser. It contains formatting and images that don't appear in email.]

     

    Welcome to tracklog hell.

     

    First, as ​@drtonyb astutely observed, the date on a track point in the middle of the .gpx jumps forward two days:

    <time>2026-02-06T19:23:22Z</time>
    <time>2026-02-08T19:23:00Z</time>
    <time>2026-02-06T19:23:24Z</time>

    That confuses LR, which assumes (not always correctly) that a log’s track points are in increasing order.  I deleted that track point from the log before proceeding.

     

    Second, LR’s handling of capture time and track logs is poorly designed and is very confusing when multiple time zones are involved.   

     

    LR assumes all photo capture times are in the time zone of the computer running LR, what I call “local time”.  If the photo includes a time zone in its metadata, LR ignores it. (This is a legacy of a poorly defined EXIF spec.)

     

    The times in track logs always include a time zone, most commonly “Z”, which indicates UTC. To compare photos’ capture times (in local time) with times in the track log, LR shifts the log times into local time’s time zone (the time zone of the computer’s clock) and then adds the offset specified by the Set Tracklog Time Offset command.

     

    Now let’s look at your example. Your camera’s clock was set to UTC time (time zone UTC+0).  (I inferred that by comparing track points in the log with the capture time of the photo on top of the peak.) (* See footnote below,)

     

    My computer is running California time (UTC-8), so by default LR will shift the times in the track log by -8 hours before comparing them with photos’ times. So I need to do Set Tracklog Time Offset to +8 hours to shift the track log times into the time zone of the camera’s clock (UTC+0).

     

    Then when I do Auto-Tag, LR correctly tags the first four photos:

     

    The fifth photo (of the tree) wasn’t tagged with a location because its capture time is 2026-02-07 05:05, outside the range of track-point times in the log (2026-02-06 19:18 through 2026-02-07 01:50).

     

    * Footnote: The photo metadata shows you set a time-zone setting in your camera of UTC+12 hours. This is recorded in the proprietary metadata field MakeNotes:TimeZone.  That setting didn’t change the capture time recorded in EXIF:DateTimeOriginal (when the shutter was pressed), but the camera did add 12 hours to EXIF:DateTimeDigitized (when the photo was rended in digital form) and EXIF:DateTime (when a photo app last changed the photo or its metadata).

     

    I don’t know why the camera didn’t add +12 to the capture time EXIF:DateTimeOriginal. But it was released in 2016, the same year that EXIF finally added time-zone support. Prior to then, camera manufacturers invented their own ways of handling time zone (and many still do).

     

    Here are those times as shown by Exiftool (which confusingly renames DateTimeDigitized to CreateDate and DateTime to ModifyDate):

    ======== Urchin Peak-20260207-5549.CR2
    [EXIF]       Date/Time Original : 2026:02:06 21:09:21
    [EXIF]       Create Date        : 2026:02:07 09:09:21
    [EXIF]       Modify Date        : 2026:02:07 09:09:21
    [MakerNotes] Time Zone          : +12:00
    ======== Urchin Peak-20260207-5554.CR2
    [EXIF]       Date/Time Original : 2026:02:06 21:21:43
    [EXIF]       Create Date        : 2026:02:07 09:21:43
    [EXIF]       Modify Date        : 2026:02:07 09:21:43
    [MakerNotes] Time Zone          : +12:00
    ======== Urchin Peak-20260207-5560.CR2
    [EXIF]       Date/Time Original : 2026:02:06 21:53:22
    [EXIF]       Create Date        : 2026:02:07 09:53:22
    [EXIF]       Modify Date        : 2026:02:07 09:53:22
    [MakerNotes] Time Zone          : +12:00
    ======== Urchin Peak-20260207-5578.CR2
    [EXIF]       Date/Time Original : 2026:02:06 23:27:23
    [EXIF]       Create Date        : 2026:02:07 11:27:23
    [EXIF]       Modify Date        : 2026:02:07 11:27:23
    [MakerNotes] Time Zone          : +12:00
    ======== Urchin Peak-20260207-5590.CR2
    [EXIF]       Date/Time Original : 2026:02:07 05:05:53
    [EXIF]       Create Date        : 2026:02:07 17:05:53
    [EXIF]       Modify Date        : 2026:02:07 17:05:53
    [MakerNotes] Time Zone          : +12:00

     

     

    D
    drtonyb
    Legend
    February 10, 2026

    ​@johnrellis 

     

    I am wondering if the user modified the DateTimeOriginal EXIF field in the CR2 file. I downloaded a CR2 file from another source and examined the timestamp fields; they were all the same, which I would assume is the local time when the photo was taken.

     

    John, I took a different approach to correct the problem. First I corrected the erroneous track point’s day and time from 2026-02-08T19:23:00Z to 2026-02-06T19:23:23Z since the point before is 2026-02-06T19:23:22Z and the point after is 2026-02-06T19:23:24Z (1 sec intervals). I then used LrC’s Metadata > Edit Capture Time… to shift the photos’ Date Time Original by +12 hours. Using Auto Tag then placed the first four photos correctly on the map. The fifth, as you also found, is not within the tracklog’s time period. Of course, Edit Capture Time only updates LrC’s metadata in the catalog, the incorrect DateTimeOriginal in the raw exif data remains unaffected.

     

    So I think this mystery is largely resolved: a user problem, not LrC.

     

    There is another long standing issue with the tracklog that is drawn on the map. When hovering over the track, a tooltip shows the time at that point. This time is not corrected by the Time Zone Offset. Here’s an example from the OP’s tracklog. I’m in time zone UTC+8, the OP’s time zone is UTC+12 with a further +1 for daylight saving time (which is not used in my TZ), so the Time Zone Offset I need to apply to the tracklog (UTC) times is +05:00. The first point in the tracklog is 2026-02-06T19:18:01Z, so LrC adds my time zone adjustment of +08:00 giving 2026-02-07 03:18:01, then the +05:00 offset I set gives the final start time 2026-02-07 08:18:01 (local NZDT). When I hover over the track’s starting point, the tooltip shows incorrectly 3:18:01 (my local AWST), as in this screen shot:

     

     

    Reported multiple times, never fixed. Given up.

    D
    drtonyb
    Legend
    February 10, 2026

    I have to make a correction. The photos supplied had Daylight Time turned off, so my Time Zone correction is +04:00, not +05:00.

    D
    DerekB9544115Author
    Participating Frequently
    February 9, 2026

    I am not sure what the problem was earlier.  I have deleted that track log and all the GPS data on all those images, then I did the same process again.  This time it has worked correctly as it always has done in the past.

    D
    DerekB9544115Author
    Participating Frequently
    February 9, 2026

    Thanks ​@johnrellis 

    Here is a link to the .gpx file and some photos which should have different GPS locations along the track log, but they are all in the same place.

    https://drive.google.com/drive/folders/1a9tlHTjXBMnYgpZVOil-AAlfhteIt68_?usp=share_link

    the final image Urchin Peak-20260207-5590.CR2 should not have any location data as it was taken after completion of the track log.  LR has incorrectly added it to the track log.

    D
    DerekB9544115Author
    Participating Frequently
    February 9, 2026

    I have also put the .xmp files in the same folder.  I am not sure if the GPS data is saved in the original RAW file or in the associated .xmp

    johnrellis
    johnrellis
    Genius
    February 9, 2026

    I’ve found over the years that the most efficient way to troubleshoot track log issues is to share the log and some sample photos -- otherwise, we waste too much time playing twenty questions. 

     

    So attach here a track log and a photo that’s not getting correctly tagged. f the forum won't let you attach the file here, upload it to Wetransfer, Dropbox, Google Drive or similar free service and post the sharing link here. 

      D
      drtonyb
      Legend
      February 9, 2026

      ​@DerekB9544115 

       

      I just tested a series of photos that I took while logging a track some years ago. The track loaded as expected in the Map module in LrC 15.1.1 with all photos placed correctly along the track.

       

      I suggest you check by reloading an older track log that you know worked in the past using LrC 15.1.1.

       

       

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices