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?
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)
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
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.
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.
... 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...
~ is ASCII 126. But otherwise I agree. Remains the metadata handling improvement >:-)
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.
After 3 weeks of work, i finally completed the compilation of AppImage using Qt 5.11.3 + QWebkit 5.212. New 6.1.0 pre-release AppImage bundle can be found here (64 bits only for the moment) : https://files.kde.org/digikam/ Please check if this bugzilla entry still valid. Thanks in advance Gilles Caulier
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best Regards Gilles Caulier
still valid für 7.0
*** Bug 402872 has been marked as a duplicate of this bug. ***
@Jens, digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
Yes, still valid. (8.1.0-git appimage)
Did you see in the reverse geolocation option that it is now possible to write only to the location metadata? These can also be searched for with the advanced search. Maik
Yes, I saw. That's great. How about old images? Was the location metadata also written previously (in addition to tags), or is it possible to write location metadata to all images that have location tags in a batch?
Just for information,in case of Exiv2 can be a source of this problem, i ported all bundles to last Exiv2 0.28 which gain a lots of bug fixes, compared to the maintenance 0.27 LTS versions, used by digiKam since a very long time. So the online pre-release AppImage 8.1.0 use Exiv2 0.28 since few days. Gilles Caulier
Link to Exiv2 0.28 announcement : https://github.com/Exiv2/exiv2/issues/2406#issuecomment-1529139799 Gilles
Jens, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier
Hi all, The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern frameworks Qt 6.7.0 and KDE 6.2.0. File can be downloaded at usual place : https://files.kde.org/digikam/ Take a care : the bundle is named with the suffix "-Qt6" not "-Qt5". This bundle is compiled under Ubuntu 22.04 and require a Linux with GlibC version >= 2.35 to run. Can you reproduce the dysfonction with this version? Thanks in advance Gilles Caulier