GEO tagging issues

[vlad]

Thanks for the tips, Vlad, Mke. (You were right, vlad, about the “Do not ask me again?” box – no doubt inadvertent, because like you I don’t generally choose that).

I have now submitted FR #2907 - please support it, if you will.

Mke, I too would support the idea of an “X” button for location fields that you don’t want converted to labels. However, like vlad, I think the idea of PS keeping track of location data which you don’t want to result in labels will be too complicated – and particularly to cater for cases when you decide you did want a label after all, and it was another place that you’d meant to block.

Where a metadata location field is populated as the result of a label assignment, then if assignment of that label is revoked the metadata should surely be cleared.

Very good principle, but I doubt that PSU would currently be able to distinguish which metadata location fields (for a particular image) were populated as the result of a label assignment and which were pre-existing (say, before the image was imported in the catalog). This would require some kind of per-image metadata history (at laeast within the internal design, if not exposed to the interface) - a significant endeavour, in my opinion. Perhaps a metadata location field should always be revoked when the corresponding label is revoked.

One significant consequence of this not happening is when the wrong city (say) has been assigned. Whether that assignment is revoked or not, any subsequent assignment of a city does not lead to the metadata fields being updated.

Could you please clarify: are you talking about City label or City fields when you're mentioning assignments, revocations and subsequent assignments?

I would suggest that if a second city is assigned when the metadata city field is already occupied, then you should preferably be asked whether you want to overwrite what’s already there. This has a bearing equally on the case where a metadata location field has been populated using the GEO Tag panel or the Details panel.

Could you please provide a clarifying example?

Vlad, you say
PSU will still (silently) lookup, create and assign matching labels in the Places hierarchy whenever it reads again those IPTC/XMP values (which are now part of the image metadata)

I think this can (and should!) be avoided. Insofar as the Catalog is updated from the metadata, this should be done using the hierarchical keywords (which is how you’d re-construct the Catalog in the event of a disaster). In the case where, in the GEO Tag panel, you’ve said “don’t create a label” for a particular field (i.e. using the proposed “X”), then there’ll be no label, and the city thus won’t appear in the hierarchical (or ordinary) keywords.

Charles, I am somewhat confused. I thought you previously agreed with me that keeping location preferences per one or more images would be too complex. I am not sure: how would the “don’t create a label” setting for a particular field work in the GEO Tag panel (which is usually invoked for a image selection)?

I have found out that if, in the GEO Tag panel, something is put in the altitude field alone (i.e. no coordinates), then zero-filled latitude and longitude fields are created. These are not removed if the altitude field alone is subsequently zeroised; they remain, as does the altitude field (it contains “0/1”). A consequence of this is that if a label, for which there are coordinates, is subsequently assigned, and on the label the option “Overwrite pre-existing GEO location info” is not checked, then the coordinates are not written to the metadata – and this might go unnoticed. Currently, if the two coordinate fields are cleared, then so is the altitude field, regardless of whether there is anything in it. The issue I’ve mentioned could be avoided if the system were to remove empty/zero coordinate fields if the altitude field is cleared, or, perhaps preferable, preventing awkward people like me from using the altitude field on its own.

That seems a rather subtle issue, but if I understood you well then I agree with you. The idea being that the GEO Tag panel should offer a simple way to completely clear all GPS data, such that this could be subequently set again by assigning a label with GEO location info (even if "Overwrite pre-existing GEO location info" is left unchecked).

On a different tack, I would like to see the altitude field populated if the coordinates are supplied. If I input coordinates by hand, the system immediately (i.e. without doing a reverse lookup) moves the pin on the map to that location. The same is true if I select an image with camera-supplied coordinates (and no altitude). I don't necessarily want to do a reverse lookup. Apart from the various issues already reported, I have plenty of photos taken well away from any places named on Google’s maps (when Google will return nothing). However, Google does have global altitude information available for any pair of coordinates: if I put coordinates into the website http://mapcoordinates.net (or http://gps-coordinates.net) it finds the position on the map and is also able to display the altitude. I would like PS to pick this up.

+1 (although one could argue that a picture could be taken from the base of the Eiffel Tower, from any of its levels or even from above the tower - therefore the altitude is not uniquely determined by the (latitude, longitude) pair; not sure how Google Maps operates, but perhaps a sensible default is the Earth surface elevation at a certain point, relative to sea level)

[chuckhebert40]

Vlad, let me deal first with something I’ve got completely wrong (sorry – I’ve been getting confused by too many cases I’ve considered!).

I said
One significant consequence of this not happening is when the wrong city (say) has been assigned. Whether that assignment is revoked or not, any subsequent assignment of a city does not lead to the metadata fields being updated.

and you responded
Could you please clarify: are you talking about City label or City fields when you're mentioning assignments, revocations and subsequent assignments?

If I assign a city using the Assign panel (or the GEO Tag panel), then the photoshop:City, State and Country fields are populated (depending on label settings). If I subsequently assign a different city, then given the same label settings the new City, State and Country will replace the former photoshop fields, regardless of whether the originally assigned city has been revoked – the fields are populated based on the last assignment.

There are metadata issues related to the replacement and revocation of labels, I’ll not go into those here (they are not specifically GEO Tagging related). However, I’ll respond to your other points.

I would suggest that if a second city is assigned when the metadata city field is already occupied, then you should preferably be asked whether you want to overwrite what’s already there. This has a bearing equally on the case where a metadata location field has been populated using the GEO Tag panel or the Details panel.

Could you please provide a clarifying example?

This is merely reflecting the fact that the photoshop (etc) location fields are not bags, and although you can assign two cities (for example) to a photo, only the second one will be written to the metadata. However, on reflection I realise that getting the system to prompt the user is overkill. If you assign a different city because the previous one was incorrect, then if you do this via the Assign panel without removing the first city assigned, the fact that you have two cities assigned will be obvious in the Assign panel. If you do it by replacing the original city in the GEO Tag panel, then that causes the originally assigned city to be revoked. If you want to assign two cities (I have photos with more than one village in them), then clearly the metadata fields can’t cope – same issue as with Event.

Vlad, you say
PSU will still (silently) lookup, create and assign matching labels in the Places hierarchy whenever it reads again those IPTC/XMP values (which are now part of the image metadata)

I think this can (and should!) be avoided. Insofar as the Catalog is updated from the metadata, this should be done using the hierarchical keywords (which is how you’d re-construct the Catalog in the event of a disaster). In the case where, in the GEO Tag panel, you’ve said “don’t create a label” for a particular field (i.e. using the proposed “X”), then there’ll be no label, and the city thus won’t appear in the hierarchical (or ordinary) keywords.

Charles, I am somewhat confused. I thought you previously agreed with me that keeping location preferences per one or more images would be too complex. I am not sure: how would the “don’t create a label” setting for a particular field work in the GEO Tag panel (which is usually invoked for a image selection)?

Sorry for confusing you Vlad; I confuse myself at times! My thinking is this. Suppose you use the GEO Tag panel to specify (directly, or via a reverse lookup) a city for which there’s no Catalog label. The system asks whether you want to create a new label, and you say “no”. Because there is no label, no lr:hierarchicalSubject will be created in the metadata, and no keyword. On the assumption that the system Read preferences are set to “Merge keywords with existing Catalog labels”, and “Read hierarchical keywords (if available)”, then the absence of these will mean that no label should be created on a subsequent read of the metadata. Or am I missing something?

Earlier in this thread we touched on the question of coordinates being written to labels, and in answer to the question you asked, yes, I would only see this being done at the City level, and only in the following situations:
(i) I put in the name of a city and do a lookup to get the coordinates. If a label for that city exists, but has no coordinates, then copy the coordinates to the label (this is the same as would be achieved by doing a lookup using the label record in the Catalog – but why have to do it twice?) The same should apply where a new city label is being created.
(ii) I put in some coordinates (or they are there, from the camera) and do a reverse lookup. If this returns a city, with no more detailed location, such as a street (true in the case of the villages in many of my photos), then copy the coordinates to the label for that city. (I might, in the same village, take other pictures which have different coordinates, but as far as I’m concerned – e.g. for plotting a round-the-world trip – any coordinates that, in a reverse lookup, result in the same village are good enough)

That seems a rather subtle issue, but if I understood you well then I agree with you. The idea being that the GEO Tag panel should offer a simple way to completely clear all GPS data, such that this could be subsequently set again by assigning a label with GEO location info (even if "Overwrite pre-existing GEO location info" is left unchecked).

OK, forget the subtlety! I would just like to see the two coordinate fields, plus the altitude field, handled as a set such that they are all cleared together. Altitude on its own should not be allowed, any more than one coordinate.

one could argue that a picture could be taken from the base of the Eiffel Tower, from any of its levels or even from above the tower - therefore the altitude is not uniquely determined by the (latitude, longitude) pair; not sure how Google Maps operates, but perhaps a sensible default is the Earth surface elevation at a certain point, relative to sea level

I am happy to work on the basis that altitude refers to surface elevation, which I am sure must be what Google provides. If someone wants to record the altitude of a picture taken from a balloon or under the sea, then the altitude should be recorded elsewhere! At any event, using the Altitude field independently current clearly causes problems.

[vlad]

If I assign a city using the Assign panel (or the GEO Tag panel), then the photoshop:City, State and Country fields are populated (depending on label settings). If I subsequently assign a different city, then given the same label settings the new City, State and Country will replace the former photoshop fields, regardless of whether the originally assigned city has been revoked – the fields are populated based on the last assignment.

That makes sense: the metadata always reflects the latest assignment. (It's a good property, in my opinion.)

An interesting issue could arise, however, if Hert implements metadata clearing (update) upon label revocation. Let's say I assign the London label to an image and then I assign the Paris label to the same image. (Forget for a moment that wouldn't be very logical.) IIUC, in this case I end up with Paris in the City field and with France in the Country field (assuming parent mapping processing is enabled in the Paris label). So far, so good. But what should happen if I then unassign the France label? If the City and Country fields are simply cleared (on syncing), then I would end up with an inconsistent state: the London label is still assigned to the image, but the corresponding city and country fields are now empty in the image metadata.

(Fortunately, I believe there is a good solution at the implementation level: if one or more labels are revoked or deleted, then PSU should clear all the corresponding fields from all the corresponding images, but still leave those images as out-of-sync; once the images get write-synced again, all the label assignments still in effect will trigger the correct updating of all metadata. This would still ensure full catalog-metadata consistency for any synced image - something which I regard as an essential property in PSU.)

This is merely reflecting the fact that the photoshop (etc) location fields are not bags, and although you can assign two cities (for example) to a photo, only the second one will be written to the metadata. However, on reflection I realise that getting the system to prompt the user is overkill.

Yes, that would be overkill indeed. I personally like that PSU asks the right questions and confirmations, without being too intrusive or annoying.

If you assign a different city because the previous one was incorrect, then if you do this via the Assign panel without removing the first city assigned, the fact that you have two cities assigned will be obvious in the Assign panel. If you do it by replacing the original city in the GEO Tag panel, then that causes the originally assigned city to be revoked. If you want to assign two cities (I have photos with more than one village in them), then clearly the metadata fields can’t cope – same issue as with Event.

All the above are good remarks. I don't see much room for improvement in the case of superfluous assignments.

Sorry for confusing you Vlad; I confuse myself at times! My thinking is this. Suppose you use the GEO Tag panel to specify (directly, or via a reverse lookup) a city for which there’s no Catalog label. The system asks whether you want to create a new label, and you say “no”.

Is the prompting a hypothetical (suggested) function? I don't remembr the current system actually asking about creating a new label - IIRC, it automatically creates or not a location label, based on the global settings (that is, the base level for location processing).

Because there is no label, no lr:hierarchicalSubject will be created in the metadata, and no keyword. On the assumption that the system Read preferences are set to “Merge keywords with existing Catalog labels”, and “Read hierarchical keywords (if available)”, then the absence of these will mean that no label should be created on a subsequent read of the metadata. Or am I missing something?

Yes, you are: in addition to keywords and ICS, certain other metadata fields (such as Event, PersonInImage or location fields) could lead to automatic creation of labels, upon a read or an import.

OK, forget the subtlety! I would just like to see the two coordinate fields, plus the altitude field, handled as a set such that they are all cleared together.

+1 for the set clearing suggestion, although I don''t see any problem with each field still being independently editable (and removable) too.

Altitude on its own should not be allowed, any more than one coordinate.

Thats a stronger requirement than the previous one. I''m not sure why and how you suggest to enforce it, especially if the standard allows it. If I'm an aerial photographer or a balloon trip enthusiast, all I might care is at which altitude I'm shooting which images.

[chuckhebert40]

Thanks Vlad, for putting me straight

An interesting issue could arise, however, if Hert implements metadata clearing (update) upon label revocation.

I’ve been giving the revocation issue a bit of thought – would seem better to deal with it that under the Label revocation: findings + comments thread. (I’ll be off line for the next two weeks – time to think about it)

Is the prompting a hypothetical (suggested) function?

Sorry, yes, it is; I should have made it clear that I was picking up on the suggestion that you should be asked if you wanted to create a label when introducing a new city (etc) in the metadata. However, as you’ve pointed out, labels are created not just from reading (hierarchical) keywords. I’ve just imported an image with two names (not in the Catalog) in the Iptc4xmpExt:PersonInImage fields, and PSU created two new labels in the People category, and also two in the Miscellaneous category, presumably on the basis of the keywords in the metadata (I set PSU not to read the hierarchical keywords or ICS scheme). So, I ended up with four labels assigned – and this not ideal result reminded me that I checked this out a while ago (and reported my findings somewhere). Too much to learn – and forget.

Altitude on its own should not be allowed, any more than one coordinate.

Thats a stronger requirement than the previous one. I''m not sure why and how you suggest to enforce it, especially if the standard allows it. If I'm an aerial photographer or a balloon trip enthusiast, all I might care is at which altitude I'm shooting which images.

Yes, fine, if the standard allows it – but if you enter an altitude (only) in the GEO Tag panel, then zeroes are put in the coordinate fields, preventing coordinates on a place label being written to the metadata. If you say this is an unlikely scenario, then I’d have to agree. Nevertheless, not ideal – better, in this case, that if nothing’s been entered in the coordinate fields in the GEO Tag panel then the metadata coordinate fields are simply not created. (I’m not familiar with the standards: do coordinate fields have to be present if the altitude field is present, and vice versa? We've discussed the idea of treating the three fields as a set, in that they can all be cleared, but your balloonist might not like losing his altitude data when he clears incorrect coordinates! This is what happens now if you put zeros in the coordinate fields to clear them - you lose the altitude data also).

[vlad]

I’ve been giving the revocation issue a bit of thought – would seem better to deal with it that under the Label revocation: findings + comments thread. (I’ll be off line for the next two weeks – time to think about it)

I agree with trying to stay on topic (although the topics do overlap). I am looking forward to your revocation thoughts, whenever you are able to write them. Happy travels meanwhile!

I’ve just imported an image with two names (not in the Catalog) in the Iptc4xmpExt:PersonInImage fields, and PSU created two new labels in the People category, and also two in the Miscellaneous category, presumably on the basis of the keywords in the metadata (I set PSU not to read the hierarchical keywords or ICS scheme). So, I ended up with four labels assigned – and this not ideal result reminded me that I checked this out a while ago (and reported my findings somewhere).

That's definitely not good (although the not ideal result could be manually fixed by merging the labels, as needed). I guess the PersonInImage reading should take precedence over the simple keyword reading. It would be interesting to test what would happen if you turned on the reading of hierarchical keywords. (I forgot, is there a special setting for that?) In my view, the hierarchical keyword reading should take the highest precedence (or maybe the 2nd highest after ICS reading), since hierarchical keywords allow PSU to unambiguosly recreate the full label path. (That's why they are highly recommended, btw.)

Too much to learn – and forget.

Indeed. But I think that reporting specific issues or suggestions in Mantis could help, because we - and Hert - could then easier track them.

Yes, fine, if the standard allows it – but if you enter an altitude (only) in the GEO Tag panel, then zeroes are put in the coordinate fields, preventing coordinates on a place label being written to the metadata. If you say this is an unlikely scenario, then I’d have to agree. Nevertheless, not ideal – better, in this case, that if nothing’s been entered in the coordinate fields in the GEO Tag panel then the metadata coordinate fields are simply not created. (I’m not familiar with the standards: do coordinate fields have to be present if the altitude field is present, and vice versa? We've discussed the idea of treating the three fields as a set, in that they can all be cleared, but your balloonist might not like losing his altitude data when he clears incorrect coordinates! This is what happens now if you put zeros in the coordinate fields to clear them - you lose the altitude data also).

Your remarks may warrant one or more Mantis tickets too.

[ColinD]

Hi, there are four images in my collection that have adopted Geo-location entries that place them in the US but were taken in Australia with non-GPS enabled cameras. I have been trying to delete the data but it keeps coming back. I have tried selecting the thumbnail and clicking the x beside either latitude or longitude, clicking OK to the warning that it will delete the info then clicking OK; I have tried using the batch process with GPS remove and all with no success.
Win 10 pro 64-bit
Thanks for any help.

[vlad]

Hi ColinD, do you have catalog labels assigned to those four images? Check to see if any assigned label (especially in the Places hierarchy) has embedded GPS data. (Open the label details and look for the Geo Location section.)

Hope that helps,
Vlad

[ColinD]

Thanks Vlad, yes there were catalog labels assigned but not by me, just seems a random thing. So far I can't clear these either. I wonder why this was done to just four images all taken over widely different times and different cameras.

[vlad]

Hi Colin, check if those four images have location metadata written to them - and if the location values match the assigned label names. (If yes, then you could try to manually remove the location metadata as well as delete the assigned labels.)

[ColinD]

Thanks for your help Vlad, all good now.

[fbungarz]

Reading through this lengthy discussion, I am surprised nobody asked this question:
Why not simply have an option to create labels from the Geo-Panel Favorites which from then on would then apply the Geo-Panel fields via "Apply Detail Profile" automatically?

To illustrate what I am talking about. This is photo of a favorite hostal in Quito with the Geo-Panel saved as a favorite:

Arupo_Geo-Panel.jpg (305.75 KiB) Viewed 9756 times

Here is the same photo with its name as a label. That label can already be configured to write coordinates and fill in certain fields via "Apply Detail":

Arupo_Label.jpg (262.95 KiB) Viewed 9754 times

For me the obvious would be: in the Geo-Panel add an option to save the "Geo-Favorites" as a specifically configured label with the geo-coordinates and the relevant fields filled in.

This would be a powerful way to quickly geotag and at the same time not loose control of the process.

[vlad]

For me the obvious would be: in the Geo-Panel add an option to save the "Geo-Favorites" as a specifically configured label with the geo-coordinates and the relevant fields filled in.

On the surface, your suggestion opens a bunch of questions and seems to add complexity:

- Where should Hostal Arupo be created as a label? what happens if Ecuador and/or Quito are not yet in your hierarchy - should they be created (and configured) automatically as well?

- Your 2nd screenshot suggests automatically filling the location metadata in the detail profile associated to the label, but I might prefer them filled in via the GEO Location section + the Mapped to... field; and then, there are additional alternatives regarding the label setup: should it toggle Process parent mapping or Also assign its parent? (Otherwise, the parent mappings for the city or country would not be automatically applied when Hostal Arupo is assigned.)

On reflection, I guess the label creation policy for GEO favorites could simply follow the current policy for Geo Location processing - and that policy, in turn, could be further tweaked by the user if FR #3020 (and/or #2844) is implemented.

This would be a powerful way to quickly geotag and at the same time not loose control of the process.

If you geotag some image (by either entering the details manually or picking up a GEO favorite), then you could already convert that metadata to labels, based on your GEO Location processing setting. Am I missing something?

[fbungarz]

Hi Vlad,
sorry for not being clear on this. I am not suggesting to do all of this fully automatic!
What I suggest is this:
(1) create favorite with the an option that says "also create Geo-label from favorite"
(2) alternatively add a separate option to the GEO Panel that says: create Geo-label" [personally I would actually prefer that second option, after a while the list of favorites gets cluttered, much too long and the much better logical alternative would be to create Geo-labels right away, but since favorites already exists and people would likely complain if it was removed...]
anyway...
(3) the create new label dialog now pops up (like it would, when you create a new label in the label panel)
(4a) well, I guess the label could per default be created as a place below "city-country-places",
BUT as you say - this adds unnecessary complexity, so I for simplicity as well as flexibility I would actually prefer this:
(4a) alternatively the default parent would simply be your last choice when you did create your last new label; that is what happens right now, when you create any new label via the label panel. You then have to manually place that label where it belongs, say for example I create a label called "test", this is what pops-up:

New_Label_last_setting.jpg (280.43 KiB) Viewed 9743 times

Obviously "test" is not a lichen called "Lecanactis", it is simply the last parent I used, so now I manually need to change this parent...

(5) the new label would per default get the name of the "location"field (also with the option to simply change it, as I can still change any other label name in that dialog box). Per default the fields from the Geo-Panel and the coordinates would filled in: Location, City, State/Province, Country Code, Country + longitude, latitude & altitude

...should it toggle Process parent mapping or Also assign its parent? (Otherwise, the parent mappings for the city or country would not be automatically applied when Hostal Arupo is assigned.)

NO, no need to toggle anything! We are not talking about assigning parents, not talking about mapped labels but labels that apply a Detail Profile; i.e., one label that fills in all the fields from the Geo-Panel all at once! Have a looka again at the screenshot.

AND, even better: you already can tweak any label any way you want right now! Nobody prevents you from doing this tweaking manually for these labels too. Anything field that is being filled in from the Geo-Panel, you can still change, either during the time when the label is created or at any time later. I do that with my labels all the times...

On reflection, I guess the label creation policy for GEO favorites could simply follow the current policy for Geo Location processing - and that policy, in turn, could be further tweaked by the user if FR #3020 (and/or #2844) is implemented.

As much as I would LOVE to see label templates getting implemented, storing favorites as labels would probably be a lot less complicated and could likely be implemented fairly quickly. So, I'll take that for now, while waiting for the big things happen later...


Cheers,
Frank

[fbungarz]

If you geotag some image (by either entering the details manually or picking up a GEO favorite), then you could already convert that metadata to labels, based on your GEO Location processing setting. Am I missing something?

You are, IF you have that option enabled. I do not. Why? My Places hierarchy does NOT correspond with PSu's (or Google's) default. And enabling that option would thus create duplicate labels that I do not want...

Having the option enabled creates this:
PLACES::South America:Ecuador::Pinchincha::Quito

In my case I do have tons of images like this:
PLACES::Continents::South America:Ecuador::Pinchincha::Quito

That is because I created this hierarchy long before PSu came along. Also, I do have quite a few other things below the "Places" category, like informal regions, for example the "Sonoran Desert", the "Andes", i.e., geographic regions that do not correspond to political ones, e,g.:
PLACES::Regions::Sonoran Desert
or
PLACES::Borders::Polish-German Border
or
PLACES::Historic Places::German Democratic Republic
(ironically there was even a recent post asking about where to best place England after the Brexit: http://forum.idimager.com/viewtopic.php?f=57&t=24281)
etc.

For me, having the option to manually create and tweak these labels would greatly enhance the flexibility. There is a tendency these days to make computers do everything for you.
To give you another example: The Getty Thesaurus treats Galapagos as a province of Ecuador, which it is, but this archipelago has more than a hundred islands, we imported them all into the catalog, however, for convenience grouped them into "island groups". These groups essentially are the larger, main islands with their "satellites" around them. However, Getty also treats the whole archipelago as "island group"; this is in conflict with how we use the "island groups" of the Galapagos.

Basically, what I am saying is: Much about the discussion here has be about Google not always getting it right, some suggestions which other repositories of geographic names might be better, etc. etc.
The point is: nobody gets it right all the time. But at least the user, who took a photo has been just there. He probably knows better than Google or anyone else, how to best set up the labels under place names. My suggestion thus is about adding flexibility and customization...

[vlad]

In my case I do have tons of images like this:
PLACES::Continents::South America:Ecuador::Pinchincha::Quito

I guess you could merge Places::Continents::South America with Places::South America.
But maybe you even shoudn't have to do this, but rather (have a way to) instruct PSU to look for the continent level under Places::Continents rather than Places. (Feel free to add a note to FR #3020.)

(ironically there was even a recent post asking about where to best place England after the Brexit: http://forum.idimager.com/viewtopic.php?f=57&t=24281)

To me, the issue is moot, as long as one doesn't use a European Union label. (Wisely, the default hierarchy does not ship with any such label.) I hope we can agree that UK (including England) remains in Europe, even if it leaves the EU.

For me, having the option to manually create and tweak these labels would greatly enhance the flexibility.

You already have the options to:
1) Manually create and tweak labels in your hierarchy
2) Manually edit and tweak geodata, including the details returned by Google or some other service

What's indeed missing is a way to tweak the algorithm which processes the geo metadata and turns it into labels.

There is a tendency these days to make computers do everything for you.

Yep - and that's not always good.

Basically, what I am saying is: Much about the discussion here has be about Google not always getting it right, some suggestions which other repositories of geographic names might be better, etc. etc.

The point is: nobody gets it right all the time. But at least the user, who took a photo has been just there. He probably knows better than Google or anyone else, how to best set up the labels under place names. My suggestion thus is about adding flexibility and customization...

Right - but the question is whether you want your own label names for places to match the geo metadata in your images. If you do, then I would suggest that automatic GEO Processing could still become helpful to you, provided that the algorithm for pairing location metadata with labels inside Places gets improved (i.e., becomes more flexible). I'm all for providing specific suggestions on that, btw.

Regarding label templates (#2844): that's indeed a complex feature to design (let alone implement), but additional settings for locations (#3020) could be delivered much faster, imho.