Repository navigation
Trust the GPS timestamps of a video, never its creation time - #939
Merged
Merged
Conversation
…file A GPX track that misses a file lets the later geotag sources take their turn. When none of them geotagged the file, the error reported was that of the last one to fail, which hid the miss. A video whose own GPS is too noisy, given a GPX of another day, failed as "GPS is too noisy": the very problem the GPX was given to work around. The Desktop Uploader, whose chain runs two GPX sources, exiftool_xml, native and exiftool_runtime, shows only that error. Report the miss instead: "The GPX track in X (...) misses the video Y (...) by 105.1 days. Check that the GPX file belongs to this video, ...". An error that ends the chain, such as "Stationary video", is still reported, as it says something about the file itself, and a file that a later source geotags still only gets the warning it gets now.
A video's GPS clock places a GPX track along it, and tells whether the track is of the same recording. Two things kept it from doing so: - A GoPro stamps a placeholder date until its GPS has the time, and a GPS rejected as noise may never get past it. Such a clock was told apart by the creation time of the video, which comes from the camera's own clock and can be anything. A noisy GPS whose clock disagreed with the creation time got any GPX synced from the start of the video, even one recorded months before (mapillary#858). - Only a leap of more than a day was taken for the GPS acquiring the time. Judge the timestamps alone. Leave out those before 2016 (the placeholder dates are 2000-01-01 and dates in October 2015) or more than a day in the future, and keep only those after the last leap of more than a minute ahead of the video. What is left is the GPS time, whether or not the positions were too noisy to publish, so it places the GPX, and a GPX of another time misses the video. The creation time is no longer read for that. When the clock has no timestamps, sampling looked for a start time in the GPS timestamps by rules of its own, which leave out only those before 2010. Now that the clock leaves out placeholder dates, that would bring them back, so it reads the same clock.
This was referenced Oct 28, 2026
caglarpir
added a commit
that referenced
this pull request
Oct 30, 2026
…940) This reverts the merge of #940 (3fcf6ca), back to main as it was after #939. #940 placed a GPX track along a video without GPS timestamps by the video's creation time. It was decided, after #940 was opened, that the creation time, which comes from the camera's clock, is never to be used to place a track: only a video's own GPS timestamps and its duration are. #944 handles videos without GPS timestamps that way instead, warning when the video and the track differ in length, and is stacked on #939, so it applies once #940 is reverted.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #938; review the last commit.
A video's GPS clock places a GPX track along it, and tells whether the track is of the same recording. Two things kept it from doing so:
Now the timestamps are judged alone. Those before 2016 (the placeholder dates are 2000-01-01 and dates in October 2015) or more than a day in the future are left out, and only those after the last leap of more than a minute ahead of the video are kept. What is left is the GPS time, whether or not the positions were too noisy to publish, so it places the GPX, and a GPX of another time misses the video. The creation time is no longer read for that.
When the clock has no timestamps, sampling looked for a start time in the GPS timestamps by rules of its own, which leave out only those before 2010. Now that the clock leaves out placeholder dates, that would bring them back, so it reads the same clock.
Checked against the GPS timestamps of 616 sample videos from many cameras: only three are affected by the new limits, all GoPro MAX videos whose clock shows a 2015 placeholder date, and none has a leap between a minute and a day. Unit and integration tests pass; also checked by hand through
processwith the Desktop Uploader's arguments.