Most certainly not!I guess you could merge Places::Continents::South America with Places::South America.
As I explained, I am using Places as a logical container not only for political geographic units. So my hierarchy currently looks like this:
PLACES
-Continents
---South America
-----Argentina
-----Brazil
-----Ecuador
-----etc.
-Regions
---Andes
---Sonoran Desert
---etc.
-Borders
---Polish-German border
---Swiss-German border
etc.
-Historic Places
---German Democratic Republic
etc.
Have PSU create geographic labels automatically would result in South America becoming a top-level label in this hierarchy. I don't think that makes much sense:
PLACES
--South America
----Argentina
----Brazil
----Ecuador
----etc.
-Regions
---Andes
---Alpes
---Atacama
---Sonoran Desert
---etc.
-Borders
---Polish-German border
---Swiss-German border
etc.
-Historic Places
---German Democratic Republic
etc.
My problem: a lot of thinking went into setting up my label hierarchy before PSu's new functionality came along. I am experiencing these issues repeatedly. For example, there was a good reason why I started using delimited keywords, when lightroom keywords not yet existed. Now these delimited keywords are being deprecated and I am probably well advised to abandon them. But there are other cases, where keeping my "legacy" data to me seem to make a lot of sense.
Though I see the advantages on automatic GEO-label creation, I also see some of its pitfalls...
Ideally PSu, like you suggest, should be able to "see" an existing hierarchy and thus place the labels where they actually belong. I doubt this kind of "clarvoyance" is likely to be implemented any time soon.
So, what I have been thinking to do instead, is perhaps have the GEO-Panel create its second hierarchy and ever so often clean it up, routinely merging "Places::South America" into "Places::Continents::South America". However, this would not only necessarily complicate my workflow (with the benefit of having these labels being created automatically), but it would still not address two concerns:
(1) will the unwanted labels keep creeping back as long as the setting is enabled?
(2) even though the labels might be auto-created from the panel the labels themselves would remain powerless; assigning them to an image would not fill in the fields from the GEO-Panel nor would adding a label write the GEO-coordinates to the files, right?
You are saying that yourself:
What's indeed missing is a way to tweak the algorithm which processes the geo metadata and turns it into labels.
That actually is not my point. I was talking about Scotland leaving the UK as a result of the Brexit, which is a likely scenario. As a result the UK itself would cease to exist as has happened with the east German Democratic Republic, the Sowjet Union, former Yugoslavia. The point is: political unions are not stable, but historic boundaries shift. How do you deal with this. Even new countries may appear on the map, like South Sudan.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.
So, again, my point is: limiting Places to an automatic lookup-hierarchy is much too rigid! I prefer more flexibility even if it requires a bit more input (and a brain) to do it...
Actually, I very much doubt that and here is why: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.
If you want to implement label templates at some point in the future (#2844) you probably want these templates to work also with your GEO-labels. The "additional settings" (#3020) that you suggest could be implemented quickly would, in my opinion, essentially best be implemented via "label templates", i.e., what you are specifically asking for is a way to customize the way GEO-labels by giving the user a choice how these should be configured. That is essentially asking for "templates" of these GEO-labels, right?
Your "additional settings" (#3020) proposal thus has immediate consequences for the "label template" (#2844) proposal. If you design a functionality that allows the user to set up templates for the creation of GEO-labels, why not go all the way and do this for all label categories. The People label is another example. Currently I do find it fairly annoying that per default that category assumes that the people are all people pictured on the photo, thus "auto-filling" the field "person in image". My legacy data in the category people includes the creator of an image (the photographer) and that person is in almost all cases not pictured in the photo, yet PSU insists he/she is, if I choose to place that label under "people".
BTW - I am not sure how complicated #2844 will need to be. Currently there is already a powerful way how to batch-configure existing labels. The problem is, every new label that you create in a category does not inherit these default settings, but you need to manually change them again. If there was a way how to set a template with default settings for a particular category, that could also address your needs for more flexible GEO-label configuration. If you do it the other way round, have "flexible GEO-label configuration" be implemented first, prior to introducing "label templates", it is quite likely that this features will interfere eventually interfere with the "templates"...
PS: What I have been thinking to avoid the current issues that I encounter both with the People and the Places category is re-locating my labels that are affected into a different custom category: creating a category "Custom Places" for "my" borders, regions and historic places, creating a category "Custom People" for people that are not shown in the photo...
The reason I am reluctant to do that: thousands of images are affected and I am a bit weary of having to re-write metadata to all of them...
Are you talking about catalog labels or geo favorites?