Skip to content

Fail a GPX file whose times cannot be read, saying why - #935

Merged
caglarpir merged 3 commits into
mapillary:mainfrom
caglarpir:report-unreadable-gpx-times
Oct 27, 2026
Merged

caglarpir merged 3 commits into
mapillary:mainfrom
caglarpir:report-unreadable-gpx-times

Conversation

@caglarpir

Copy link
Copy Markdown
Contributor

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_limits called _is_video_stationary([]), which says True. v0.14.7 does the same.

Path Before After
process VIDEO --video_geotag_source gpx (and process_and_upload) MapillaryStationaryVideoError "Stationary video" MapillaryInvalidGPXError
video_process VIDEO OUT --geotag_source gpx MapillaryVideoGPSNotFoundError "No GPS points found" MapillaryInvalidGPXError
process IMAGES --geotag_source gpx MapillaryInvalidGPXError "No timestamped points found in the GPX file …" MapillaryInvalidGPXError, saying why
Half the times unreadable ready, 30 of 60 points left out silently ready, with a warning

The 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.000Z
  • X.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 read
  • once per file: Ignoring 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:

  1. The above.
  2. Backstop: a video that reaches the checks of process with no points fails as MapillaryVideoGPSNotFoundError "No GPS points found", not as stationary. This also covers an NMEA file without the date of any fix.
  3. "X.gpx is not a valid GPX file" gives gpxpy's reason, e.g. 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 for process of a video and of images, and for video_process. Also checked by hand with GPX files made from a dashcam video's own track, through process, video_process, process_and_upload --dry_run and process of images, and on sample videos and GPX files from many cameras.

@meta-cla meta-cla Bot added the cla signed label Oct 27, 2026
@caglarpir
caglarpir force-pushed the report-unreadable-gpx-times branch from 3c84c44 to 7126192 Compare October 27, 2026 12:16
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
caglarpir force-pushed the report-unreadable-gpx-times branch from 7126192 to 4be23c6 Compare October 27, 2026 12:32
@caglarpir
caglarpir merged commit 2c6ed71 into mapillary:main Oct 27, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant