Geotag problem nmea vs gpx

[bob3bob3]

I have an interesting problem with geotagging of the "difference" between using an NMEA vs GPX file. Note that the GPX is generated from the NMEA data (with GPSBabel) which itself comes from a Ublox device and GPSD. I increased the Ublox rate rate to 5/sec.

Using exiftool 12.93

I am geotagging images for Mapillary use, so accuracy is kind of important. The image rate is 3FPS. The filename represents the time to millisecond accuracy.

The filename to date/time input
exiftool -P -overwrite_original  '-alldates<filename' '-SubSecTime*<${Basename;m/_(\d+$)/;$_=$1}' ./
No problem with that, it works well. Example filename - 20240723_005854_333.jpg

If I use NMEA thus;
TZ=utc exiftool -api GeoSpeedRef=k -overwrite_original -geotag=input.nmea -'geotime<Composite:SubSecDateTimeOriginal' ./
All of the GPS fields are properly written, including track and speed. The accuracy of the position though is "snapped" to a grid which makes tight curves very chunky. I haven't measured the grid, but would guess between 2 and 5 metres.

If I use GPX thus;
TZ=utc exiftool -api GeoSpeedRef=k -overwrite_original -geotag=input.gpx -'geotime<Composite:SubSecDateTimeOriginal' ./
It doesn't write the GPS speed EXIF despite the speed appearing in the GPX file. In addition the GPS Track gets "renamed" such that the following would be the fix;
exiftool '-GPSTrack<GPSImgDirection' -overwrite_original ./
exiftool '-GPSTrackRef<GPSImgDirectionRef' -overwrite_original ./
exiftool -GPSImgDirection= -overwrite_original ./
exiftool -GPSImgDirectionRef= -overwrite_original ./
The accuracy no longer snaps to a grid so curves are quiet smooth.

Ideally I'd like to just fix the grid snap NMEA mode. I am hoping of there is some parameter to add to the command line that will do that.

Tnx Bob

[Phil Harvey]

Hi Bob,

There is no difference in ExifTool's calculation method between these two types of input files.

I'm thinking the "chunky" problem is likely that NMEA doesn't support fractional seconds as far as I am aware.  Are these synthesized by gpsbabel?

Regarding the GPSTrack/GPSImgDirection problem, it sounds like GPSBabel is writing this direction to "course", which some drones use to represent the yaw direction of the device, so ExifTool writes this to GPSImgDirection.  I checked the GPX 1.1 specification and can't find any standard property which would represent this direction.  Is this configurable in GPSBabel?

It would be helpful to have a sample GPX that you used, and the corresponding NMEA.  If you don't want to post it here, you can email it to me: philharvey66 at gmail.com

- Phil

BTW: You can see the values that ExifTool imports from the track log by using the -v4 option.  This should show us where these problems are coming from, but I'll need to see the actual logs to devise a strategy to fix them.  I'm thinking the NMEA problem should be fixable, but I'm not sure about the GPX GPSTrack issue because it may require a change that would break things for other users.

[bob3bob3]

Hi Phil, tnx for getting back.

Please find gzip files attached. Both the NMEA and GPX source files are quite "smooth", but I did a reverse geotag on the images to show the problem. Have also included the Mapillary OSMiD overlay of one area.

Fractional seconds are written to the jpg okay from the NMEA source. I don't know if GPSBabel synthesizes, but the NMEA source file actually has fractional seconds written in it.

Yes the GPX file has "course" and if I have to use it I am quite okay "renaming" the tags to GPSTrack etc. The problem one is actually GPSSpeed as I use that to do rough filtering prior to upload.

Noted re -v4. I'll give that a try later today.

Cheers Bob

[Phil Harvey]

Thanks for the samples.  You're right, NMEA does contain fractional seconds.  My mistake.

It looks to me as if GPSBabel is smoothing the coordinates.  This will make things look nicer but it won't improve the accuracy.

For example, this fix from the NMEA log:

Code Select Expand

$GPRMC,212131.200,A,2629.222,S,14758.920,E,0.00,65.30,220724,,*26
$GPGGA,212131.200,2629.222,S,14758.920,E,1,06,1.3,341.990,M,37.7,M,,*49
$GPVTG,65.302,T,0,M,0.004,N,0.008,K*6E
$GPGSA,A,3,,,,,,,,,,,,,2.9,1.3,2.5*3C
has

latitude = 26 deg 29.222 min = 26.48703333333 deg
lonitude = 147 deg 58.920 min = 147.982 deg

But the corresponding fix in the GPX file has slightly different coordinates:

Code Select Expand

      <trkpt lat="-26.487040000" lon="147.981996667">
        <ele>341.990</ele>
        <time>2024-07-22T21:21:31.200Z</time>
        <course>65.302002</course>
        <speed>0.002315</speed>
        <geoidheight>37.7</geoidheight>
        <fix>3d</fix>
        <sat>6</sat>
        <hdop>1.300000</hdop>
        <vdop>2.500000</vdop>
        <pdop>2.900000</pdop>
      </trkpt>
This is not just rounding.  Some smoothing is being performed.

I think you need to understand what GPSBabel is doing.

- Phil

[bob3bob3]

Hi Phil

Didn't try the -v4 but found the base reason. It was about "smoothing" in a way but was to do with the NMEA only, not the GPX.

I had been carrying out a "clean" of NMEA data using GPSBabel with an NMEA output;

Input;
$GPRMC,220000.00,A,2635.4687,S,14822.2388,E,49.4943,48.554,220724,9.4,E*75
$GPRMC,220000.20,A,2635.4669,S,14822.2411,E,49.4713,48.712,220724,9.4,E*7B
$GPRMC,220000.60,A,2635.4633,S,14822.2457,E,49.5531,48.814,220724,9.4,E*78
$GPRMC,220000.80,A,2635.4615,S,14822.2481,E,49.5338,48.956,220724,9.4,E*71

Output;
$GPRMC,220000.000,A,2635.469,S,14822.239,E,49.49,48.55,220724,,*1F
$GPRMC,220000.200,A,2635.467,S,14822.241,E,49.47,48.71,220724,,*14
$GPRMC,220000.600,A,2635.463,S,14822.246,E,49.55,48.81,220724,,*1F
$GPRMC,220000.800,A,2635.461,S,14822.248,E,49.53,48.96,220724,,*1D

Note the rounding problem. I reran the geotag on the higher precision file data and it all now works. I am using version 1.8.0 of GPSBabel. 1.9.0 is available so I may test that too. I don't see anything in the docs that mentions this as such.

Many thanks for the steer!

Cheers Bob