exiftool wrongly maintains a gps latitude string value

[paolobenve]

with the attacched image,

Code Select Expand

exiftool -j -n produces a string value for the GPSLatitude tag, while it should produce a float one as for GPSLongitude.

exiftool 12.40

[Phil Harvey]

Some JSON parsers have trouble with too many digits in a numerical value, so ExifTool treats it as a string if it has more than 16 digits after the decimal place.  Unfortunately, your GPSLatitude has 17 digits.

I can't think of an easy way around this.

- Phil

[Phil Harvey]

OK.  I'll add a patch to ExifTool 12.78 which will provide a work-around: With that version you can use -c %-.16f instead of -n to format as a signed number with 16 decimal places.

- Phil

[StarGeek]

To be fair, that is a ridiculously useless degree of accuracy.

Eight decimal places is 1.1 mm
If I've done the math correctly, 17 decimal places works out to 1.1 fm (Femtometers), which would be used to measure the width of the nucleus of an atom.

Anything beyond -c %.9f is smaller that 0.11 mm.

[paolobenve]

> To be fair, that is a ridiculously useless degree of accuracy.

You are right, but if for any reason that value is there, exiftool produces a string instead of a number, and this behaviour can make a software using exiftool crash

[Phil Harvey]

The high precision is an artefact of the way the EXIF GPS is stored:

Code Select Expand

> exiftool a.jpg -gpslatitude="0 0 1"
    1 image files updated
> exiftool a.jpg -gpslatitude
GPS Latitude                    : 0 deg 0' 1.00"
> exiftool a.jpg -gpslatitude -n
GPS Latitude                    : 0.000277777777777778
> exiftool a.jpg -gpslatitude -n -j
[{
  "SourceFile": "a.jpg",
  "GPSLatitude": "0.000277777777777778"
}]
Perl limits the precision to 15 digits, but if the value is less than 1 you may have leading zeros after the decimal on top of the 15 digits.  This only happens for GPS coordinates near the equator or prime meridian.

- Phil

[Neal Krawetz]

GPS with 17 digits?  That's like "precise to the atomic level". (Accuracy is not the same a precision.)

With today's technologies, 8 decimal points is the max that I've seen for most gov and scientific high performance uses. (That's millimeter resolution.) Considering that the ground moves by more than about a foot (1/3 meter) every day due to "earth tide" (lunar gravity pull) and heat expansion/contraction from the Sun, most readings beyond 6 decimal places are likely to change after any given hour.

But that's high sensitivity. For orbital consumer GPS? That's usually 5 decimal places max (+/- 1 meter).
Devices that record more than 5 decimal places are just throwing out random numbers at that point.

(As I recall, Phil has a physics background. So he's welcome to correct me.)

Why does ExifTool ever report more than 6 decimal places for GPS?

[Phil Harvey]

You are correct Neal.  (And I do have extensive experience with GPS systems from years working on sonar surveying software as well as my astroparticle physics background.)

But don't blame ExifTool, it reports what is written.  And you would be surprised at the number of people who want an "exact" coordinate value to be stored with an ungodly number of digits.

- Phil

[Phil Harvey]

But to get back on topic, and to summarize the problem:

1. Some JSON parsers crash when reading numbers with more than 16 digits after the decimal point.

2. To patch this, ExifTool quotes these values and returns them as a string.  (I know, I hate adding patches for other sofware's bugs, but there you have it.)

3. To deal with this, the JSON reader must be flexible enough to handle either a string or number for any given tag.

I don't know what your program looks like, but I would think that point 3 should be easy to implement.

- Phil