[digikam] [Bug 377228] New: Assign only deepest level reverse geotag to image to avoid tag spam

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

            Bug ID: 377228
           Summary: Assign only deepest level reverse geotag to image to
                    avoid tag spam
           Product: digikam
           Version: 5.5.0
          Platform: Appimage
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: Geolocation-Editor
          Assignee: [hidden email]
          Reporter: [hidden email]
  Target Milestone: ---

I have started reverse geotagging my images to be able to search for images
within a certain city or location. This works great (once you have understood
the UI), but it spams a lot of tags (TopLevelTag, Country, Country/City,
Country/City/Street, Country/City/Street/Number) in my images, which makes the
tags display below the thumbnails almost useless (since only the location tags
are visible any more).

I can think of two solutions to this problem:

a) do not show reverse geocoding tags below images, or
b) only assign *one* deepest level tag (in my example above, Number) to the
images, and not all higher hierarchy level tags.

With (b), images can still be filtered and found because searches may include
the higher level tags. (Right?)

What do you think?

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

--- Comment #1 from Jens <[hidden email]> ---
Addendum: For option (a), reverse geocoding tags could possibly be displayed as
a tooltip of the icon that indicates the image has embedded geoinformation.
That is where they would belong. This would need to be an option to be set in
the reverse geocoding dialog (globally, i.e. also for existing tags):

[X] Hide geocoding tags below thumbnails (display only as geocoding icon
tooltip)

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

Wolfgang Scheffner <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #2 from Wolfgang Scheffner <[hidden email]> ---
Jens,

I just finished the handbook section about reverse geocoding but it is not
committed yet. Could have saved you some time, sorry!

But I think I know a solution or at least a workaround for your problem: the
tags below the thumnail are displayed in alphabetical order. So if you name
your top level geo tag ~Location for ex. all your other tags remain visible in
the image icon.

Wolfgang

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

--- Comment #3 from Jens <[hidden email]> ---
Wolfgang, thank you for the handbook and your hard work!

Your workaround doesn't work, however, since the alphabetical order is only
applied to the actual tag (deepest level) and not the full tree. My top level
tag is "Orte", but "Orte/Deutschland/Berlin" still comes before "Kochen"
(because of "B"erlin).

Or is this configurable? I didn't find anything.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

--- Comment #4 from Wolfgang Scheffner <[hidden email]> ---
Well, I'm afraid you are right. I didn't test hard enough, just by accident in
my case the sub tags I tried were further aft in the alphabet.
Putting the ~ in front of all sub tags would be too tedious unless the
correlator would do it, maybe as an option. Creating special geo tags is
something the devs would probably not like becaue it makes the code more
complacated (Gilles?) for a relatively personal issue. I say that because since
I'm following the discussions I heard so many ideas how to abuse the tags and
this is an abuse to me as well. There are metadata fields especially for that
purpose (IPTC country code, country, city, sublocation, ...) and in my opinion
they should be used instead of bloating the tag tree. Unfortunately I have to
admit that the metadata handling in digiKam is not in a stage yet to do this
effectively and Gilles told me that it takes an amount of manpower to improve
that we cannot afford right now. So maybe the ~ in front of the tags assigned
by the correlator could be an interim solution.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #5 from [hidden email] ---
... and '~' is not in ASCII characters list if i remember. Only on UTF8. So
IPTC will lost this character.

So, this is not a suitable solution...

Also, distinguous Geolocation tags strings and digiKam tags strings will make a
puzzle... that we don't want...

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

--- Comment #6 from Wolfgang Scheffner <[hidden email]> ---
~ is ASCII 126. But otherwise I agree.
Remains the metadata handling improvement >:-)

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377228

--- Comment #7 from Jens <[hidden email]> ---
Actually, I'm pretty fond of being able to use tags for many purposes and not
having to reinvent the wheel for every other kind of metadata. (OTOH, if
portability is an issue, the IPTC location tags should at least be written, if
not used in Digikam too.)

But if this means we have to treat some tags specially (-> Animal Farm) and
this is not clearly visible for the user, then it is a bad solution. We already
have "face tags" (which have additional parameters not clearly indicated to the
user), now we're getting "location tags" ... at least the default icon should
be different, in addition to them being displayed only where it makes sense.

But this might be a different bug report.

--
You are receiving this mail because:
You are the assignee for the bug.