GPS data losing accuracy

[Jim Easterbrook]

I have image files with GPS info that has a precision of fractions of a minute. (The files were generated by Microsoft Pro Photo Tools, if that's relevant.)

exiv2 can read these files OK - for example:

exiv2 -g Xmp.exif.GPSLatitude -g Xmp.exif.GPSLongitude -g Exif.GPSInfo.GPSLatitude -g Exif.GPSInfo.GPSLongitude ~/Pictures/chateau_gontier.jpg
Error: Directory Canon with 6144 entries considered invalid; not read.
Exif.GPSInfo.GPSLatitude Rational 3 47deg 49' 35.419"
Exif.GPSInfo.GPSLongitude Rational 3 0deg 42' 25.135"
Xmp.exif.GPSLatitude XmpText 13 47,49.590323N
Xmp.exif.GPSLongitude XmpText 12 0,42.418921W

Reading the same file with pyexiv2 returns the Xmp keys as pyexiv2.utils.GPSCoordinate values with integer attributes: 47, 49, 35 and 0, 42, 25.

As I should have mentioned in question #211407 (which relates to bug #1067894) pyexiv2 returns the Exif keys as three rationals: [Fraction(47, 1), Fraction(49, 1), Fraction(22137, 625)] and [Fraction(0, 1), Fraction(42, 1), Fraction(31419, 1250)].

[Olivier Tilloy (osomon)]

Thanks for the report Jim. Any chance you can attach a sample picture with similar GPS data, so I can easily reproduce and investigate?

[Jim Easterbrook (wdwr04gwhnd-jim)]

Here's a small image of mine, stripped of metadata, then geotagged in Pro Photo Tools. Curiously the latitude and longitude lists of rationals now have seconds set to zero: [Fraction(47, 1), Fraction(2479543, 50000), Fraction(0, 1)] and [Fraction(0, 1), Fraction(1060489, 25000), Fraction(0, 1)]

[Olivier Tilloy (osomon)]

The issue is with the GPSCoordinate class (http://tilloy.net/dev/pyexiv2/api.html#pyexiv2.utils.GPSCoordinate) implementation in pyexiv2: it casts the 'seconds' attribute to an integer, assuming seconds cannot be floating point values.

[Jim Easterbrook (wdwr04gwhnd-jim)]

Given that degrees, minutes and seconds are all stored as 'rational' type in EXIF, I suggest that none of them should ever forced to be an integer. A side effect of this is that the a latitude or longitude value can be represented in many different ways, which will make the == operator interesting to code.

For example, 51 degrees, 30 minutes, 10.25 seconds could be stored as [Fraction(51, 1), Fraction(30, 1), Fraction(41, 4)] or [Fraction(51, 1), Fraction(7241, 240), Fraction(0, 1)]. The GPSCoordinate forms of these could be GPSCoordinate(51, 30, 10.25, 'N') or GPSCoordinate(51, 30.17083333, 0, 'N').

It appears that both forms are used, even by the same software (see my Pro Photo Tools examples). I don't know if there is any good reason not to normalise all to integer degrees & minutes and float seconds. (As long as the constructor accepts floats for all.)