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