Bug 507913

Summary: Reset existing hierarchal tags before 'Write location as tags'
Product: [Applications] digikam Reporter: mahikeulbody <51mfxqck>
Component: Geolocation-ReverseGeoCodingAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: wishlist CC: metzpinguin
Priority: NOR    
Version First Reported In: 8.7.0   
Target Milestone: ---   
Platform: Manjaro   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description mahikeulbody 2025-08-05 18:45:16 UTC 
If we geo-tag again a photo already geo-tagged to another location, new hierarchical tags (Place) are added. The existing one are not be erased. The wish is to automatically erase the existing ones before to add the new ones. If "automatically" is not wanted for some reasons I don't see right now, we could have an option to set in order to allow "erasing existing".

NB. This would be consistent with "write location as metadata" which erases the existing ones since they are "simple" fields.

Use case : we may want to geo-tag again already geo-tagged photos if we want to take in account modifications in the geo bases (openstreemap, geonames, ...).
Comment 1 Maik Qualmann 2025-08-05 18:50:54 UTC 
No chance, we don't know which of the tags are geotags. Instead of tags, it's better to write the location metadata. Because we're planning on having a location sidebar in the future.

Maik
Comment 2 mahikeulbody 2025-08-05 19:15:16 UTC 
I don't understand : when 'write locations as tags' is set, you write to all hierarchical tags linked to 'tag' into the metadata configuration, using "Place" as root label. So you could remove of all of them before to add new hierarchical "Place | ....".

> Instead of tags, it's better to write the location metadata.

I set also 'write to metadata' but hierarchical organization is more powerful.

>  Because we're planning on having a location sidebar in the future.

I am not sure to understand : do you mean location info will not be stored as hierarchical tags in the futur ?
Comment 3 Maik Qualmann 2025-08-05 19:31:07 UTC 

*** This bug has been marked as a duplicate of bug 271489 ***