Location added to files outside GPX timeframe.

[klflv]

Sometimes last location of GPX track is added to files with timestamp outside the GPX track.

This happens if I add a bunch of files (let's say - all files from a day) but only a portion of them is from a hike (with recorded GPX). The files affected are at the end of list.

The red line in screenshot is after last file that falls inside the timeframe of GPX file.

[marchyman]

GeoTag uses a too simple heuristic to determine what is and isn't part of the track. That heuristic: if an image timestamp is within 6 hours of a track endpoint the image is assumed to be part of the track. Why 6? It was an arbitrary choice pulled out of thin air.

A workaround is to only select the images you know to be part of the track before applying locations from the track log.

Do you have any other ideas? I don't remember why it seemed important to include points close to but not in a track log. Perhaps I could change the 6 hours to something much less.

[klflv]

Yes, it makes sense that it can only tell if the image is taken on track by timestamp. And yes, the reasonable workaround would be importing images only that are part of the track.

My use scenario: I go for hikes or walks in the city (street photography) and track my routes with watch (for both sports tracking and location for images). And in the meantime I take other photos too. I import all images once every few days and once every 2-4 weeks go through them archiving and sorting. At this point it makes sense to get all the GPX files from this time and import with images to GeoTag and it would be much easier to do it with all files at once rather than going trough each GPX separately.

Solution would be to implement this time as a variable in program settings that defaults at 360 minutes for the sake of keeping everything as it is right now with an option to change it. Would it be complicated to do that?

[marchyman]

Something for my todo list. While I'm at it I'll probably reduce the 6 hours to maybe 2 or 3. Memory says I added the delay so pictures taken during a stop in my travels -- gps was on my motorcycle --- would be geolocated at least close to where I was. I'd fine tune the actual locations when necessary after assigning from the track log.

[marchyman]

Change is in the code but I've not yet updated the tests or the user doc. Anyway, it will be part of the next release, whenever that is.

[klflv]

Thank you very much for your work!

I now have an issue with building the project with these changes. Xcode gives error: No such module 'ExtendTimestampView'
From my near zero experience in xcode, it seems that something is left out of commit or push.

[marchyman]

Hmmm, not a git issue, but an "I forgot to remove an include for a file that never made it past the 'testing ideas' stage." The question is why did it compile in my machine? Did I test compile before removing the module?

Anyway, the change is on github. A fresh pull should fix the compile issue.

[alexwhittemore]

I've got what seems to be a different edge case of this: the way I record tracks (with Dawarich) basically goes dormant overnight when there's no movement, so I'll routinely have no points recorded between, say, midnight, and the next time I make a large movement i.e. when I leave in the morning, say at 9a. It seems to be that photos taken at 8a, then, don't get a matched location, despite being bounded on both sides by points in the track, and very geographically similar points at that. Increasing the "extend track timestamps" parameter even to 8 hours doesn't seem to capture these photos. I guess it only applies to the ENDS of the track, rather than generically "match the nearest point if it's within 'extend track timestamps'"?

I noticed in the release notes there was something about interpolation being removed as a feature at some point - is that related?

[marchyman]

Interpolation would not help in that situation. And you are correct. The search code looks for the last point in the list of tracks sorted by timestamp with a timestamp less than or equal to the image timestamp. Then the extendedTime adjustment is applied. To catch an 8 AM image when the previous track log ends at midnight would require a 8 hour extended timestamp, even if the next track log started at 8:05.

The extendedTime should apply to both ends of the track log. I'm re-opening this issue.

[alexwhittemore]

Oh! Well it seems the app is behaving exactly as you expect. My track has a gap from 23:22ish to 8:07ish.

The "problem" photos are in the morning, from 7:58 to 8:04, all coincidentally within the blackout and also coincidentally more than 8 hours after the most recent point in the track.

Personally I think "snap to the nearest point" makes equal sense regardless of whether that point is before or after the image.

The extendedTime should apply to both ends of the track log. I'm re-opening this issue.

Is that to say you agree with me that the fudge factor SHOULD apply both before and after the most proximal point even though right now it only applies after? Just trying to make sure I understand you right.

And generally, thanks a lot, your app makes my photo workflows much more convenient!

[marchyman]

Yes, the "fudge factor" should apply to both ends. The change looks to be easy -- setting up tests to verify the change is harder :)

That said, I'm in the middle of some extensive internal changes to the app and it may be quite a while before the change will make it into the released code.

[alexwhittemore]

I appreciate the expectations management :) As it is, the "make Extend Track Timestamps really big" workaround is totally fine. For what it's worth, I didn't know what that parameter meant (or what units it was in) until this discussion, so maybe there's room for improvement in the labels too when you do get the other changes out!