Repository navigation
Fail a GPX file whose times cannot be read, saying why - #935
Merged
Merged
Conversation
caglarpir
force-pushed
the
report-unreadable-gpx-times
branch
from
October 27, 2026 12:16
3c84c44 to
7126192
Compare
gpxpy reads no time for a track point whose time it cannot read, and says nothing of it. A GPX that writes its times with two fractions, as 2026-08-12T06:32:05.000.000Z, had all its points left out without a word: process and process_and_upload then failed the video as "Stationary video", video_process as "No GPS points found", and process failed images with "No timestamped points found in the GPX file", which gives no reason. A GPX whose track points have no <time>, or with only routes or waypoints, gave the same. With only some of its times unreadable, the other points geotagged the video, and the rest were left out silently. The GPX reader of videos and images now fails such a file with MapillaryInvalidGPXError, which says why: X.gpx has no track point with a time that can be read: '2026-08-12T06:32:05.000.000Z' is not a GPX time, which looks like 2026-08-12T06:32:05.000Z gpxpy keeps no raw text, so on this path only, the file is read again for the <time> of the track points that gpxpy cannot read. Without one, the message says that its track points have no <time>; a file without track points "has no track points; routes and waypoints are not read". When only some track points have a time that cannot be read, it warns once for each file, as it does of points before 1980: "Ignoring 30 of the 60 points in the GPX file X, whose times cannot be read (e.g. '...')". No time is guessed from the text: of 06:32:05.123.456Z, the second fraction could mean anything. Points without a <time>, which GPX allows, are still left out without a word: ExifTool writes one only on the points of a GoPro video that have a GPS time.
A video that reached the checks of process with no points failed as "Stationary video", as _is_video_stationary() says True of an empty track. Fail it with MapillaryVideoGPSNotFoundError, "No GPS points found", as video_process does, before the other checks. The previous commit fails the GPX files that gave such videos. This covers the other track files that can give no points, such as an NMEA file without the date of any fix.
A GPX file that gpxpy cannot parse failed with "X.gpx is not a valid GPX file. Replace it with a valid GPX file.", which does not say what is wrong with it: a GPX file cut short, as by an interrupted download, said only that. Add the reason that gpxpy, the decoding or the file system gives, as describe_invalid_nmea() does for NMEA files: "X.gpx is not a valid GPX file: Error parsing XML: no element found: line 6, column 85. Replace it with a valid GPX file." Videos and images give the same message.
caglarpir
force-pushed
the
report-unreadable-gpx-times
branch
from
October 27, 2026 12:32
7126192 to
4be23c6
Compare
This was referenced Oct 27, 2026
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 that writes its times with two fractions, as
2026-08-12T06:32:05.000.000Z, failed the video as "Stationary video". gpxpy reads no time for a track point whose time it cannot read, and says nothing of it; the GPX reader then left out every point without a time, and_check_video_limitscalled_is_video_stationary([]), which says True. v0.14.7 does the same.process VIDEO --video_geotag_source gpx(andprocess_and_upload)MapillaryStationaryVideoError"Stationary video"MapillaryInvalidGPXErrorvideo_process VIDEO OUT --geotag_source gpxMapillaryVideoGPSNotFoundError"No GPS points found"MapillaryInvalidGPXErrorprocess IMAGES --geotag_source gpxMapillaryInvalidGPXError"No timestamped points found in the GPX file …"MapillaryInvalidGPXError, saying whyThe messages:
X.gpx has no track point with a time that can be read: '2026-08-12T06:32:05.000.000Z' is not a GPX time, which looks like 2026-08-12T06:32:05.000ZX.gpx has no track point with a time that can be read: its track points have no <time>X.gpx has no track points; routes and waypoints are not readIgnoring 30 of the 60 points in the GPX file X, whose times cannot be read (e.g. '2026-08-12T06:32:06.000.000Z')gpxpy keeps no raw text, so on this path only, the file is read again, as XML, for the track point times that gpxpy rejects. No time is guessed from them. Track points without a
<time>are still left out without a word: GPX allows them, and ExifTool writes one only on the points of a GoPro video that have a GPS time.Commits:
processwith no points fails asMapillaryVideoGPSNotFoundError"No GPS points found", not as stationary. This also covers an NMEA file without the date of any fix.Error parsing XML: no element found: line 6, column 85; a GPX cut short said only "not a valid GPX file".Tests: unit tests for the two-fraction form, no
<time>, only routes or waypoints, half the times unreadable, a valid GPX and the before-1980 warning (both unchanged); integration tests forprocessof a video and of images, and forvideo_process. Also checked by hand with GPX files made from a dashcam video's own track, throughprocess,video_process,process_and_upload --dry_runandprocessof images, and on sample videos and GPX files from many cameras.