Please HELP with TESTING if you work with GPS, the Map Panel and Location Data

[Mario]

For the next release of IMatch I plan to introduce some changes in the Map Panel.
I would be grateful if you can run some easy tests for me.
(Also related to this thread).

The Map panel now sets the destination (shown) coordinate when you drop a file or use the "Apply target marker" command in the toolbar. Before, it set the "created" coordinate for "historical" reasons.
If you then (or later) add a Destination Coordinate, the previous shown coordinate becomes the created coordinate and the new destination coordinate becomes the shown coordinate.

This also applies to the corresponding IPTCExt/Core/photoshop location data (country, city, state). When you have automatic reverse geocoding enabled, IMatch updates the location data when you change coordinates or add a destination coordinate pair. If you don't use automatic reverse geocoding you'll have to manually reverse geoode again, like with any manual change of GPS coordinates.

By definition and recommendation, a user-set GPS coordinate (e.g. in the Map Panel) should be considered as "shown". Users usually don't set the camera/device coordinate but the coordinate of what they were looking at. It more "stringent" now.

I would like to get as much feedback from users as early as possible.
There are so many workflows and so many "other" applications working with GPS coordinates somehow. I would like to check before I ship this update. And my brain is maybe a bit mushy currently. Too many hats and all that...

Helping and Testing is Easy!

Attached below is a new version of the Map Panel and a new metadata configuration file.
While IMatch is not running, you replace the Map Panel and configuration file on your computer with the new versions attached below. You can easily undo the changes if it does not work!

1. Make a backup of the folder containing the Map Panel:
"C:\ProgramData\photools.com\IMatch6\webroot\imatch\apps\FEATURES\mapapp"
Just copy the entire folder to another folder.

2. Make a backup copy of the metadata configuration file:
"C:\ProgramData\photools.com\IMatch6\config\immbcfg.xml"

3. Unzip the new version of the configuration file and replace the configuration file with the new version (See 2. above).
Windows Explorer must ask if you want to replace the existing file.

4. Unzip the new version of the Map Panel and replace the existing version on your system (see 1. above)
Windows Explorer must ask if you want to replace the existing folder.

5. Delete the IMatch browser cache folder:
"C:\ProgramData\photools.com\IMatch6\browser"

6. Work with the Map Panel, do reverse-geocoding as you usually do.
Set coordinates for a new file, change coordinates for a file, add a destination coordinate etc.
Write back metadata.
Test the results in other applications and services you use for viewing or using GPS and location data.

In case it does not work for you

A. Tell me what's not working, with as many details as possible.

While IMatch is not running:

B. Restore the backup copy of the original Map Panel (see 1. above)
C. Restore the backup copy of the metadata configuration file (see 2. above)
D. Delete the cache folder again

That's all. Your back to the current IMatch version.
Thanks for helping!

[Bolitho]

The intended change frightens me:

The Map panel now sets the destination (shown) coordinate when you drop a file or use the "Apply target marker" command in the toolbar. Before, it set the "created" coordinate for "historical" reasons.
If you then (or later) add a Destination Coordinate, the previous shown coordinate becomes the created coordinate and the new destination coordinate becomes the shown coordinate.

Far too complicated to assign the "created" coordinate (if one just wants to assign the "created" coordinate and nothing else).
Please don't do this!

KISS - Keep It Simple and Stupid:
What about leaving the "Apply target marker" as is (for the "created" coordinates) and adding an additional button "Apply destination coordinate"?

My personal background: I'm in travel photography, almost 100% of my images have "created" coordinates (mainly assigned automatically, sometimes repaired or added manually if necessary); a certain percentage has "shown" coordinates which of course only can be assigned manually.

So "created" is first before "shown".

[Mario]

Thanks for the feedback! Much appreciated.

For a long time, IMatch sets the location shown location data from the created coordinates, copying the coordinates when you use the Map Panel and reverse geocoding, unless there is also a location shown coordinate. This is in accordance with the IPTC/MWG recommendations to prefer shown for 'user-set' coordinates. This causes the created coordinates to become part of IPTCExit::LocationShown, which causes confusion. Unless the user also adds a destination coordinate pair, which sets everything straight.

This new test version just goes one step further, preferring the shown coordinate also when the user adds coordinates in
the Map Panel. Created is for devices and trackers which don't know where the user/camera was looking at.

Another solution would be a straight c->C and s->S, meaning always filling out the created address from the created coordinates and the shown address from the shown coordinates. Not sure if and how many workflows / integrations this would break.

My assumption is that when a user sets a coordinate on the Map, he/she means "That's the building/landmark/location" shown in the image and not "This is where the camera was standing".  If there is only a created address (e.g. from a device or track log), IMatch can only assume that this is the location shown.

I'm not sure what the best solution is. I definitely want to keep this simple (for coding and the user).
That's why I open this for discussion.

[rienvanham]

Hi Mario,

I'm getting this error when (replacing) coordinates:



Greetings,
Rien.

[Mario]

Hi Mario,

I'm getting this error when (replacing) coordinates:

You replace coordinates how?
Have you deleted the browser cache?

[rienvanham]

Yes,

Deleted the browser cache (again);
Took a random photo (with existing geodata);
Pointed at a random place on the map (an orange "arrow with hole" appears on that spot);
Pressed the "apply" button -> the error is there!

Rien.

[Mario]

Do you use Google Maps or one of the other maps?

[axel.hennig]

I also get this error:

Tried with a new test-DB and added a pic without metadata.
I've used GoolgeMaps.

Tested with OpenStreetMap and the error-message does not occur.

[axel.hennig]

The Map panel now sets the destination (shown) coordinate when you drop a file or use the "Apply target marker" command in the toolbar. Before, it set the "created" coordinate for "historical" reasons.
If you then (or later) add a Destination Coordinate, the previous shown coordinate becomes the created coordinate and the new destination coordinate becomes the shown coordinate.

This does not (really) work for me.

Tried with OpenStreetMap. Used a pic without metadata. Apply target maker to Berlin. Write-back. Reverse geocoding (Strg+M,G). Write-back. See screenshot.



Add image direction (via right-click on the map-panel; destination coordinate) to New York. Write-back. See screenshot.



Problem: Berlin lat/lon got shifted from Shown to Created but all other data (altitude, country, city,...) not. So current situation for Shown is: lat/lon for New York and altitude, country, city,... for Berlin.

Reverse geocoding (Strg+M,G) asks for created ans shown. Write-back. Now everything okay. See screenshot.

[axel.hennig]

Far too complicated to assign the "created" coordinate (if one just wants to assign the "created" coordinate and nothing else).
Please don't do this!

Same for me.

I would also prefer to just use "created" coordinates and not shown. And for some images I would like to manually add "created" in IMatch without having shown coordinates. Maybe adding two "apply marker" buttons? Or at least the possiblity to set both markers to the same coordinates with one click (less prefered).

Sidenote:
Shown - for me - could be very complicated. Taking a panorama from Eiffel Tower (Paris) could show nearly whole Paris. Where do I put the shown coordinates? Or do I put multiple Location Shown datasets as possible for "Location Shown tag set". And is reverse geocoding working for multiple Location Shown datasets?

[sinus]

Far too complicated to assign the "created" coordinate (if one just wants to assign the "created" coordinate and nothing else).
Please don't do this!

Same for me.

I would also prefer to just use "created" coordinates and not shown. And for some images I would like to manually add "created" in IMatch without having shown coordinates. Maybe adding two "apply marker" buttons? Or at least the possiblity to set both markers to the same coordinates with one click (less prefered).

Sidenote:
Shown - for me - could be very complicated. Taking a panorama from Eiffel Tower (Paris) could show nearly whole Paris. Where do I put the shown coordinates? Or do I put multiple Location Shown datasets as possible for "Location Shown tag set". And is reverse geocoding working for multiple Location Shown datasets?

Same for me too. 
I want use created coordinates. Say, you are in the mountains, take pictures from several mountains. Far too complicated to look for each shown target. 

I did this a short time and decided for me: simply not necessary and not really practible. Hence I do this only very seldom. 

With this sentence " My assumption is that when a user sets a coordinate on the Map, he/she means "That's the building/landmark/location" shown in the image and not "This is where the camera was standing"."

I do think the contrary. I want set the coordinate, where the camera was standing, not what is shown. If I stay on a tower in Frankfurt, I take photos from several other towers and city-impressions. Now I do not want to click on every shown building, this would be akward for me, I want to set where I was standing and that's it. 

This is, what I see. 
This thread is very interesting and very good, so can Mario (and he does) hear, what users think and decide.

[hluxem]

I want set the coordinate, where the camera was standing, not what is shown.

I agree with this as well.
That makes for an efficient and almost automatic workflow too. I usually log a GPS track with my phone. Not many pictures I use the map to set location, but I would always only want to set the location created. Created location data is included in all of my phone pictures.

[Ron_S]

I do think the contrary. I want set the coordinate, where the camera was standing, not what is shown.

I agree with this, and I have "liked" all the replies above that support this way of using location created.

[Mario]

Problem: Berlin lat/lon got shifted from Shown to Created but all other data (altitude, country, city,...) not. So current situation for Shown is: lat/lon for New York and altitude, country, city,... for Berlin.

Reverse geocoding (Strg+M,G) asks for created ans shown. Write-back. Now everything okay. See screenshot.

When you don't have reverse geocoding enabled, changing coordinates (or adding a new coordinate set) cannot change the location data you have entered. You need to run reverse geocoding again, IMatch cannot simple copy the data. It may become wrong or data entered by you may be overwritten.

[rienvanham]

Hi Mario,

I'm using Google.

Rien.

[Mario]

Hi Mario,

I'm using Google.

Rien.

Do you get the same error when you switch to OpenStreetMap?

[rienvanham]

Just in time... No, with OpenStreetMap I didn't get an error but it didn't change the existing values.

I reverted back so I can continue managing my photo's. I will retry it after a fix.

Thanks Mario!

[Jingo]

I do think the contrary. I want set the coordinate, where the camera was standing, not what is shown.

I agree with this, and I have "liked" all the replies above that support this way of using location created.

Me as well... I'm always using the map panel to add coords to the spot where the photo was taken not what the photo was taken of.  

[mopperle]

I completely agree with @sinus and others. Regarding GPS/location data, important for me is WHERE I have taken a picture. What I haven taken, comes to the description and/or keywords and/or categories. what sense does it make to get location data ("Location Shown") for a person, general landscapes, wildlife?
What I use when it comes to "what do you see on this image" is the "GPS Image Direction", for example mountain view. Unfortunately only my iPhone provides such data.

[jch2103]

I fully understand why Mario is doing this, and the complications/confusion from two historical (prior, anyway) for dealing with "created" v "shown" coordinates. 

Most of the time, I've been OK with the older default handling while making some exceptions on a case-by-case basis. I've been unable to test Mario's test update due to schedule conflicts, but hope to do so in the next couple of days. 

[jmsantos]

I have never understood MWG's recommendation that manual geolocation be saved to LocationShown, rather than LocationCreated (as seen in the flowchart). Hence, I rarely use this function and in practice write the location data manually.

As a photographer, my interest is to save the location created, which indicates where the camera was when taking the photo. For example, when synchronizing a tracklog with photographs, that track records the points where the camera was, not what is seen; however, the coordinates is written to LocationShown, based on that recommendation.

Perhaps the MWG recommendation makes sense in the work of documentalists, who are not the producers of the images. They can locate "what is seen", and may not know "where" the photo is taken from. But I don't see any sense in it for a photographer.

[axel.hennig]

I have never understood MWG's recommendation that manual geolocation be saved to LocationShown, rather than LocationCreated (as seen in the flowchart).

I don't understand that flowchart, because the first decision "Automated geo-location inserted?" does not has a "no" possibility...

[mopperle]

IMHO a No should point to "Manual geo-location to be added?"

[David_H]

IMHO a No should point to "Manual geo-location to be added?"

No; if you're not automatically adding the geo-location at creation, nothing happens (you could argue for a line to Done, but that'd be messy).

What's confusing is that the first modification around, if tags 1-6 aren't filled in, then they get filled (presumably LocationCreated, as that's the same as the Image Creation workflow), yet the second time around, they'll be present so update tags 19-26 (presumably LocationShown/Destination). No possibility exists for correcting the LocationCreated once its present in this workflow.

[DigPeter]

My photography subject are mainly relative closeups of wildlife and plants, or landscapes.  My gps data are of the position of the camera, which is all I need.  I am happy with the system as it is now.  I agree with Bolitho - keep it simple.   

[mastodon]

" Users usually don't set the camera/device coordinate but the coordinate of what they were looking at." Well, I don't think so. Users usually prefer to set the point, where the pfot was tkane, so where the camera was. Locations show is a very difficult task or not really interesting (photos of people in). I prefer to use only Location created, and Location shown is just a category.

[axel.hennig]

@Mario: based on the discussion in this thread, what is you current plan regarding implementation?

[erichaas]

I prefer to use LocationCreated. As pointed out above, LocationShown can be problematic for some photos.

[Mario]

@Mario: based on the discussion in this thread, what is you current plan regarding implementation?

I thought to give this a week or a bit more and then decide based on the responses.
So far I think the easiest solution would be to do a simple

created coordinates -> created location
shown coordinates -> shown location

mapping. That's better than the mix we have currently.

[dadu]

Hi Mario,
I am with the group that uses GPS coordinates to indicate where the camera was.

Related question: I noted that writing GPS coordinates to .jpg files changes the create date of the file to the time of writing the GPS coordinates. I don't want that...I want the original creation date of the .jpg to remain unchanged, regardless of when I write the GPS coordinates to the file. Is that possible at all?

[Mario]

P

Related question: I noted that writing GPS coordinates to .jpg files changes the create date of the file to the time of writing the GPS coordinates. I don't want that...I want the original creation date of the .jpg to remain unchanged, regardless of when I write the GPS coordinates to the file. Is that possible at all?

Please don't hijack this thread with an unrelated question.
Open a new thread and explain your observation.
Include a original image you have used and state exactly what you mean with creation date. There are about 10 timestamps which have the word create or creation in them, so the complete tag key is important.

[Mees Dekker]

I fully agree with all people who want GPS location as the location where the camera was. 

Often I want to take another photo from the same created position. It is essential that these coordinates are correctly saved. 

Besides: in general these coordinates are far more accurate (recorded by either the camera itself of via a tracklog) than the location shown. 

[Mario]

So after giving this poll a bit more than a week, I've carefully considered your replies.
Please let me know when I've missed a thing.

It appears to me what people want a simple:

1. Created coordinates => LocationCreated location data.
2. Target/Dest coordinates => LocationShown location data.

3. Setting a pin on the map (via target marker or dropping files) should (as it does now) set the created coordinate.
Which then sets the LocationCreated location data when reverse geocoding.

4. Adding a destination in the Map panel sets the destination coordinates and fills LocationShown location data.

5. Unless the user adds an explicit destination coordinate, only the created GPS coordinates and the LocationCreated metadata are filled.

Are these points correct?

Here are the problems with this approach.

1.  The MWG Location Data (like included in the Default Metadata Panel layout) are mapped to LocationShown, not LocationCreated by ExifTool (and IMatch). This means that when you only set a created coordinate, these tags are empty.

2. This also applies to location tags in other metadata standards (legacy IPTC) or XMP name spaces (IPTCExt, Photoshop etc.).
All these tags are mapped to *Shown location data, not *Created.

Several features of IMatch (like Events) look at LocationShown coordinates. Because so far, these were always filled. IMatch filled them when the user added a created coordinate only. And only when a file had both created and dest, both LocationCreated and LocationShown were filled. But LocationShown always had priority.

This is why I've implemented the complex logic with created coordinates => LocationShown unless there are also destination coordinates. Which then leads to the problems/issues I've explained in my first post above.

I understand that (most) users (and all cameras) set created coordinates. The Map Panel too.
This is the gist of this thread. Destination / shown coordinates are an optional extra not many users care about.

After reading all this I'm afraid that I will need to keep things as they are, with all the added complexity. Only then GPS location data will work in IMatch and in other applications and all "linked" location data in IPTC and XMP will be filled, even if the user only adds the created coordinate.

For example, "XMP::iptcExt\LocationShownCountryName" is mirrored/mapped into "Composite\MWG-Country" and "XMP::photoshop\Country\Country".

One solution I've came up with (and I kinda like it) would be to always fill both, LocationShown/LocationCreated location data when only location created coordinates exist. These sets of location data would then be identical, unless the user adds a destination coordinate pair, which breaks the automatic link.

I think this might work well, allowing the user to have created coordinates only while ExifTool and IMatch can do all the mirrorign and filling across metadata formats in the background.

[sinus]

...
One solution I've came up with (and I kinda like it) would be to always fill both, LocationShown/LocationCreated location data when only location created coordinates exist. These sets of location data would then be identical, unless the user adds a destination coordinate pair, which breaks the automatic link.

I think this might work well, allowing the user to have created coordinates only while ExifTool and IMatch can do all the mirrorign and filling across metadata formats in the background.

During reading your post, realy, exact this idea (one solution) came into my mind.
Then I read further and at the end you wrote about this. 
I think, without knowing your complex knowledge, this would be for sure a good solution! 

[axel.hennig]

Are these points correct?

Yes.

Question to your solution:
When both (Shwon and Created) are filled and I realize that the Created-coordinates are wrong. Then I would like to have two possibilities:
1. Set the new Created-coordinates via Map and keep the existing Shown-coordinates.
2.  Set the new Created-coordinates via Map and apply the same new coordinates to the Shown-location

[mastodon]

There is no so much possibilty because backwards compatibity. We have thousands of images with the old system.

[Mario]

Question to your solution:
When both (Shwon and Created) are filled and I realize that the Created-coordinates are wrong. Then I would like to have two possibilities:
1. Set the new Created-coordinates via Map and keep the existing Shown-coordinates.
2.  Set the new Created-coordinates via Map and apply the same new coordinates to the Shown-location

If the created coordinates are wrong and so the created and shown location data was set from the wrong coordinates, why would you like to keep the wrong location data for shown?

I guess in this rather rare case you can just add a destination coordinate in the map panel and thus unlink the location created from the location shown location data. You now have two separate sets of coordinates and you can reverse geocode or set them individually.

[mastodon]

Maybe short video explanation and how to about this after the implementation?

[Mario]

Maybe short video explanation and how to about this after the implementation?

The only thing that will change to what is currently implemented (assuming I implement my suggested solution) is that IMatch also fills the LocationCreated XMP location tags. Currently it only fills LocationShown, unless you set both a created and destination coordinate. I just make IMatch assume: "If there is only one coordinate, it's both created and shown".
I don't think an explanation video is really needed for that. Most users won't even notice the change.

Filling LocationShown is required, since many features in IMatch and the whole "location fields like City have to appear in multiple metadata formats and XMP namespaces". See my explanation above.

That's what IMatch does, but what leads to the unfortunate situation that files with created GPS coordinates only have LocationShown tags filled but noting in LocationCreated. This becomes especially apparent when working with the IPTC Location Metadata Panel layout, which shows both location data sets.

This thread shows that most users want created GPS coordinates to be treated as created (camera standpoint). Even when the standards like IPTC assume that a coordinates set manually by humans (e.g. in the IMatch Map Panel) are to be treated as "location shown", while coordinates set by devices are to be treated as "device standpoint".

I think it safe to assume that when a user only enters created GPS coordinates, these coordinates reflect both location created and location shown. And this is what I will implement for the next release. It ensures that LocationShown exists and can be mapped and it also ensures that LocationCreated contains location data matching the created GPS coordinates.

And yes. Metadata is complex and messy. And why so many software vendors out there don't care.

[Jingo]

I think the approach to fill both sets of fields will work for most users.. and allows complex functionality in IMatch to work as well.  

The whole XMP namespace makes one miss the simpler days of straight IPTC fields  

[Mario]

The whole XMP namespace makes one miss the simpler days of straight IPTC fields  

IPTC had (has) many shortcomings, from field length limiting to non-support for character sets.

XMP is a very versatile metadata format that can handle basically anything.
Problem is, things have evolved over time. And mistakes were made by standard bodies and software companies.

Many clients still work with legacy IPTC data deprecated 20 years ago. Sigh.
Then there are several EXIF versions and a ton of XMP changes (some breaking changes too) over the last decade, introducing and recommending different mappings for the same information into different XMP namespaces.

Then, why does photoshop XMP has a City and County tag, but no Location?
Where is there a created Altitude but no Shown Altitude tag?
Why do software vendors unnecessarily duplicate standard XMP metadata in their own proprietary name spaces and only fill their data, but not the standard tags?
Why do camera vendors write hard-coded "rating=none" into only partially defined XMP records?
Why do camera vendors record timezone offsets in the EXIF data but ignore them in the XMP data in the same file?
This list goes on and on.

All this creates a big challenge for a DAM like IMatch, which often has to deal with metadata written by a dozen applications over 10, 20 or 30 years. ExifTool and IMatch manage most of this complexity silently in the background. But sometimes I cannot come up with the "one "solution and have to do several iterations over time to best handle user interest, workflows, rules and recommendations across the board.

For IMatch, I want to make things work 'automatically' so users don't have to care. It would be a bad thing to tell a user that when he/she sets the City in that tag, he/she must also set the city in these 5 other tags. This should be something that is done by IMatch in the background (and it is).

Other software often does not care as much. And so we might end up with XMP data that has two different cities or locations or country names in different tags - tags which actually should be synchronized.
Users don't notice unless they switch to another software, which happens to fetch the city name from another tag not maintained by the original software - leaving the user hanging in limbo.

[Mario]

OK, here is how I've implemented it now
There is a video at the end of my explanation.

Definitions:
1. Files can have a set of created GPS coordinates and LocationCreated location data.
2. Files can have a set of destination GPS coordinates and LocationShown location data.
3. LocationShown must be is mapped to a variety of other tags in legacy IPTC, XMP IPTC, Photoshop XMP etc.

I) Automatic reverse geocoding is assumed to be off.
File has no GPS coordinates yet.

ACTION: User assigns GPS coordinates to the file (map panel or via a location).
Created coordinates are set. (NO CHANGE FROM BEFORE).

ACTION: User reverse geocodes the file.
This step is assumed to set the LocationShown (for reasons explained above).

IMatch applies the results from the geocoding to both LocationCreated and LocationShown (CHANGE).
Destination coordinates are set from the created coordinates when the file has no destination coordinates yet. (CHANGE)

Basically, IMatch now assumes that when there is only a created coordinate pair, "Shown equals Created".
Created and Destination GPS coordinates are identical.  (CHANGE)
There is a created Alt but no destination Alt tag. But IPCTExt has an Alt for LocationCreated and LocationShown and IMatch fills these.

Looking at the Map Panel, the file shows with the normal flag, although it has both created and destination coordinates (CHANGE). Before, the map panel would have clustered the two coordinate pairs and shown the blue (2) cluster icon.

ACTION: User moves the file flag to another location on the map.
IMatch recognizes that the file has identical created and destination coordinates and moves them both to the new location (CHANGE).

ACTION: User reverse geocodes again to update location data for the new position.
IMatch updates both LocationCreated and LocationShown.

ACTION: User adds a direction marker for the file. This changes the existing destination coordinate to a location nearby the created coordinate so both markers are visible. IMatch updates the file coordinates with the new destination coordinate.
Created coordinates and destination coordinates are now different and thus unlinked. (CHANGE)

ACTION: User moves the direction marker on the map. IMatch updates the destination coordinate for the file.

ACTION: User performs reverse geocoding for the file.
IMatch looks up both the location created and location shown coordinates and sets LocationCreated and LocationShown.

ACTION: User deletes the destination coordinate pair (easy via the IPTC Location Metadata Panel layout).
IMatch removes the LocationShown data and the destination coordinates.

ACTION: User moves the file flag on the map panel.
IMatch updates created coordinates for the file.

ACTION: User performs reverse geocoding for the file.
IMatch fills both LocationShown and LocationCreated and sets the destination coordinates to match the created coordinates.

II) Automatic reverse geocoding is assumed to be on.
File has no GPS coordinates yet.

ACTION: User sets created coordinates for the file on the map panel (or via a location).
IMatch performs reverse geocoding.
IMatch detects that the file has no destination coordinates and sets them to the created coordinates.
IMatch sets LocationCreated and LocationShown to the same values.

ACTION: User moves the file flag on the map panel.
IMatch performs reverse geocoding.
IMatch detects that the created and destination coordinates of the file are identical and sets both LocationCreated and Location Shown.

ACTION: User adds a destination marker for the file.
IMatch performs reverse geocoding.
Since created and destination coordinates for the file no longer match, IMatch does reverse geocoding for both coordinate pairs and fills LocationCreated and LocationShown independently.

TL;DR; (Summary)

1. IMatch fills LocationShown from created GPS coordinates as before, but also fills LocationCreated.

2. A file with only created coordinates is assumed to have the same coordinates for the destination (created = shown), unless the user actually adds a destination coordinate pair.

3. If the user modifies the created coordinate, IMatch ensures that the destination coordinates are matched, unless the file has destination coordinates different from the created coordinates.

4. IMatch only sets destination coordinates when there none when LocationCreated is set/modified (reverse geocoding).
This ensures that the destination coordinates are only set when needed or when not setting would cause confusion.

5. Before we often had created coordinates and LocationShown data, but no destination coordinates or LocationCreated data, unless the user set both created and destination coordinates and performed reverse geocoding.

I've created a video which shows all this in action: https://www.photools.com/bin/imatch-gps.mp4

I show how coordinates are set and how the "shown" coordinates follow the created coordinates until the user actually adds a destination coordinate.
In the second part I repeat these steps, but with automatic geocoding enabled. This makes the behavior immediately visible.

[jch2103]

This looks like a very reasonable and thorough approach to the Created and Shown location issue, and should address the big majority of use cases (no doubt someone will have a different need, but I'd think that could be easily addressed by workflow adjustments). Too bad you don't have control over the various names of location-related metadata tags!

ps - I can envision that the next related issue will be assignment of extraterrestrial coordinate systems. At first I thought this might wait until space tourism begins, but then it occurred to me that it's possible that some users (researchers for now) might already have collections of lunar or Martian images they'd want to manage via IMatch...

[Mario]

(...) some users (researchers for now) might already have collections of lunar or Martian images they'd want to manage via IMatch...

[Jingo]

Space... the final frontier!!  Good Luck Mario!!!

This is an awesome solution and the amount of thought and effort you put into this is typical Mario... we all appreciate it!!!

[thrinn]

(...) some users (researchers for now) might already have collections of lunar or Martian images they'd want to manage via IMatch...

... and then they will complain that reverse geocoding is not working. Or why the Maps panel does not show any streets...