Bug 481289

Summary: Problem with Reverse Geocoding writing Xmp.lr.hierarchicalSubject
Product: [Applications] digikam Reporter: mahikeulbody <51mfxqck>
Component: Geolocation-ReverseGeoCodingAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED NOT A BUG    
Severity: normal CC: metzpinguin
Priority: NOR    
Version First Reported In: 8.2.0   
Target Milestone: ---   
Platform: Manjaro   
OS: Linux   
Latest Commit: Version Fixed/Implemented In: 8.3.0
Sentry Crash Report:

Description mahikeulbody 2024-02-13 11:41:29 UTC
SUMMARY
If we do Reverse Geocoding with 'write locations as tags' set and then we do exiftool --HierarchicalSubject: photo.jpg we get (this is an example) :

"Place|England, Place|England, Place|England|London, Place|England|London|Baker street"

instead of just "Place|England|London|Baker street" as Tag Manager does with such hierarchical tag.
Comment 1 Maik Qualmann 2024-02-13 12:03:30 UTC
And where is the bug now? If you save "England", "London" and "Baker street" as assigne tags with path, the content will be exactly as you see it with ExifTool. How else can you tell what is just a tag path and is actually assigned to the image.

Please ask such questions in the mailing list and do not open them as a bug.

Maik
Comment 2 mahikeulbody 2024-02-13 12:20:49 UTC
If we do a Reverse Geocoding we get a Digikam hierarchical tag "Place|England|London|Baker street" and a Xmp.hierarchicalSubject "Place|England, Place|England, Place|England|London, Place|England|London|Baker street" into the photo.

But if we apply this Digikam hierarchical tag to another photo we get a Xmp.hierarchicalSubject "Place|England|London|Baker street" into this other photo.

May be it is not a bug (i.e. the developer wanted this behavior) but that seems (imho) inconsistent.
Comment 3 Maik Qualmann 2024-02-13 12:28:33 UTC
If you only have "Place|England|London|Baker street" in the metadata, only "Baker street" will appear under the image, not "England" or "London" and these will not have a "check" in the tags manager.

Again, how else to encode in a string what is just path and what is assigned to the image?

Maik
Comment 4 mahikeulbody 2024-02-13 12:47:39 UTC
> If you only have "Place|England|London|Baker street" in the metadata, only "Baker street" will appear under the image, not "England" or "London" and these will not have a "check" in the tags manager.

No. Let say Place|England|London|Baker street doesn't exist yet into Digikam.

exiftool -xmp:all= photo.jpg
exitool -ipc:all photo.jpg
exiftool -HierarchicalSubject="Place|England|London|Baker street"

start Digikam
check Tag Manager, you will see the new tree Place|England|London|Baker street.
Comment 5 Maik Qualmann 2024-02-13 12:50:46 UTC
Yes, but only "Baker Street" has a "check", not "England" or "London", that's the difference. Check "England" and "London" and you have the same metadata string.

Maik
Comment 6 mahikeulbody 2024-02-13 13:02:31 UTC
I am not sure to understand what do you mean by "to have a check". If you mean that if I select England or London in the Tags Manager, Digikam doesn't display my photo, it is wrong, it displays my photo.
Comment 7 mahikeulbody 2024-02-13 14:35:40 UTC
I feel that there is misunderstanding which could be due to my low level in english. Please forgive me if it is the case. So I will try to reformulate otherwise.

When you drag&drop the tag C of a tree A|B|C to a file, Digikam writes HierarchicalSubject = "A|B|C".

Why Reverse Geocoding does not the same thing instead of to write HierarchicalSubject = "A, A|B, A|B|C" ?

There is no difference using a tags tree into Digikam (including the "check" stuff you talk about) whatever it has been created by Reverse Geocoding or manually with the Tag Manager or read from HierarchicalSubject in the file. So why to store it into HierarchicalSubject differently (and in a more complicated form) in case of Reverse Geocoding ?
Comment 8 Maik Qualmann 2024-02-13 15:13:10 UTC
"A|B|C"  :

[ ]A
   [ ]B
      [x]C

"A, A|B, A|B|C" :

[x]A
   [x]B
      [x]C

Maik
Comment 9 mahikeulbody 2024-02-13 16:37:50 UTC
Ok, that toke me a little time to find these checks because I never used before the Tab panel of Caption sidebar menu (my only tags come from automatic tagging such as face recognition and reverse geocoding). So my misunderstanding of your answers :-(

Setting a non-root tree node works as if the higher levels of the tree were set. That does not appear in the Tab panel of Caption sidebar menu  but all functions (advanced search, tabs manager, tabs filters, ...) work as if these higher levels were set (AFAIK).

So I wonder what benefice there is to write HierarchicalSubject = "A|B|C, A|B, A" over to write simply "A|B|C" except to be able to display A[ ] B[ ] C[x] when in fact that does not reflect that Digikam will work as if we have A[x] B[x] C[x].

If the higher nodes of a node set were automatically set in order be more consistent with the way all functions work in this case (AFAIK again) that would remove the artificial (?) need to write strings as "A|B|C, A|B, A".

Also you could take in account that Digikam writes HierarchicalSubject = "A|B|C" when the user drag&drop the tag C onto a photo.

In case you would want to "fix" this different behavior between Tab panel of Caption sidebar and drag&drop from Tags filter, my suggestion would be to write HierarchicalSubject as drag&drop does for both Tab panel and Reverse Geocoding.
Comment 10 mahikeulbody 2024-02-13 16:50:47 UTC
-------------------------------------------------------------------
Also you could take in account that Digikam writes HierarchicalSubject = "A|B|C" when the user drag&drop the tag C onto a photo.
In case you would want to "fix" this different behavior between Tab panel of Caption sidebar and drag&drop from Tags filter, my suggestion would be to write HierarchicalSubject as drag&drop does for both Tab panel and Reverse Geocoding.
-------------------------------------------------------------------

Please doesn't take in account this part of my comment, sorry.
Comment 11 Maik Qualmann 2024-02-13 17:35:41 UTC
Another try:

"A|B|C" : only C is a tag of the image, A and B are not.

"A, A|B, A|B|C" : A and B and C are a tag of the image.

If you were to search for A or B in the first variant, the image would not be found. In the second variant very well.
And this is not something we came up with, this is a metadata standard.

Maik
Comment 12 mahikeulbody 2024-02-13 17:51:45 UTC
Ok.

> If you were to search for A or B in the first variant, the image would not be found.

I found it with the left side Tags panel selecting A or B (or C, of course). Is it right ?
Comment 13 Maik Qualmann 2024-02-13 18:11:39 UTC
It would also be displayed for A and B in the left sidebar if you have activated the recursive tag view under Menu->View.
But be aware that with "A|B|C" only the tag C is actually assigned to the image.

Maik
Comment 14 mahikeulbody 2024-02-13 18:31:57 UTC
> It would also be displayed for A and B in the left sidebar if you have activated the recursive tag view under Menu->View.
It is activated here but when I set it a long time ago but I did not understand all the meaning since for me, the only "logical" way to search with tags tree is the recursive way. By the way, I just became aware of the option 'in tree' to advanced search a tag.

This setting doesn't apply to Tags filter. That means we have to set individually all needed node of a tree if we wanted the recursive way ?