| Summary: | Problem with Reverse Geocoding writing Xmp.lr.hierarchicalSubject | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | mahikeulbody <51mfxqck> |
| Component: | Geolocation-ReverseGeoCoding | Assignee: | 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
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 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. 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 > 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.
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 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. 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 ? "A|B|C" :
[ ]A
[ ]B
[x]C
"A, A|B, A|B|C" :
[x]A
[x]B
[x]C
Maik
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. ------------------------------------------------------------------- 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. 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 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 ?
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 > 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 ?
|