Limit precision in gpx.fmt

[WGroleau]

The following request has some inaccuracies due to a lack of understanding on my part. I have suggested an alternative in the following comments.

I suggest this file should format lat/long to seven decimal places or less. Seven would be one centimeter or less.

(-p gpx-fmt causes -c to be ignored.)

With the claim that there are devices with greater accuracy, an alternative might be for some other part of the perl code to make the -c not be ignored. Otherwise everyone would have to maintain their own copy of gpx.fmt for whatever precision they prefer.

[StarGeekSpaceNerd]

This post disagrees with that assessment.

See the -c (-coordFormat) option. By default, exiftool will copy with 8 decimal points for the seconds, but only two when printing.

If you're using the -n (--printConv) option, then you're getting the raw number. See the above -coodFormat link if you want to limit the output.

[WGroleau]

The issue is with gpx.fmt (see title). -p gpx-fmt causes -c to be ignored.

I did not use -n but I suspect it would also be ignored.

But your link tells me I am wrong about accuracy—that there are devices with greater accuracy than the GPS system can provide. I've edited the suggestion to acknowledge that possibility.

[StarGeekSpaceNerd]

Ah, my apologies. I indeed did not read the title closely enough.

If you look at the gpx.fmt file you will see that the tag names in it all have a trailing hashtag. This is a shortcut for the -n (--printConv) option. So that option is in effect and will override the -coodFormat option. I would think this is to prevent problems where a user might add options that would affect the output and lead to undesired results, which would make it harder to trouble shoot.

If you change line 30 to remove the hashtags, then the -coodFormat option should work. Line 31 could also be edited if desired, but line 32 should probably be left alone.

[WGroleau]

OK, I would revise the request to leave the # out of the "official" file so that the user can decide the format on the command line.

[boardhead]

I think it is best to write the full precision to the GPX file by default. If I made the change you suggest then people would complain about a loss in precision.

[WGroleau]

Then perhaps text in the file comments and in the man page to explain the option for folks who have the same lack of knowledge that I had. Not knowing that the # in the file overrides the -coordformat might induce some frustration.

[boardhead]

I like the idea of adding a note to this effect in the gpx.fmt file. Here is what I came up with:

#            4) Coordinates are written at full resolution.  To change this,
#               remove the "#" from the GPSLatitude/Longitude tag names below
#               and use the -c option to set the desired precision.

• Phil

[WGroleau]

On Sep 13, 2022, at 08:53, Phil Harvey ***@***.***> wrote: I like the idea of adding a note to this effect in the gpx.fmt file. Here is what I came up with: 4) Coordinates are written at full resolution. To change this, remove the "#" from the GPSLatitude/Longitude tag names below and use the -c option to set the desired precision.

Sounds good to me. Might also want to consider revising this part of the man page: exiftool -p gpx.fmt -d %Y-%m-%dT%H:%M:%SZ dir > out.gpx Generate a GPX track log from all images in directory "dir". This example uses the "gpx.fmt" file included in the full ExifTool distribution package and assumes that the images in "dir" have all been previously geotagged. The -d isn’t needed now since you have put the equivalent into the format file. By the way, it still works even if some of the images have no GPS tags. Those get an error message back to the shell and are omitted from the output GPX file. For a bonus, that file can then be used to tag the other images using other tools that interpolate by time of creation.

…

-- Wes Groleau “An adventure is only an inconvenience rightly considered. An inconvenience is only an adventure wrongly considered.” ― G.K. Chesterton

[boardhead]

The -d isn’t needed now since you have put the equivalent into the format file.

Good point, thanks. I'll update this.