If an image is loaded into the Geolocation editor the image list does not show its existing location tags, if there are any. I would expect these to show up since although they are tags, but still belong to the geolocation data. Also, when copying and inserting the geo data from another image, I would expect these tags to be copied as well.
Please provide : - one screenshot showing the geolocation tag in album gui and other one the items loaded with these geolocation tags in editor. - Some samples images with your geolocation tags, to try to reproduce the problem with 6.0.0. Q: did you tried DK AppImage 6.0.0 pre release to see if this problem is fixed ? Gilles Caulier
I understand the bug report so that they expect the tags geolocation coordinates to be included (Bug 278963). But this is not so, for example, if you put a image with the coordinates of Paris and add the tag "Paris", the most useful image does not automatically have the coordinates if you only add the tag "Paris". Maik
This Bug 192442 should be inserted in my posting Maik
Actually my bug report was only about the geolocation tags which were inserted by reverse geocoding not showing up in the geotags editor when the same image is loaded again - and thus probably not copied into another image when the copy & paste functionality of the geolocation editor is used. But I do like - and support - the idea of tags being able to carry geo coordinates; although this is a completely different issue. I also have a huge image collection which is tagged according to location and I personally would find it a lot easier to assign (geotagged) tags directly in the tag editor since 95% of my images are taken in known fixed locations, than having to open the geotag editor for every album, which cannot preview movies and does not have a thumbnail grid (only tabular layout).
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. To reproduce: 1. geotag an image, apply reverse geocoding to have it tagged with e.g. city name 2. save & close geotag editor 3. select image again, reopen geotag editor 4. "Tags" column in the thumbnail table is empty, but the city name tag from above should show up here, IMHO.
*** Bug 449080 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.
How is the geolocation editor supposed to know which of all the tags are the location tags? The Tags column is only intended to show when new ones are added. What we could do since digiKam-8.0.0 is display location metadata, but tags are impossible. Maik
(In reply to Maik Qualmann from comment #11) > How is the geolocation editor supposed to know which of all the tags are the > location tags? The Tags column is only intended to show when new ones are > added. > What we could do since digiKam-8.0.0 is display location metadata, but tags > are impossible. > > Maik In the reverse geocode section, you can set a template to set tags. Can the path for these tags not be checked against the template and filled in where they exist? I understand that if tags were not stored in hierarchical format in the metadata, this would probably be impossible, but if tags exist that match the template, why not fill in the data?
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
+1 for the Maik comment #11... Gilles Caulier