Repository navigation
Report why a GPX track was not used when no other source geotags the file - #938
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.
caglarpir
added a commit
to caglarpir/mapillary_tools
that referenced
this pull request
Oct 30, 2026
- A track assumed to start with a video without GPS is never refused for its length, in process or in sampling, and the creation time is never used to place it: a MapillaryGPXAlignmentWarning says when the track and the video differ in length (mapillary#944). Only --interpolation_use_gpx_start_time still refuses a long track. - A file that a GPX or NMEA track missed fails with the miss when no later source geotags it (mapillary#938). - The process report lists the geotagging warnings (mapillary#945). - upload caches the checksums of the files, and shows progress while computing them (mapillary#942, mapillary#943).
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.
A GPX track that misses a video hands the video on to the next geotag source. When no later source geotagged it, the error reported was that of the last source to fail, which hid the miss. A GoPro 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
gpx,gpx,exiftool_xml,nativeandexiftool_runtime, shows only that error.MapillaryOutsideGPXTrackError, the missMapillaryStationaryVideoErrorThe error, for a noisy GoPro video given a GPX recorded months before:
The GPX track in GS018205.gpx (2026-05-29T12:47:06+00:00 to 2026-05-29T12:53:00+00:00) misses the video GS018205.360 (2026-09-11T15:39:40.599000+00:00 to 2026-09-11T15:39:56.099000+00:00) by 105.1 days. Check that the GPX file belongs to this video, then the camera clock and the time zone of the GPX timestampsTests: unit tests for the Desktop Uploader's chain, for each kind of later failure, for a later error that ends the chain, and for a later source that geotags the video. Also checked by hand through
processwith the Desktop Uploader's arguments, on a noisy GoPro video with a GPX of another day, of the same day 3 hours off, and of the video itself.First of three stacked PRs: this one, then #939 and #940. None of them touches README.md or docs/; the documentation follows in its own PR.