Sticky GPS Co-ordinates - Too many decimal places

[PandDLong]

I am cleaning up my Created and Shown GPS co-ordinates to set them the same when they should be (they got a bit messed up in the Spring).  In many cases, the issue is with rounding where one will have 13 decimal points of precision and the other will be rounded/truncated at 6.

Using a metadata template (MDT), I copy the co-ordinates from one to the other and set the gpsdestdistance to zero.  This works fine 90% of the time.


But, sometimes after write-back, I still have an issue but the 13 digit GPS co-ordinate has changed spots.

Before MDT


After applying the MDT


After write back



This will repeat endlessly using MDT to copy from the rounded GPS co-ordinates to the other.  Sometimes the IPTC Extension Location GPS tags are the same as EXIF GPS tags and sometimes they are both rounded values so a bit "out of sync".

Then I decided to try and manually edit the GPS co-ordinate by trimming the excess decimal points.   Then I did a write back and the result was even stranger - with two "lengthy" GPS co-ordinates showing up.




As further testing, I changed the MDT to copy the EXIF GPS tags (using the short codes) but I had the same outcome.

If you know the game, this feels a bit like "whack a mole".   

Not a big issue, but it is odd behaviour given it occurs only with a few images - both those with GPS originally suppled by the camera as well as those that I had originally done through the iMatch map.


Let me know if there is some further testing that would be helpful.


Michael

[Tveloso]

I have seen these high-precision GPS coordinates on occasion here as well.

It's been some time since I last saw this happen (but I also haven't been able to work with IMatch as much lately), so I can't be sure it was the exact same behavior as Michael describes (where the high-precision values "moved" between Created and Shown).  I think in my case it stayed at one of the two, but didn't initially "stick" with an attempt to synch them (to the lower-precision value).

But I did manage to get them synched via copy and paste (so effectively via manual edits in the MD Panel).  I think it might also have required updating the corresponding tags back on the 1-Default MD Panel layout as well.

[Mario]

I don't understand the problem.

ExifTool rounds, I assume, to a certain number of digits, clipping trailing zeros.
Maybe native GPS and XMP GPS have different precision requirements or storage capabilities and mapping between them introduces some minor rounding error?  I have really never bothered.

There is a lot of math going on when coordinates are calculated, shifted, rotated, projected and moved between the map panel in the browser JavaScript, the code provided by OpenLayers or Google in their APIs, coordinates moved between the browser and IMatch via JSON, formatted for display in the MD panel or emitted by a variable. Precision and significant digits don't change but there may be more or less precision (aka digits) produced, depending on which algorithm is used and where. Floating point (real) numbers are never really 'precise'.

The algorithms uses by IMatch or the Map Service APIs may use more or less precision than ExifTool. Writing back GPS data maybe result is small changes in the 6th, 8th or higher digit. I think this is what you encounter? But that's irrelevant for the purpose. People put a pin on the map or want to see the pin where the file is placed.  If lat is 51.479345 or 51.47934512301 is irrelevant.

When I recall correctly, IMatch uses 13 (?) digits, trimming trailing zeros as needed. Not sure. Did not work with this for a long time.

If you try compare GPS coordinate for some purpose, use something like 

(abs(latA-latB) < 0.00001) and (abs(lonA-lonB) < 0.00001)

or whatever precision you require to determine that two coordinates are the same.

[Tveloso]

In my case, this could potentially be an artifact of differing treatment of the structured location tags across earlier versions of IMatch.

For the sake of simplified terminology, lets say that within the two sets of Location Data

    1.) Created
    2.) Shown

...there are two sets of Tags:

    1.) GPS Coordinates
    2.) Location Names (Country, City, etc)

...so that we have:

    1. Created
      1.1 Coordinates
      1.2 Names

    2. Shown
      2.1 Coordinates
      2.2 Names

My newly indexed files contain only Created Coords initially:

    1. Created
      1.1 Coordinates <values populated>
      1.2 Names <no data>

    2. Shown
      2.1 Coordinates <no data>
      2.2 Names <no data>

What I find now, is that after Reverse Geocoding such a file, I will get this:

    1. Created
      1.1 Coordinates <values populated>
      1.2 Names <no data>

    2. Shown
      2.1 Coordinates <no data>
      2.2 Names <values populated>

...while such a file that was eligible to receive an IMatch Location at Ingest, looks like this:

    1. Created
      1.1 Coordinates <values populated>
      1.2 Names <values populated>

    2. Shown
      2.1 Coordinates <no data>
      2.2 Names <values populated>

What I recall seeing earlier this year is what I think resulted in a "writeback loop" (I believe for for Image Direction), because the file wound up with this condition:

    1. Created
      1.1 Coordinates <values populated>

    2. Shown
      2.1 Coordinates <values populated - with higher precision>

...so the two sets of GPS Coordinates actually differed from each other slightly (thereby causing a new Image Direction? value to be calculated?), and requiring another writeback for the Direction Tag.

I no longer recall those details, but I remember having to try a few times to get the two coordinate sets to be in synch, so that a new WriteBack would not be needed.

While it seems that for my newest files (indexed over the past few days), only the Created Coordinates (1.1) have values (even after I have finished processing those files - via reverse Geocoding or applying IMatch Locations) I did find some files from just a few weeks ago where both sets are fully populated:

    1. Created
      1.1 Coordinates <values populated>
      1.2 Names <values populated>

    2. Shown
      2.1 Coordinates <values populated>
      2.2 Names <values populated>

...but there, the two sets of Coordinates contained identical values (both having 6 digits after the decimal).  And the two sets of Names were also the same.

In may case, these are all iPhone Photos, and there were iOS updates over that period of time as well, so even more stuff influencing all of this...

But I do remember seeing those "higher precision values" in some of my files earlier this year...(but haven't see them since)...

[Mario]

Not sure if I understand everything written in your post...

GPS coordinates coming in from a device can (and usually will) differ from numerical coordinates produced by the Map Panel and will also differ between different map providers. In the virtually irrelevant digits.

5 decimal places is a resolution of 1.11m and the 7. digit is already only 11.1mm.  That's way more than any GPS device can deliver (except maybe military).

IMatch keeps the coordinates as delivered by ExifTool (numerical and degrees).
When IMatch produces coordinates using a Map provider or other means, it uses the numerical as produced. For formatting, IMatch uses a format that produces (within the limits set by the standard library / Windows numeric formatting) the full number, without trailing spaces.

As I wrote in another post, there will be tiny differences between devices, map providers and how numerical values are formatted e.g. in the Metadata Panel or when ExifTool processes numerical values provided by IMatch via args during write-back.

As I said, the actual number of decimal places, trimmed or rounded to 8 or more digits can be ignored. Usually humans never look at these coordinates, except maybe in the degrees format. IMatch can display numerical coordinates, but that should not cause confusion or concerns.

GPS resolution, in best conditions, is 3 to 5 meters or so. In normal environments, it's more like 10 to 20 meters. There are of course, depending on the device used or at which zoom level you set a pin in the Map Panel, variations. Some devices triangulate better than others, some devices have better GPS receives, a user setting a pin at Map zoom level 10 instead of 8 will get a different coordinate pair from the map provider etc.

[PandDLong]

In sorting out my problem, I realized I mis-labelled the subject.  I thought the extra precision was the problem - it was a "red herring" (I hope you know this english expression).   

As per Tony's comments, most of my problem was generated when I did a lot of geo-related changes during that period when there was a rounding issue between exiftool and iMatch  (while Mario fixed that issue quickly with another release, I think it was longer before I updated my version).

To be clear - whether there is 5, 6, or 12 decimal places of precision doesn't really matter (as per Mario's comment).  However, when the Location Shown and Location Created are different - even by very little - it can create other issues - as you can see here in my map panel with artificial destination co-ordinate and corresponding field-of-view.



Hence, I was trying to make them equal for the approx. 2000 photos for which they had become slightly different.  A simple metadata template to copy Created GPS to Shown GPS worked 90+% of the time.  But, as per my original note, some had a sticky problem that was a challenge to fix.
I think I have fixed all the photos, through the following:

1. If the Created GPS had extra precision, I still copied it to Shown (after I stopped thinking the precision was the problem).  That solved about half of my sticky GPS photos.

2. More were solved by "undoing" the GPS.  For all my photos that have GPS co-ordinates when I first index in IMatch, I copy the GPS co-ordinates to custom tags as a historical record (ask me why I decided to do that...).  For "undo", I use a metadata template to copy those original co-ordinates back to the exif tags and do a write-back.  That solved all photos that had original GPS added by the camera.

3. For the remainder, I deleted the Shown GPS and did a write-back.

For those last two categories, those photos no longer have a Shown GPS but that is okay as that was normal with earlier versions of iMatch. Out of curiosity, I applied my template to again set Shown GPS to be the same as Created for a couple of these photos and that seemed to work fine. 

A couple of observations when trying to diagnose why some had a problem but most did not:
  - Those that needed another write-back to update the 'imgdirectionref' were often the problem ones as that would update a GPS co-ordinate or two.
  - In the output panel for Exiftool, I could see where it would '-' a GPS tag and then '+' a slightly different value to the same tag. Not sure where it was getting the different value as it wasn't in the "request" from iMatch.

Some Apple Quicktime movies still have GPS issues - but it seems quite different.  If needed I will create a different thread for those (hoping not).

Thank you Mario & Tony for contributing to this thread, it helped me think through this challenge.

Michael