Bug 208227 - ImagePosition does not always reflect contents of GPS Exif-Tags
Summary: ImagePosition does not always reflect contents of GPS Exif-Tags
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Geolocation-Engine (show other bugs)
Version: 2.0.0
Platform: Compiled Sources Unspecified
: LO wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-23 01:17 UTC by Johannes Wienke
Modified: 2017-08-19 06:10 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Wienke 2009-09-23 01:17:50 UTC
Version:           1.0.0-beta5 (rev.: 1026738) (using KDE 4.3.1)
Installed from:    Compiled From Sources

I just found out that ImagePosition does not always reflect the current contents of the GPS Exif tags.

Steps to reproduce:
1. Add an image to the digikam database
2. Change the GPS tags using an external tool like exiftool

Now, if you select the geo localization widged on the right side of digikam, the new GPS coordinates aren't reflected in the digikam database. I did not find a solution to convince digikam to refresh these values without using the edit dialog for coordinates, which works fine and reflects the newly assigned coordinates.
Comment 1 Marcel Wiesweg 2009-09-23 19:07:09 UTC
"Image -> Reread Metadata From Image" does not work?
Comment 2 Johannes Wienke 2009-09-23 19:15:56 UTC
Ok, I didn't know that option. That works. But shouldn't digikam be able to refresh this automatically. Or at least when doing an F5 in that album?
Comment 3 Marcel Wiesweg 2009-09-23 19:32:39 UTC
We decided some time ago not to do this automatically. We could of course (at least, if the modification date is changed when changing metadata). 
We can think about this again for the next version.
Comment 4 Johannes Wienke 2009-09-23 19:40:48 UTC
Wouldn't it be much more general to use something like an md5 hash? This should always be modified when the file changes.
Comment 5 Marcel Wiesweg 2009-09-23 22:34:49 UTC
Yes but we cannot generate a hash on startup for every image. We do use a hash over parts of the file, nonetheless we need the file system time stamp to know which files may have changed
Comment 6 Marcel Wiesweg 2009-11-30 20:40:12 UTC
I dont think we will change behavior here...
Comment 7 Michael G. Hansen 2009-11-30 21:14:12 UTC
When I do 'touch someimage' while digikam is running, the thumbnail of that image is refreshed automatically. Wouldn't it be easy to simply (optionally) connect that signal to a re-read-metadata-slot?

Michael
Comment 8 Marcel Wiesweg 2009-12-01 21:36:51 UTC
Yes we can do that, no problem. But it will only work as long as digikam is running, and if KDirWatch works (which it does not often enough)
Comment 9 Johannes Wienke 2009-12-01 21:42:27 UTC
(In reply to comment #8)
> Yes we can do that, no problem. But it will only work as long as digikam is
> running, and if KDirWatch works (which it does not often enough)

Better than nothing, I think.
Comment 10 caulier.gilles 2014-08-24 08:00:24 UTC
Johannes,

This file still valid using last digiKam 4.2.0 ?

Giles Caulier
Comment 11 barsanuphe 2015-05-12 18:59:15 UTC
Running digikam 4.9 on Archlinux, I can add GPS information from the geolocation plugin. However, it seems the new metadata is directly written to the file, and not to the database. 
I have to reread metadata from image to have the file flagged as having GPS location and displayed on the map. 
It looks like this bug, but even when the GPS data is added by Digikam itself... or maybe I have overlooked something?
Comment 12 caulier.gilles 2015-09-24 13:16:00 UTC
Git commit 40dd102ba1c3a0ea39a84ec5656d967c79627c8c by Gilles Caulier.
Committed on 24/09/2015 at 13:11.
Pushed by cgilles into branch 'frameworks'.

Geolocation Edit always refresh database contents about GPS info and after write to file metadata if it's possible.
To read GPS Info from item, it try in first database else file metadata.
Geolocation map view is now based to QWebView instead KHTML. So we cannot see no more memory leak and tiles dysfunction with GoogleMaps.
Note : in 5.0.0, Geolocation Edit tool is now also available in ImageEditor, Showfoto and LightTable.
Related: bug 317241, bug 330231
FIXED-IN: 5.0.0

M  +4    -1    NEWS
M  +8    -7    app/main/digikamapp.cpp
M  +1    -0    libs/database/CMakeLists.txt
A  +147  -0    libs/database/item/imagegps.cpp     [License: GPL (v2+)]
A  +59   -0    libs/database/item/imagegps.h     [License: GPL (v2+)]
M  +9    -1    libs/database/item/imageposition.h
M  +2    -2    showfoto/main/showfoto.cpp
M  +2    -2    utilities/geolocation/editor/CMakeLists.txt
R  +35   -35   utilities/geolocation/editor/dialog/geolocationedit.cpp [from: utilities/geolocation/editor/dialog/gpssyncdialog.cpp - 094% similarity]
R  +7    -7    utilities/geolocation/editor/dialog/geolocationedit.h [from: utilities/geolocation/editor/dialog/gpssyncdialog.h - 091% similarity]
R  +14   -14   utilities/geolocation/editor/dialog/gpsgeoifacemodelhelper.cpp [from: utilities/geolocation/editor/dialog/gpssyncgeoifacemodelhelper.cpp - 082% similarity]
R  +7    -7    utilities/geolocation/editor/dialog/gpsgeoifacemodelhelper.h [from: utilities/geolocation/editor/dialog/gpssyncgeoifacemodelhelper.h - 086% similarity]
M  +4    -4    utilities/geolocation/editor/dragdrop/mapdragdrophandler.cpp
M  +3    -3    utilities/geolocation/editor/dragdrop/mapdragdrophandler.h
M  +23   -20   utilities/geolocation/editor/items/gpsimageitem.cpp
M  +24   -0    utilities/geolocation/editor/items/gpsimageitem.h
M  +1    -1    utilities/geolocation/editor/reversegeocoding/rgwidget.cpp
M  +8    -7    utilities/imageeditor/main/imagewindow.cpp
M  +8    -7    utilities/lighttable/lighttablewindow.cpp

http://commits.kde.org/digikam/40dd102ba1c3a0ea39a84ec5656d967c79627c8c