Bug 271489

Summary: Repeated reverse geotagging may duplicate /location tags
Product: [Applications] digikam Reporter: Milan Knížek <knizek>
Component: Geolocation-ReverseGeoCodingAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: normal CC: caulier.gilles, mike, nick.andrik
Priority: NOR    
Version: 7.0.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Milan Knížek 2011-04-22 15:36:16 UTC
Version:           2.0.0 (using KDE 4.6.2) 
OS:                Linux

New /location tags do not replace the existing ones and a repeated reverse geotagging is applied.

Reproducible: Always

Steps to Reproduce:
Open MyBestImage.jpg in Geolocation plugin, set GPS coordines to CityA, apply reverse geotagging.
Either close Geo-location plugin or even keep it open and change the GPS coordinates for MyBestImage.jpg to CityB and apply new reverse geotagging.

Actual Results:  
MyBestImage.jpg has two locations in tags: /location/blabla/blabla/CityA and /location/blabla/blabla/CityB.

Expected Results:  
Only the last /location/blabla/blabla/CityB is set. Any prior /location/... shall be removed.

Further, if an image, which already has /location/.... set, is opened in Geo-location plugin, the /location/... should be shown in the plugin's Tag column as well.
Comment 1 Michael G. Hansen 2011-04-22 16:01:01 UTC
Hi Milan,

the problem here is that we don't store that some tags are 'location' tags, they are just regular tags once stored in the database or in the image. To do something as you propose, we would either have to start noting the 'location' type in the database, or also allow the user to specify a pattern of tags which should be removed once new geotags arrive. Maybe one could let the user mark one tag as the 'location' tag, instead of creating patterns.

Michael
Comment 2 Michael G. Hansen 2011-04-22 16:02:15 UTC
Milan, the bugs you are filing here actually belong to kipi-plugins/gpssync.
Comment 3 Milan Knížek 2011-04-22 16:19:25 UTC
I have overlooked the "list all.."  projects during the selections phase of reporting a new bug and kipi-plugins is not listed in those pre-selected, sorry - I promise to get better ;-)

(I do not use kde bugs reporting system regularly and it always takes some time to get used to its user interface. )
Comment 4 caulier.gilles 2011-12-20 17:21:01 UTC
Milan, Michael,

This file still valid using kipi-plugins 2.4 ?

Gilles Caulier
Comment 5 Milan Knížek 2011-12-23 11:21:37 UTC
As far as I can tell, the behaviour has not changed.
Comment 6 caulier.gilles 2015-05-18 13:18:33 UTC
This file still valid using last kipi-plugins 4.10.0 ?

Gilles Caulier
Comment 7 Milan Knížek 2015-08-19 18:53:39 UTC
With kipi-plugins 4.12.0 the buggy behaviour is still the same.
Comment 8 caulier.gilles 2016-07-16 13:09:59 UTC
*** Bug 304591 has been marked as a duplicate of this bug. ***
Comment 9 caulier.gilles 2016-11-29 11:21:09 UTC
Can you reproduce the problem using digiKam Linux AppImage bundle ? The last
bundle is available at this url:

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 10 caulier.gilles 2020-08-03 04:50:40 UTC
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
Comment 11 Milan Knížek 2020-08-04 17:32:59 UTC
Unfortunatelly, the bug is the same as reported originally.
Comment 12 caulier.gilles 2023-04-20 14:50:36 UTC
@Milan

digiKam 8.0.0 is out. Problem still reproducible ?

Best regards
Gilles Caulier
Comment 13 caulier.gilles 2023-10-12 14:43:28 UTC
#Milan,

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