GEO tagging issues

[chuckhebert40]

I have been identifying the location (places and coordinates) of some pictures of Nepal, and encountered a few issues.

(1) In the GEO Tag panel I set City = “Namche” and then did a lookup to get the coordinates. These were different from the coordinates on another picture, also with City = “Namche”. I realised that for the earlier picture I’d original put in City = “Namche Bazar”.

Nepalese towns are evidently stored in in Google maps along with an area plus a number (a sort of zip code), as can be seen by looking up towns in Google maps (i.e. outside PSU): e.g. Namche Bazar, Namche 56000; Ghunsa, Lelep 57600. Where the town and the area are synonymous there is only one entry: Jiri 45500; Manang 33500.
If, in the GEO Tag panel of PSU, I put in “Jiri” there is no problem. However, when I put “Namche Bazar” into PSU and do a lookup, it correctly returns the coordinates of Namche Bazar, and the map shows a pin on Namche Bazar, but the City in the GEO Tag panel gets changed to “Namche” – the name of the area. This explains how I come to have two photos with City = "Namche" but with different coordinates. If I set City = “Ghunsa” I get the correct coordinates, but the City field gets changed to “Lelep” - which at least is noticeable.

This is clearly not a satisfactory situation. In the first place, I don’t want the City name changed, and secondly, the area name (e.g. Lelep) appears effectively to be in a random location (just as the name of a USA state would appear wherever is convenient on a map). I imagine this problem is to do with Google’s GEOTagging rather than with PSU, and in this instance relates to Nepal, which maybe won’t bother too many people. However, I think it worth mentioning in case anyone is encountering strange coordinates in other countries.

(2) My researches in connection with the foregoing threw up another problem:

In the PSU GEO Tag panel I set City = “Shank”, and Country = “Pakistan”. When I did a lookup the correct coordinates were returned, and the pin on the map was correctly located, but the fields City, Country Code and Country were all cleared. I had the same result with “Usina”,” Para” [State], ”Brazil”, and with “Letheringsett”, “United Kingdom”. Whether this is Google, or an interface issue, I don’t know, but it’s not right!

Two other issues are more clearly PSU-related:

(3) I filled in the City field (with a town name) and set Country = Nepal. The system came back with the wrong details (many place names are repeated in Nepal). I can delete the City and State/Province, but there seems to be no way of deleting the coordinates in the GEO Tag panel, nor in the Details panel (where it seems I can delete almost everything else). How can I delete Latitude & Longitude?

(4) Having put information in the GEO Tag panel and done a lookup, the Catalog gets updated automatically; this is out of line with the Details panel, where I have to click the “Apply” button (or answer a question about whether I want to update the Catalog, if I move away from the photo in question). The “Apply” button thus appears to be redundant on the GEO Tag panel. Apart from the inconsistency within PSU, it is additionally annoying because of the previous point – having been given the wrong coordinate information I can’t get rid of it! I would prefer it if, having done a lookup (or a reverse lookup), you had to click the "Apply" button to cause any updating to take place.

I've also noticed that if I type "GBR" in the Country Code it is ignored - I have to use the lookup. This is a bit of a pain (the UK being off the bottom of the screen!). I would prefer the system to accept a typed Country Code.

POSTSCRIPT: I've just put "Sete, Nepal" into Google and got some hits about trekking there. That's OK. I then clicked on Maps, and got a map showing le Namasté [restaurant], 84 Grande Rue Mario Roustan, 34200 Sète in France. Not daunted by this, I put City = "Sete" into the GEO Tag panel, and selected Nepal as the country. The result:- Location = "Nepal", City = "Manzanillo", State/Province = "Colima", Country = "Mexico", with Manzanillo pinpointed on the map.

Sete clearly isn't on Google maps. I'd rather it just said the place couldn't be found!

[vlad]

In the PSU GEO Tag panel I set City = “Shank”, and Country = “Pakistan”. When I did a lookup the correct coordinates were returned, and the pin on the map was correctly located, but the fields City, Country Code and Country were all cleared. I had the same result with “Usina”,” Para” [State], ”Brazil”, and with “Letheringsett”, “United Kingdom”. Whether this is Google, or an interface issue, I don’t know, but it’s not right!

I agree.

I can delete the City and State/Province, but there seems to be no way of deleting the coordinates in the GEO Tag panel, nor in the Details panel (where it seems I can delete almost everything else). How can I delete Latitude & Longitude?

For a single image: open the GEO Tag panel -> go to the map marker -> right-click -> Delete.
For one or multiple images: you could run a batch with the GEO Remove command.

It certainly would be good if there was a (simple) way to clear up the GPS coordinates + (optionally) the location fields via the GEO Tag panel, whether for one image or for multiple images at the same time.

(4) Having put information in the GEO Tag panel and done a lookup, the Catalog gets updated automatically; this is out of line with the Details panel, where I have to click the “Apply” button (or answer a question about whether I want to update the Catalog, if I move away from the photo in question). The “Apply” button thus appears to be redundant on the GEO Tag panel.

How did you conclude that? It doesn't match my experience.

Apart from the inconsistency within PSU, it is additionally annoying because of the previous point – having been given the wrong coordinate information I can’t get rid of it! I would prefer it if, having done a lookup (or a reverse lookup), you had to click the "Apply" button to cause any updating to take place.

Unless I'm missing something, your preference is already implemented.

POSTSCRIPT: I've just put "Sete, Nepal" into Google and got some hits about trekking there. That's OK. I then clicked on Maps, and got a map showing le Namasté [restaurant], 84 Grande Rue Mario Roustan, 34200 Sète in France. Not daunted by this, I put City = "Sete" into the GEO Tag panel, and selected Nepal as the country. The result:- Location = "Nepal", City = "Manzanillo", State/Province = "Colima", Country = "Mexico", with Manzanillo pinpointed on the map.

Sete clearly isn't on Google maps. I'd rather it just said the place couldn't be found!

I guess that's a problem with overzealous guessing: applications these days insist on offering you some suggestions (false positives) even when these partially or loosely match the query rather than coming up empty handed (false negatives).

[Hert]

In addition to Vlad's reply; it's also possible to enter a 0 in the input fields to clear them.

About the wrong lookup info; PSU uses GoogleMaps for the lookups. If the information returned for certain coordinates is incorrect then you can report that to Google as I have no control over what's right and what's wrong. And if you're using an early PSU-V2 version then the lookups take place may go through GeoNames instead of Google Maps, which offered less accuracy in exotic locations; hence why PSU later switched to GoogleMaps for that.
Based on your other comments I've got the impression that you're not using the latest version? http://whatsnew.idimager.com

[chuckhebert40]

Thanks Vlad, Hert, for responding.

For deleting the coordinates it wouldn’t have (didn’t!) occur to me to delete the map marker. The obvious thing I would have thought is to allow them to be highlighted and then deleted (in the GEO Tag panel or in the Details panel). I did subsequently stumble on the insertion of zero – despite 0, 0 being a legitimate location, even if one that's unlikely to be of interest.

I’ve just checked the updating issue. In folder view I selected photo A, which had no location data, no assigned categories, etc. I opened the GEO Tag panel and put in a City (new – not one I’ve used before), selected Nepal as the Country, and then hit the lookup button. This returned the State/Province (also one I haven't used before), and the coordinates. I then went to a different folder and selected a photo (B). I was not asked whether I wanted to save the GEO data. I closed PSU, then reopened it. PSU was (of course) showing photo B. I returned to photo A, and there in the GEO Tag panel were the coordinates. I could also see these in the Details panel (XMP Advanced, exif section). Going to the Assign panel I could that the city had been assigned, and in the Category view I could see that under Places/Asia/Nepal the State had been added, and under that the City. The GEO data has clearly been retained, although at no stage did I use the Apply button, nor was I asked whether I wished to retain or discard the data. [If I clear the GEO data, e.g. by choosing Delete on the map pin, then if I move away from the picture I am asked if I want to discard the data].

Incidentally, is there any reason why the coordinates shouldn't be written to a new City label that's created?

I’m using PSU v 3.1.1.3070, which appears to be the latest build.

As regards reporting incorrect coordinates to Google, yes, I can do that, Hert. However, when it comes to “Namche Bazar” being replaced in the GEO Tag panel by “Namche” after doing a lookup, or the City, State & Country fields being erased completely in the GEO Tag panel, I can’t tell whether that is a problem with Google Maps or in PSU. [The correct coordinates are returned for “Namche Bazar”, so it is obvious that “Namche Bazar” is correctly used by Google Maps, and it is after this has been done that “Namche Bazar” in the City field gets replaced by “Namche” – is that an interface issue? At any event, I don't think it should be replaced - Google doesn't necessarily know better!].

My ‘postscript’ example might be a bit bizarre, but given that I get completely different results using Google Maps direct on the one hand, and going via PSU on the other does prompt me to wonder whether there is an interface issue between PSU & Google Maps.

[vlad]

For deleting the coordinates it wouldn’t have (didn’t!) occur to me to delete the map marker.

I agree, it's one of those hidden features.

I’ve just checked the updating issue. [...] The GEO data has clearly been retained, although at no stage did I use the Apply button, nor was I asked whether I wished to retain or discard the data. [If I clear the GEO data, e.g. by choosing Delete on the map pin, then if I move away from the picture I am asked if I want to discard the data].

Ok, I know what happens: the asking dialog for "Apply changes?" has a "Do not ask me again" option - so I'm pretty sure you must have checkmarked that in the past. You will most likely see again the asking dialog for applying new coordinates if you invoke the action: Help -> Reset "Don't ask again" questions. (Obviously, this may restore other confirmation dialogs too.)

FWIW, I tend to ignore the "Don't ask again" options because I'm afraid I might get confused in the future about some behavior being silently applied (or ignored) - yours is a case in point. An interface improvement I might suggest in Mantis is to preserve the "Don't ask again" options, but to add a new category (Action Confirmations) to Tools -> Preferences, which would allow us to see and change which specific actions are currently set to trigger confirmation dialogs. What do you think?

Incidentally, is there any reason why the coordinates shouldn't be written to a new City label that's created?

You are talking about the consequence of a GEO lookup based on the City input, right? (If the lookup key also includes the Location field, then the GPS coordinates may arguably apply only to that particular location.) I would likely be happy with that. I remember Hert saying that GPS coordinates are not very useful for a whole city or area - but I think that judgement should be left up to each of us. (For a round-the-world trip, even some approximate coordinates are arguably better than none at all.) If I'm doing a lookup based only on the City field, then I'm presumably looking for some representative (approximate) coordinates - and, yes, why shouldn't this get reflected in the new City label? (As a matter of fact, a lookup invoked from the GEO section of the label details panel fills in even the Radius field, so I guess that value could be filled in via the GEO Tagging panel too.)

As regards reporting incorrect coordinates to Google, yes, I can do that, Hert. However, when it comes to “Namche Bazar” being replaced in the GEO Tag panel by “Namche” after doing a lookup, or the City, State & Country fields being erased completely in the GEO Tag panel, I can’t tell whether that is a problem with Google Maps or in PSU. [The correct coordinates are returned for “Namche Bazar”, so it is obvious that “Namche Bazar” is correctly used by Google Maps, and it is after this has been done that “Namche Bazar” in the City field gets replaced by “Namche” – is that an interface issue? At any event, I don't think it should be replaced - Google doesn't necessarily know better!].

Well, a lookup doesn't only find the matching coordinates (via Google Maps) - it may also fill out other GEO fields, such as Country or State/Province. (@Hert: does that happen also via Google Maps, or rather via Geonames?)

I highly doubt that PSU overwrites the City field on its own initiative, I think it's a side effect of the underlying lookup service. If I'm correct, then the proper question is whether PSU should implement a special check and force the preserving of the input geo fields whenever the lookup result includes some changed field(s)? Perhaps, but I'm not entirely sure - I'd be interested in Hert's take on this.

Charles, do you know that I have also noted a number of surprising or odd things about GEO locations in a different thread? Perhaps we could come up with a useful summary, based on our shared experiences. (I'm a bit surprised that no one else has jumped in, given that other people use GEO features too.)

Regards,
Vlad

[Mke]

(I'm a bit surprised that no one else has jumped in, given that other people use GEO features too.)

Well, if you insist

I do use Geo tags, but normally using the GPX track feature + some manual adjustment.

Like you, I've found that reverse lookup via Google isn't always reliable (Google's problem, no doubt, not PSU's) and it can lead to the creation of additional locations being added to the catalog that I don't want - so I rarely use reverse lookup. If I do use it, then it would normally be to tag an item in the catalog, which I'd check and hand-edit if necessary, before applying it as a label to the images.

I guess an improvement that would encourage me to use reverse lookup more, would be for PSU to not automatically go ahead and create new catalog items based on the reverse lookup results, but to ask "would you like to add these location items to the catalog?" If I select 'no' then it would just write the reverse lookup data (with the option of editing it, of course) to the IPTC and XMP fields. That would at least mean that you could avoid your Places::Netherlands::Rotterdam / Places::Netherlands::Zuid-Holland::Rotterdam issue, Vlad.

[vlad]

Mke, thanks for chiming in. A couple of comments:

1. There are some oddities not only with the reverse lookup (based on input coordinates), but also with the regular lookup (based on some input field(s)). Charles has provided a good example: pick an image without any GEO info, open the GEO Tag panel, type 'Namche Bazar' in the City field and perform a lookup: it will find the GPS coordinates, but also change the City field value to 'Namche'. That may not be desirable.

2. Asking the user if (s)he wants to create new catalog labels based on the reverse lookup results would not necessarily help, because PSU could still subsequently read the new IPTC/XMP location fields and then create matching catalog labels (without confirmation). And I don't think the policy of matching location labels to IPTC/XMP location fields should be configurable per image(s) (although it could be configured per category or per label (tree), via label templates) - that would be way over the top, IMHO!

Instead, the location field-label matching algorithm should be improved, e.g. the City field Rotterdam should be able to match the existing label Places::Netherlands::Rotterdam even when the State/Province field (Zuid-Holland) is present. Perhaps, in that case, PSU should be smart enough to create the Zuid-Holland label under Places::Netherlands (as it already does) and then relocate (upon confirmation?) the Places::Netherlands::Rotterdam label under Places::Netherlands::Zuid-Holland? Does that make sense? Any drawbacks?

[Mke]

1. There are some oddities not only with the reverse lookup (based on input coordinates), but also with the regular lookup (based on some input field(s)). Charles has provided a good example: pick an image without any GEO info, open the GEO Tag panel, type 'Namche Bazar' in the City field and perform a lookup: it will find the GPS coordinates, but also change the City field value to 'Namche'. That may not be desirable.

Yes it does indeed do that, generated by Google too, no doubt - not desirable, but at least you can edit the fields if you don't like what Google returns. To avoid Google (and all the location fields) you can right click on the map and put the city name into the 'Search' field (which then fills in none of the location fields)

2. Asking the user if (s)he wants to create new catalog labels based on the reverse lookup results would not necessarily help, because PSU could still subsequently read the new IPTC/XMP location fields and then create matching catalog labels (without confirmation). And I don't think the policy of matching location labels to IPTC/XMP location fields should be configurable per image(s) (although it could be configured per category or per label (tree), via label templates) - that would be way over the top, IMHO!

Not a problem if PSU doesn't subsequently read the new IPTC/XMP location fields and then create matching catalog labels (without confirmation). Other than having to make the selection on initial input, of course.

Instead, the location field-label matching algorithm should be improved, e.g. the City field Rotterdam should be able to match the existing label Places::Netherlands::Rotterdam even when the State/Province field (Zuid-Holland) is present.

I'd support that, but I imagine that it's Google that does the matching, not PSU, so them you'd need to talk to...

Perhaps, in that case, PSU should be smart enough to create the Zuid-Holland label under Places::Netherlands (as it already does) and then relocate (upon confirmation?) the Places::Netherlands::Rotterdam label under Places::Netherlands::Zuid-Holland? Does that make sense? Any drawbacks?

That would be cool, but I can imagine that people would want more than these two options. What if you want Places::Netherlands::Zuid-Holland under Places::Netherlands::South-Holland? Or what if you want Places::Poland::Lodz to be under Places::Poland::Lodz Province::Lodz or Places::Polska::województwo łódzkie::Łódź instead of Places::Poland::Łódź Voivodeship::Lodz? I think you'd need a manual editing option of some kind, rather than expecting PSU to do it fully automatically.

Either way though, for any automatic / semi-automatic solution, I imagine that would require PSU to hold a new database table of 'Google Geo location overrides' that it would need to check with after if it does a lookup / reverse lookup, so that it knows how write the location to the catalog.

[vlad]

To avoid Google (and all the location fields) you can right click on the map and put the city name into the 'Search' field (which then fills in none of the location fields)

Excellent point. Thanks for the tip (reminder).

2. Asking the user if (s)he wants to create new catalog labels based on the reverse lookup results would not necessarily help, because PSU could still subsequently read the new IPTC/XMP location fields and then create matching catalog labels (without confirmation). And I don't think the policy of matching location labels to IPTC/XMP location fields should be configurable per image(s) (although it could be configured per category or per label (tree), via label templates) - that would be way over the top, IMHO!

Not a problem if PSU doesn't subsequently read the new IPTC/XMP location fields and then create matching catalog labels (without confirmation). Other than having to make the selection on initial input, of course.

Well, I think that PSU always reads and matches the IPTC/XMP location upon any subsequent change affecting the image. Are you suggesting that you're not concerned about such scenarios (subsequent changes) - or that PSU should never create new location labels for certain image(s) and/or location fields? To me, the later suggestion seems almost inconceivable, as it would require per image or per field policies, right? (I'm sure it could be implemented, but it would be a nightmare in terms of complexity.)

Instead, the location field-label matching algorithm should be improved, e.g. the City field Rotterdam should be able to match the existing label Places::Netherlands::Rotterdam even when the State/Province field (Zuid-Holland) is present.

I'd support that, but I imagine that it's Google that does the matching, not PSU, so them you'd need to talk to...

Google only matches GPS coordinates or partial location info to full location info - but it's PSU that eventually matches that info to catalog labels, right?

(Don't forget that PSU is already more geo-sophisticated that some people realize; for example, IIRC it can automatically assign place labels at import time not only based on prior location fields, but also by comparing GPS coordinates in geo-tagged images vs. GPS+Radius info specified in catalog labels. With a bit (or a lot) more work, the GEO support in PSU could become state of the art.)

Perhaps, in that case, PSU should be smart enough to create the Zuid-Holland label under Places::Netherlands (as it already does) and then relocate (upon confirmation?) the Places::Netherlands::Rotterdam label under Places::Netherlands::Zuid-Holland? Does that make sense? Any drawbacks?

That would be cool, but I can imagine that people would want more than these two options. What if you want Places::Netherlands::Zuid-Holland under Places::Netherlands::South-Holland? Or what if you want Places::Poland::Lodz to be under Places::Poland::Lodz Province::Lodz or Places::Polska::województwo łódzkie::Łódź instead of Places::Poland::Łódź Voivodeship::Lodz? I think you'd need a manual editing option of some kind, rather than expecting PSU to do it fully automatically.

These are excellent points, but I don't think it's necessarily reasonable to request both of the following:
1) reliable support for automatic matching (both on reading and on saving location metadata).
2) reliable support for overriding (user-specified) label-metadata mappings

Even if the above could be implemented, that's getting too complicated IMO. Overall, I think that the existing design (automatic label creation & assignment based on exact string matching + global setting w.r.t. location level matching) is very good and fairly simple to grasp. Come to think of it, why would you really want to have województwo łódzkie and Łódź' in the location fields, but Łódź Voivodeship and Lodz as catalog labels or as keywords? (Well, I could see reasons, but still...)

The refinement I suggested about the state/province info was simply meant to avoid the need of worrying about catalog labels for that level - but perhaps that's not worth implementing either. (For a start, I might be happy even with a simple 'X' button for each location field (inside the GEO Tag panel), such that I could quickly clear up one or more values returned by a lookup or reverse lookup.)

Just wondering: wouldn't the support for alternative geo services (in addition to Google Maps) offer the biggest bang for the buck? Does anyone know which other public services are available and how do they compare to Google?

Either way though, for any automatic / semi-automatic solution, I imagine that would require PSU to hold a new database table of 'Google Geo location overrides' that it would need to check with after if it does a lookup / reverse lookup, so that it knows how write the location to the catalog.#

I understand what you're saying and I am sure it could be implemented - but, again, I'm not sure it's worthwhile.

[vlad]

Just wondering (as I'm too lazy to check right now): does the current label-field matching algorithm already take label synonyms into account? That would allow, for example, the City field Łódź to match the Places::Poland::Lodz Province::Lodz label, assuming Łódź is already in its synonym list.

(Well, I guess the Poland label should also have Polska as a synonym, Lodz Province should have the polish variant(s) too etc.; of course, it would be even better if the Google lookup service was able to suggest a list of synonyms - i.e., alternative names - that could be used by Photo Supreme and by each of us; this way the 1:1 name matching rule could become somewhat more flexible, at least for existing labels. Feel free to call it the poor man's custom geo database. )

[Mke]

Well, I think that PSU always reads and matches the IPTC/XMP location upon any subsequent change affecting the image. Are you suggesting that you're not concerned about such scenarios (subsequent changes) - or that PSU should never create new location labels for certain image(s) and/or location fields?

I'm not sure whether or when PSU would automatically check and refresh IPTC/XMP location data for a catalogued image, but I can't think of an obvious reason why it would need to do so, because locations tend not to move much
OK, I'm being facetious; it's true that the borders and names of political entities do change from time-to-time, but normally very rarely. So I'd be a little surprised if PSU really does refresh these without manual intervention. But I'm prepared to be surprised.

Google only matches GPS coordinates or partial location info to full location info - but it's PSU that eventually matches that info to catalog labels, right?

My impression is that so far as lookups and reverse lookups are concerned (which, as mentioned in my earlier post, I tend not to use much - due to some of the reasons being discussed here) PSU writes what Google tells it to. Of course PSU can do matching based on existing geo data from items in the catalog, but that data would probably have originated at some point from a Google lookup / reverse lookup too, unless manually input or imported with the images from some other software. As before though, I could be wrong...

These are excellent points, but I don't think it's necessarily reasonable to request both of the following:
1) reliable support for automatic matching (both on reading and on saving location metadata).
2) reliable support for overriding (user-specified) label-metadata mappings
Even if the above could be implemented, that's getting too complicated IMO.

I'd certainly be delighted to see reliable automatic matching, but if the problem originates with Google, as I suspect, PSU would need to ask for user assistance. And then remember what it had been told, so that you don't have to manually make the change for every subsequent image sharing the same location.

Come to think of it, why would you really want to have województwo lódzkie and Lódz' in the location fields, but Lódz Voivodeship and Lodz as catalog labels or as keywords? (Well, I could see reasons, but still...)

My point is actually the opposite - sorry for not being clearer. I'd want the location fields, catalog lables and keywords to match, but I wouldn't necessary want them all to match what Google thinks is right.
In this particular case Google thinks (or rather PSU says that Google thinks) that Places::Poland::Lódz Voivodeship::Lodz is right.
Not being Polish, I'd probably prefer my location fields, catalog lables and keywords to say Lodz Province, not Lódz Voivodeship. Especially as PSU can't search on those diacritics (Mantis #2773 )
Others (especially Poles) might prefer the Polish version - województwo lódzkie - to Goggle's version.

I might be happy even with a simple 'X' button for each location field (inside the GEO Tag panel), such that I could quickly clear up one or more values returned by a lookup or reverse lookup.)

Well, at least we can agree on that one! And maybe an 'X' button against the latitude & longitude too.

There's some details on Google's API at https://developers.google.com/maps/docu ... ding/intro which might turn up something useful - I've had a quick look and the bit that caught my eye was "the geocoder may return several results when address queries are ambiguous" - that may perhaps apply to the areas of Nepal (and similarly remote areas of the UK like Letheringsett!) that kicked off this discussion?

[vlad]

Well, I think that PSU always reads and matches the IPTC/XMP location upon any subsequent change affecting the image. Are you suggesting that you're not concerned about such scenarios (subsequent changes) - or that PSU should never create new location labels for certain image(s) and/or location fields?

I'm not sure whether or when PSU would automatically check and refresh IPTC/XMP location data for a catalogued image, but I can't think of an obvious reason why it would need to do so, because locations tend not to move much

Mke, there's a misunderstanding. You now appear to be solely focused on the IPTC/XMP location fields (as filled in with values returned by Google), although we've been also talking about the catalog labels that are assigned (and created, if needed) based on those fields. Of course, PSU won't refresh the IPTC/XMP location data by itself - but it's a different matter with the catalog labels in the Places hierarchy (and that's what I'm talking about)!

IIUC, you suggested that the Geo Tag panel should ask the user (upon pressing Apply) whether he wants to create and assign catalog labels for the filed in location values (whatever they are - they may even be filled in by hand, not by Google). Let's say the user is pressing No: this would write the location values to the corresponding IPTC/XMP fields, but it would not lookup and assign matching catalog labels at that point. So far, so good. (That's what you wanted, right?)

However, my point is that 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). That may happen, for example, in case of a Read Metadata operation, or even in case of Save Metadata or automatic write-sync (for a concrete example, see point 6 in my post here). To conclude, the user's input ("do NOT create and assign catalog labels for the IPTC/XMP location data in this image") would have momentary effect - but it would not necessarily stick.

Are we on the same page now?

Google only matches GPS coordinates or partial location info to full location info - but it's PSU that eventually matches that info to catalog labels, right?

My impression is that so far as lookups and reverse lookups are concerned (which, as mentioned in my earlier post, I tend not to use much - due to some of the reasons being discussed here) PSU writes what Google tells it to. Of course PSU can do matching based on existing geo data from items in the catalog, but that data would probably have originated at some point from a Google lookup / reverse lookup too, unless manually input or imported with the images from some other software. As before though, I could be wrong...

You're not wrong, we're just looking at it from opposite ends: you're talking about how location fields are filled in (from Google lookups or from PSU labels with embedded GEO info), while I'm talking about how PSU matches and assigns catalog labels within Places, based on input IPTC/XMP data.

These are excellent points, but I don't think it's necessarily reasonable to request both of the following:
1) reliable support for automatic matching (both on reading and on saving location metadata).
2) reliable support for overriding (user-specified) label-metadata mappings
Even if the above could be implemented, that's getting too complicated IMO.

I'd certainly be delighted to see reliable automatic matching, but if the problem originates with Google, as I suspect, PSU would need to ask for user assistance. And then remember what it had been told, so that you don't have to manually make the change for every subsequent image sharing the same location.

Once again, the same misunderstanding: you're talking about input-ouput matching in the GEO data (as performed by Google), while I was talking here about matching (mapping) GEO data and catalog labels (which is completely under PSU's control).

Come to think of it, why would you really want to have województwo lódzkie and Lódz' in the location fields, but Lódz Voivodeship and Lodz as catalog labels or as keywords? (Well, I could see reasons, but still...)

My point is actually the opposite - sorry for not being clearer. I'd want the location fields, catalog lables and keywords to match, but I wouldn't necessary want them all to match what Google thinks is right.
In this particular case Google thinks (or rather PSU says that Google thinks) that Places::Poland::Lódz Voivodeship::Lodz is right.
Not being Polish, I'd probably prefer my location fields, catalog lables and keywords to say Lodz Province, not Lódz Voivodeship.

Yep, that's understandable. The GEO Tag panel does offer the option to edit the lookup values returned by Google, although applying the same correction, over and over again, is hardly a sane option when separately GEO-tagging/adjusting tens or hundreds of images. (Coming to think about this, you are right that it would be awesome if PSU would somehow learn from past corrections and assist us going forward.)

Especially as PSU can't search on those diacritics (Mantis #2773 )

You don't have to remind me: I'm the only one who promptly supported your ticket

Others (especially Poles) might prefer the Polish version - województwo lódzkie - to Goggle's version.

Google does support other languages too (although I don't know if Polish in particular is supported). Does Photo Supreme invoke the Google queries based on the language specified in the global settings? Is there perhaps a case for requesting a particular language setting for the GEO lookups and reverse lookups?

I might be happy even with a simple 'X' button for each location field (inside the GEO Tag panel), such that I could quickly clear up one or more values returned by a lookup or reverse lookup.)

Well, at least we can agree on that one! And maybe an 'X' button against the latitude & longitude too.

Good - I'll open a Mantis ticket.

There's some details on Google's API at https://developers.google.com/maps/docu ... ding/intro which might turn up something useful - I've had a quick look and the bit that caught my eye was "the geocoder may return several results when address queries are ambiguous"

Hmm, I'm wondering how is PSU handling such a case. Does it simply pick up the first (or some random) result?

that may perhaps apply to the areas of Nepal (and similarly remote areas of the UK like Letheringsett!) that kicked off this discussion?

Maybe. It would be interesting to find out more (including some examples).

[Mke]

Mke, there's a misunderstanding. You now appear to be solely focused on the IPTC/XMP location fields (as filled in with values returned by Google), although we've been also talking about the catalog labels that are assigned (and created, if needed) based on those fields. Of course, PSU won't refresh the IPTC/XMP location data by itself - but it's a different matter with the catalog labels in the Places hierarchy (and that's what I'm talking about)!

IIUC, you suggested that the Geo Tag panel should ask the user (upon pressing Apply) whether he wants to create and assign catalog labels for the filed in location values (whatever they are - they may even be filled in by hand, not by Google). Let's say the user is pressing No: this would write the location values to the corresponding IPTC/XMP fields, but it would not lookup and assign matching catalog labels at that point. So far, so good. (That's what you wanted, right?)

However, my point is that 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). That may happen, for example, in case of a Read Metadata operation, or even in case of Save Metadata or automatic write-sync (for a concrete example, see point 6 in my post here). To conclude, the user's input ("do NOT create and assign catalog labels for the IPTC/XMP location data in this image") would have momentary effect - but it would not necessarily stick.

Are we on the same page now?

Yes, I am now! I can recreate what you're describing and can also see why I was misunderstanding you - and how much more frustrating this problem must be for you too!

I'd forgotten that for various reasons I deleted all of the pre-set locations in the Places hierarchy, before starting to use it in earnest, and started again with my own

I now only apply IPTC/XMP location data by lookups / reverse lookups, and only for selected cases (as previously mentioned), so PSU doesn't mess with my hierarchy as much as it must do with yours.

And, as you pointed out in your example, it's surely a bug that if you unassign a label and delete the latitude and longitude, that the IPTC/XMP location data is still retained in the image...

Coming to think about this, you are right that it would be awesome if PSU would somehow learn from past corrections and assist us going forward.

It would be a big factor in persuading me to use the location data more.

[Mke]

I guess it's worth summarising that, for me
1) I have no problem with IPTC/XMP location data being added to images
2) The current fully-automatic system that generates catalog entries from IPTC/XMP location data causes me problems that could be improved by either:

• making it optional (via a configuration option), or
  allowing user overrides that PSU would remember, as per my suggestion above.

[chuckhebert40]

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).

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. 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. 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.

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.


Additionally:

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. (This is all somewhat tied in to the subject of Mantis #2299).


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.