dfandrich / gpscorrelate

C program to match GPS tracks to photographs, and store the matches in the EXIF data in the photographs.
https://dfandrich.github.io/gpscorrelate/
GNU General Public License v2.0
24 stars 8 forks source link

Make .gpx processing more robust against invalid data #27

Open reald opened 3 months ago

reald commented 3 months ago

Coming back from vacation I wanted to geotag a bunch of images with gpscorrelate. But this did not work correctly, for most of the pictures no fitting coordinate could be found.

I found out that the .gpx files of the GPS (Garmin Vista HCX) had some implausible dates in some points ("2043-10-"). The time itself seems to be correct for these points, also the coordinates seem not to be off.

$> grep -B 4 -A 4 "2043-" 2*.gpx

20240228.gpx-    <time>2024-02-28T14:13:50Z</time>
20240228.gpx-   </trkpt>
20240228.gpx-   <trkpt lat="27.808132" lon="-15.713051">
20240228.gpx-    <ele>66.530</ele>
20240228.gpx:    <time>2043-10-14T14:14:09Z</time>
20240228.gpx-   </trkpt>
20240228.gpx-   <trkpt lat="27.810196" lon="-15.726586">
20240228.gpx-    <ele>66.136</ele>
20240228.gpx-    <time>2024-02-28T14:14:24Z</time>

20240228.gpx-    <time>2024-02-28T14:14:55Z</time>
20240228.gpx-   </trkpt>
20240228.gpx-   <trkpt lat="27.810386" lon="-15.727208">
20240228.gpx-    <ele>90.530</ele>
20240228.gpx:    <time>2043-10-14T14:16:21Z</time>
20240228.gpx-   </trkpt>
20240228.gpx-   <trkpt lat="27.826851" lon="-15.746896">
20240228.gpx-    <ele>86.839</ele>
20240228.gpx-    <time>2024-02-28T14:16:31Z</time>

20240302.gpx-    <time>2024-03-02T10:44:30Z</time>
20240302.gpx-   </trkpt>
20240302.gpx-   <trkpt lat="28.106219" lon="-15.443543">
20240302.gpx-    <ele>109.693</ele>
20240302.gpx:    <time>2043-10-17T10:44:38Z</time>
20240302.gpx-   </trkpt>
20240302.gpx-   <trkpt lat="28.113640" lon="-15.441651">
20240302.gpx-    <ele>106.583</ele>
20240302.gpx-    <time>2024-03-02T10:44:41Z</time>

20240302.gpx-    <time>2024-03-02T13:47:07Z</time>
20240302.gpx-   </trkpt>
20240302.gpx-   <trkpt lat="28.112554" lon="-15.442249">
20240302.gpx-    <ele>154.720</ele>
20240302.gpx:    <time>2043-10-17T13:47:17Z</time>
20240302.gpx-   </trkpt>
20240302.gpx-   <trkpt lat="28.104386" lon="-15.443748">
20240302.gpx-    <ele>163.688</ele>
20240302.gpx-    <time>2024-03-02T13:47:21Z</time>

20240302.gpx-    <time>2024-03-02T13:58:23Z</time>
20240302.gpx-   </trkpt>
20240302.gpx-   <trkpt lat="28.060291" lon="-15.421636">
20240302.gpx-    <ele>78.632</ele>
20240302.gpx:    <time>2043-10-17T13:58:56Z</time>
20240302.gpx-   </trkpt>
20240302.gpx-   <trkpt lat="28.049973" lon="-15.419228">
20240302.gpx-    <ele>82.799</ele>
20240302.gpx-    <time>2024-03-02T13:58:59Z</time>

Although this does not make sense it seems to happen quite often. I suspect that gpscorrelate expects the points in a monotonic increasing order and the year 2034 outliers breaks the order. Please implement some filter and throw away the points that are not in an increasing order when reading the input gpx data.

dfandrich commented 3 months ago

Yes, it assumes dates to be sequential order. A GPX file does does not do that is malformed, so GIGO. It might be useful for gpscorrelate to check this and abort if it finds such a malformed input.