Bug 400579

Created attachment 116042 [details]
after editing: 7 gps data

after editing 5 gps data disappeared.
for example: gps image direction, gps altitude etc.

In digiKam or Showfoto, did you see the GPS tags removed from Exif viewer in right sidebar ?

Gilles Caulier

I'll take a closer look. But I think it's correct, all this data comes from a GPS receiver. After the GPS correction, the information would no longer fit. Take the GPS altitude, this would be invalid for the new coordinates and must be deleted. You can update these in the geolocation editor again.

Maik

(In reply to caulier.gilles from comment #2)
> In digiKam or Showfoto, did you see the GPS tags removed from Exif viewer in
> right sidebar ?
> 
> Gilles Caulier

yes

(In reply to Maik Qualmann from comment #3)
> I'll take a closer look. But I think it's correct, all this data comes from
> a GPS receiver. After the GPS correction, the information would no longer
> fit. Take the GPS altitude, this would be invalid for the new coordinates
> and must be deleted. You can update these in the geolocation editor again.
> 
> Maik

a deleted measure is more erroneous than the old measure.

when you fix the location of a photo you move by a few meters then you introduce a small error.

some value does not change. for example "GPS altitude reference" = "above sea level"

let the user have the choice to keep old measures or compute automatically the new altitude and the new compass direction.


thanks

We call the MetaEngine::removeGPSInfo() function in MetaEngine::setGPSInfo() before setting the new coordinates. This is the comment:

// In first, we need to clean up all existing GPS info.

The question is why. I think that someone has thought about it, that it is just necessary that no old GPS fragments remain.

Maik

Maybe I'm getting a little too far. But GPS information can be an important part of preserving evidence. And only fully coherent GPS data makes sense.

Maik

// In first, we need to clean up all existing GPS info.

==> This comment come from me. Certainly to prevent garbage in GPS data and re-write all from scratch. Remember that not all camera record a complete set (and standardized GPS tags list. This depend of internal GPS device synchro with satellites.

Typically, there is no reason to drop only few GPS tags and let's all other in place. This require to list exactly the which one can be lets as well in all case.

Take a list of a complete GPS tags and look which one are incompatible with and update of latitude, longitude, and altitude information. After all, as i remember, digiKam geolocation tool only touch this tags really.

Gilles

Created attachment 116068 [details]
checkDistance.patch

I have another idea and need feedback to see if it's good. We check the distance to the old coordinates. Only at a deviation greater than 100m we delete the old coordinates. Greater distance? Not clear for the user?

Maik

I used GPS for my photographs for 10 years with native photo app(Nokia, Samsung) or Opencamera.

The gps error is < 10 m

digiKam 7.0.0 stable release is now published and now available as FlatPak:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Thanks in advance

Gilles Caulier

digikam 7.0.0

I agree with all arguments. We need consistent data. If we change position then altitude must be changed but not the other data as for example "GPS image direction"even if distance is big.

I changed a little the position (about 100 m) of an image
then
no data is changed in "metadata" tab. In "map" tab position changed. Strange.

I change the position (about 300 km) of an image 
then
- no data is changed in "metadata" tab. In "map" tab position changed. Strange.

Hypothesis: GPS data are changed in digikam database but not in image file (I ask for digikam to store data in image file by default)

The saving of geological information must now be activated in digiKam-7.0.0 
like all other metadata types in the metadata setup.

Maik

Am Donnerstag, 13. August 2020, 10:08:19 CEST schrieben Sie:
> https://bugs.kde.org/show_bug.cgi?id=400579
> 
> --- Comment #12 from Philippe ROUBACH <philippe.roubach@free.fr> ---
> digikam 7.0.0
> 
> I agree with all arguments. We need consistent data. If we change position
> then altitude must be changed but not the other data as for example "GPS
> image direction"even if distance is big.
> 
> I changed a little the position (about 100 m) of an image
> then
> no data is changed in "metadata" tab. In "map" tab position changed.
> Strange.
> 
> I change the position (about 300 km) of an image
> then
> - no data is changed in "metadata" tab. In "map" tab position changed.
> Strange.
> 
> Hypothesis: GPS data are changed in digikam database but not in image file
> (I ask for digikam to store data in image file by default)

Ok now I ask for digikam to record GPS data in image file.

I modified the localization for about 100 m.

then in metada tab several gps data disappeared.

GPS Altitude : 82 m
GPS Altitude Reference : Above sea level
GPS Date Stamp : 2019:09:16
GPS Image Direction : 32136/100
GPS Image Direction Reference : Magnetic direction
GPS Processing Method : 65 83 67 73 73 0 0 0 110 101 116 119 111 114 107 0
GPS Time Stamp : 14:32:15
GPS Version ID : 2.2.0.0


some comments:

In most case we modify a little the localization because sometime smartphone GPS make a little error.

GPS Altitude : 82 m

must be automatically computed by digikam instead of deleted

GPS Altitude Reference : Above sea level

must not be deleted

GPS Date Stamp : 2019:09:16

must be set to day of the modification by digikam ?

GPS Image Direction : 32136/100
GPS Image Direction Reference : Magnetic direction

must not be deleted

GPS Processing Method : 65 83 67 73 73 0 0 0 110 101 116 119 111 114 107 0

I don't know what it is then I don't know if it is consistent to keep it

GPS Time Stamp : 14:32:15

must be set to the time of the modification by digikam ?

GPS Version ID : 2.2.0.0

i don't know what it is then i don't know if it is consistent to keep it

Perhaps  a parameter must be added to indicate what software modified gps data. In this case digikam.

I wouldn't change or delete the GPS timestamp. In my opinion that's the main field that shouldn't be deleted when GPS information is modified, because when it exists it is likely to be the most accurate indication of exactly when the picture was taken in UTC (since the camera clock might or might not be set properly), so it's pretty valuable information.

I have this issue for a GPS-enabled camera I used for years (a Canon PowerShot A520). Very often when the picture was taken just after the camera was turned on, the camera received enough satellite data to get a timestamp (you just need one satellite for that) but not the location (requires 3 satellites) or altitude (requires 4 satellites). As a result I have these pictures with GPS timestamps but no GPS location. When adding GPS location, I lose the GPS timestamp... It's a shame to lose valuable data this way.

You could also argue that GPS Image Direction isn't made invalid when changing the GPS location because it potentially comes from a completely different sensor (a compass).

There's also another major issue with this behaviour, which is that GPS data is entirely overwritten when running the pictures through the Batch Queue Manager (or maybe just specifically the User Shell Script, that's the main one I use)! So even if I'm not modifying the GPS information, I'm still losing Altitude, Speed, Direction and Timestamps from my geolocalized pictures... Of course I can disable the writing of GPS info in settings but then I can't set the GPS in the metadata anymore in the main app...

Git commit 99335145efb577f0d27ed4c9b02c17050cbed852 by Maik Qualmann.
Committed on 25/03/2023 at 19:36.
Pushed by mqualmann into branch 'master'.

remove existing GPS info only if the coordinate deviation is greater than 100 m
FIXED-IN: 8.0.0

M  +1    -1    NEWS
M  +21   -2    core/libs/metadataengine/engine/metaengine_gps.cpp

https://invent.kde.org/graphics/digikam/commit/99335145efb577f0d27ed4c9b02c17050cbed852

thanks