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.)
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.)