user definable time stamp threshold for gpx track log import

[akirot]

When attaching gps positions imported from a gpx track log apply the (interpolated) position only if the time difference between datetime created and (interpolated) gpx timestamp is less than a user definable threshold.
Do nothing (i.e. don't apply a position) if the threshold is exceeded.

This avoids applying totally wrong (interpolated) positions if there is a huge time difference between two logged positions.

See there:
https://www.photools.com/community/index.php?topic=12624.0

Mario once considered it there:
https://www.photools.com/community/index.php?topic=6521.msg45116#msg45116

[Carlo Didier]

+1

[Mario]

Do nothing (i.e. don't apply a position) if the threshold is exceeded.

This would mean that the track ends when this happens, correct? All other points after the 'time gap' would be discarded.
If you look around at a place for 10 minutes without taking a photo, then continue your hike and take photos again, these images would never be visible...this cannot be it?

[thrinn]

Do nothing (i.e. don't apply a position) if the threshold is exceeded.

This would mean that the track ends when this happens, correct? All other points after the 'time gap' would be discarded.
If you look around at a place for 10 minutes without taking a photo, then continue your hike and take photos again, these images would never be visible...this cannot be it?

The way I see it the intended behaviour is as follows:
Let's say we have a tracklog with two trackpoints at 15min intervals only: TP1 at 8:00, TP2 at 8:15. Let's also assume the threshold is set to 5min.
A picture taken at 8:05 would get an interpolated position (same as it is now) because it is near enough to TP1 (timestamp-wise, not location-wise).
A picture taken at 8:08 would not get a position because it has been taken more than 5min later than TP1 and more than 5min earlier that TP2.
A picture taken at 8:10 would get an interpolated position because it is near enough to TP2,  timestamp-wise.
A picture taken at 8:20 would get the position of TP2 because it has been taken only 5min later than TP2, and there is no further trackpoint available (no "interpolation" possible).
All pictures taken later than 8:20 (or earlier than 7:55) would not get any position because the time difference to all available trackpoints is too large.

Does this make sense?

[hluxem]

+1

[akirot]

thrinn describes the expected behavior perfectly - thank you!

This would mean that the track ends when this happens, correct? All other points after the 'time gap' would be discarded.

No - because the later points are valid ones.

Background: When e.g. moving through a deep canyon it is totally normal to lose satellite reception for a certain amount of time.

If you look around at a place for 10 minutes without taking a photo, then continue your hike and take photos again, these images would never be visible...this cannot be it?

Not necessarily - because there usually is a new position in the log as soon as I move.

If there is no new position:
I would be perfectly fine if IMatch did not assign a position when a certain threshold is exceeded. Not assigning a position identifies the images in question. I can assign a position manually.
A convenient mitigation would be an user adjustable threshold which I increase or decrease on demand thus speeding up the whole thing.

[Mario]

If not too much of a burden, please provide a sample track log file which has this problem, and also matching images (you can blacken the images if you like and resize them to 100 pixels).
If I look into this for potential included in the next major IMatch version, having some real-life data would be helpful.

[akirot]

Sorry, can't share für privacy reasons.

Simply take a gpx track log you already have,
delete lines of it to produce a gap (e.g. for half an hour),
try to assign images falling into this gap (timewise).

That will do the job.

[akirot]

I wonder if this should be split into a bug report plus a feature request.

The bug (ignored threshold):

There already should be a (hardcoded) threshold implemented - thus assigning positions only within the threshold.
If two subsequent satellite fixes are more than "two times threshold" apart there should no position be assigned for an image taken in between.
Clearly a position for an image should not be interpolated if two satellite fixes are e.g. 30 minutes apart and the image has been taken 15 minutes after the first of the two satellite fixes.

The feature request (user definable threshold):

The definition should not be implemented as a general option but as a variable value when assigning the positions (in the map panel). Thus a user can narrow down the position allocations by varying the threshold during different runs.

[Mario]

So far this seemed to have worked well. No bug reports, no complains AFAIK.

I always have to keep in mind that a problem a specific user encounters (and that may bother him big-time) may be a 'not a problem' for the rest of the user base:
- not many users work with separate track logs
- not many users have to deal with unreliable satellite connections
- many smart phones and modern cameras interpolate internally when they can't get a satellite lock, I believe
- if there is an occasional outlier, users just move the pin for the file in the Map Panel to a 'better' location

I'm definitely no GPS wiz and IMatch is not a specialized GPS application.
I plan to look into your request for IMatch 2022/2023, but that is all I can promise at this time.

Maybe, for your particular use case, using a specialized application like GeoSetter would be better?
GeoSetter persists coordinates in XMP and EXIF, and IMatch will pick them up automatically after GeoSetter has written them.

[akirot]

I'm a long term user of Geosetter.

Apparently it is not longer maintained/supported.

It perfectly did the job for me for many years.

But newer cameras aren't supported, neither newer/evolved metadata standards.
(It's not enough to update to the current Exiftool version.)

Nolens volens I had to switch to the IMatch map.
And there is room for improvement...

[Mario]

Among other small changes and enhancements for track log import I have added a user-defined threshold which determines the maximum +/- time difference between track points and file timestamps.

If the timestamp of a file does not fall within +/- threshold seconds, the track point is not considered a match for the file. Before, the 'nearest' track point was always used, independent on the actual time difference.

I have also improved and streamlined the track log import process, import settings can now be opened directly from the import dialog and via the <S> keyboard shortcut. Some minor bug fixes, user interface enhancements for smaller screens etc.

[akirot]

Thank you!!!!!!!!!!!!!!!!!!
This saved me/us a bug report!
(I just returned from a trip where a longer gpx log has a gap of more than one hour - and whilst moving I have taken photographs during this time. IMatch interpolated positions for this timeframe - which were all wrong. Better do nothing than something wrong.)
Again - thank you!