The process for writing GPS values does not preserve sufficient precision of (sub-meter) GPS coordinates. That is, myFile.Properties.Set(new GPSLatitudeLongitude(ExifTag.GPSLatitude, d, m, s)); results in slightly inaccurate "jagged" coordinates, which becomes apparent when they are otherwise smooth/linear/interpolated.
This is what I would expect (these are linearly-generated points at 0.00001/0.00002 lat/lon steps):
This is the actual result:
After investigating, I believe it is UFraction32.FromDouble() that can create an inaccurate fraction. I iterated it a bunch over 0.00001 steps (convert a decimal to fraction and then get back the decimal) and here's the sort of worst case result: 51.409100 -> 51.411765 delta 0.002665. I'm not entirely sure what sort of error this means for DMS seconds vs real-world distance, but the resulting example above shows that it can easily reach a meter or so.
To make sure I wasn't losing precision elsewhere, I changed the decimal-to-fraction implementation to https://stackoverflow.com/a/42085412 and this does indeed result in accurate values (the expected result above is generated this way).
The process for writing GPS values does not preserve sufficient precision of (sub-meter) GPS coordinates. That is,
myFile.Properties.Set(new GPSLatitudeLongitude(ExifTag.GPSLatitude, d, m, s));results in slightly inaccurate "jagged" coordinates, which becomes apparent when they are otherwise smooth/linear/interpolated.This is what I would expect (these are linearly-generated points at 0.00001/0.00002 lat/lon steps):
This is the actual result:
After investigating, I believe it is
UFraction32.FromDouble()that can create an inaccurate fraction. I iterated it a bunch over 0.00001 steps (convert a decimal to fraction and then get back the decimal) and here's the sort of worst case result:51.409100 -> 51.411765 delta 0.002665. I'm not entirely sure what sort of error this means for DMS seconds vs real-world distance, but the resulting example above shows that it can easily reach a meter or so.To make sure I wasn't losing precision elsewhere, I changed the decimal-to-fraction implementation to https://stackoverflow.com/a/42085412 and this does indeed result in accurate values (the expected result above is generated this way).