Thisbug affects coordinates in exported JPEGs and TIFFs but not in raw XMPsidecars, which maintain high precision.
Aworkaround is to use the Run Any Command plugin to create an exportpost-process action that runs ExifTool with arguments that copy the GPScoordinates from the original to the exported file.
Details of the Bug
EXIFrepresents GPS coordinates with three rationals (fractions) for degrees,minutes, and seconds. The numerators and denominators are stored as 32-bitunsigned integers, allowing extremely fine precision (on the order of 1 part in70 million of latitude or longitude seconds).
Forexample, ExifTool stores the latitude 37.1234567891389 in EXIF with these threerationals:
LRstores GPS coordinates in the catalog as 64-bit floating point numbers, whichallow 15 decimal digits of precision, with at least 12 fractional digits. Thisprovides a precision of roughly 0.00001 (10^-5) centimeters.
Butinexplicably, LR exports EXIF coordinates using a minutes denominator of only10,000, limiting precision to about 18 centimeters. For example, it exportslatitude 37.1234567891389 as:
(Youcan examine the rational representation of the exported coordinates using"exiftool -v".)
Thefix is trivial -- use a minutes denominator of 50,000,000 rather than 10,000,which will increase the precision to about 0.004 centimeters. (A denominator of 50,000,000 is small enough to allow a maximum value of60 to be represented as a 32-bit unsigned rational.)
Here'ssample code of how to do the conversion from floating point to the EXIFrational representation:
function degreesToEXIF (d) local sign = d >= 0 and 1 or -1 local degrees, fracDegrees = math.modf (math.abs (d)) local minutes = fracDegrees * 60 local minutesDen = 50e6 local minutesNum = math.floor (minutes * minutesDen + 0.5) if minutesNum == 60 * minutesDen then degrees, minutesNum = degrees + 1, 0 end return sign, degrees, 1, minutesNum, minutesDen, 0, 1 end