[Digikam-devel] GPS coordinate accuracy

[Arnd Baecker]

Hi,

when specifying a location with the new
"Edit geographical coordinates" tool   (Brilliant, BTW!!)
on the best zoom-level,
this leads to coordinates like
51.02370121634948, 13.710897266864777
Assigning this to the image and checking
the location with "google maps", "more info"
leads to "51.0235,13.7103333333"
which is off by several meters.

So at some point either not enough digits are saved
or they get lost during conversions?

Should I create a BKO entry?

Two more remarks:
- Could one also use this widget with the map
  in the GPS Info Tab?
- In the GPS Info Tab in the sidebar of digikam the
  location is given as 54'1.41''.
  Why not just use the decimal variant here as well?

Best, Arnd

P.S.: Yes, I am able to access bugs.kde.org,
but only with the trick of using https://bugs.kde.org.
We seem to be blocked from the  http://bugs.kde.org
(Anyone ever heard about something like this before ??)

P.P.S.: and yes, I followed Gilles advice and
did an upgrade (of one machine) to debian etch and
therefore use KDE 3.5.5 on that machine ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

On Friday 24 November 2006 16:26, Arnd Baecker wrote:

> Hi,
>
> when specifying a location with the new
> "Edit geographical coordinates" tool   (Brilliant, BTW!!)
> on the best zoom-level,
> this leads to coordinates like
> 51.02370121634948, 13.710897266864777
> Assigning this to the image and checking
> the location with "google maps", "more info"
> leads to "51.0235,13.7103333333"
> which is off by several meters.
>
> So at some point either not enough digits are saved
> or they get lost during conversions?
>
> Should I create a BKO entry?
>
> Two more remarks:
> - Could one also use this widget with the map
>   in the GPS Info Tab?
> - In the GPS Info Tab in the sidebar of digikam the
>   location is given as 54'1.41''.
>   Why not just use the decimal variant here as well?
>
> Best, Arnd
>
> P.S.: Yes, I am able to access bugs.kde.org,
> but only with the trick of using https://bugs.kde.org.
> We seem to be blocked from the  http://bugs.kde.org
> (Anyone ever heard about something like this before ??)
>
> P.P.S.: and yes, I followed Gilles advice and
> did an upgrade (of one machine) to debian etch and
> therefore use KDE 3.5.5 on that machine ;-)

(:=))...

I let's others digiKam users GPS fan talking about your remark.

Julien, Fabien, Gerhard, ...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

Hi,

Gilles Caulier wrote:
> On Friday 24 November 2006 16:26, Arnd Baecker wrote:
>> when specifying a location with the new
>> "Edit geographical coordinates" tool   (Brilliant, BTW!!)

I agree :)

>> on the best zoom-level,
>> this leads to coordinates like
>> 51.02370121634948, 13.710897266864777
>> Assigning this to the image and checking
>> the location with "google maps", "more info"
>> leads to "51.0235,13.7103333333"
>> which is off by several meters.

I just tried and for me, it works perfectly...
Note: I open the location for more info in firefox, not konqueror, but
it should be the same I guess.

>> So at some point either not enough digits are saved
>> or they get lost during conversions?
>> Should I create a BKO entry?
>> Two more remarks:
>> - Could one also use this widget with the map
>>   in the GPS Info Tab?

I think there's already a wish in bko for that.

>> - In the GPS Info Tab in the sidebar of digikam the
>>   location is given as 54'1.41''.
>>   Why not just use the decimal variant here as well?

This is the value returned by exiv2...

>> P.S.: Yes, I am able to access bugs.kde.org,
>> but only with the trick of using https://bugs.kde.org.
>> We seem to be blocked from the  http://bugs.kde.org
>> (Anyone ever heard about something like this before ??)

I never had this problem.


> I let's others digiKam users GPS fan talking about your remark.
>
> Julien, Fabien, Gerhard, ...
Yep :)

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Friday 24 November 2006 23:24, Gilles Caulier wrote:
> On Friday 24 November 2006 16:26, Arnd Baecker wrote:
[...]

> > - In the GPS Info Tab in the sidebar of digikam the
> >   location is given as 54'1.41''.
> >   Why not just use the decimal variant here as well?
>
> (:=))...
>
> I let's others digiKam users GPS fan talking about your remark.
>
> Julien, Fabien, Gerhard, ...
>

...count me in :)

I've tweaked the exiv2 logic a bit for the upcoming 0.12 release. Since
the exiv2 output is shown in digikam if I'm not mistaken, here is what
it is now:

Consider
   3.14159292 degrees, which can also be written as
   3deg 8.4955752' or
   3deg 8' 29.734512"

Depending on how the value is encoded in the Exif data (*), exiv2 will
show 7 decimal places for degrees, 5 for minutes and 3 for seconds,
i.e.,
   3.1415929deg (**)
   3deg 8.49558'
   3deg 8' 29.735"

Converting this to distance, the corresponding accuracies of such values
are (at least):
   10^-7deg ~ 1.1cm
   10^-5'   ~ 1.9cm
   10^-3"   ~ 3.8cm

i.e., all much lower than the best GPS accuracy you can ever get, so
there shouldn't be a concern that the numbers shown do not correspond
to a location determined by GPS accurately enough.

(*) In the Exif field, longitude and latitude values must be encoded as
three rationals (two 32bit integers each): the number of degrees,
minutes and seconds. Fractions are obviously possible for all three and
one specific value can be encoded in multiple ways.

(**) I also replaced the degree sign with 'deg', due to charset
concerns.

-ahu.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

Hi,

thanks for looking into this!

On Sun, 26 Nov 2006, Andreas Huggel wrote:
[...]

> I've tweaked the exiv2 logic a bit for the upcoming 0.12 release. Since
> the exiv2 output is shown in digikam if I'm not mistaken, here is what
> it is now:
>
> Consider
>    3.14159292 degrees, which can also be written as
>    3deg 8.4955752' or
>    3deg 8' 29.734512"
>
> Depending on how the value is encoded in the Exif data (*), exiv2 will
> show 7 decimal places for degrees, 5 for minutes and 3 for seconds,
> i.e.,
>    3.1415929deg (**)
>    3deg 8.49558'
>    3deg 8' 29.735"
>
> Converting this to distance, the corresponding accuracies of such values
> are (at least):
>    10^-7deg ~ 1.1cm
>    10^-5'   ~ 1.9cm
>    10^-3"   ~ 3.8cm
>
> i.e., all much lower than the best GPS accuracy you can ever get, so
> there shouldn't be a concern that the numbers shown do not correspond
> to a location determined by GPS accurately enough.

These numbers do indeed sound accurately enough.
However, it seems this is not yet achieved
(current exiv2 svn and digikam svn):

Take any image and use the "Edit geographical coordinates"
to provide a position on the highest zoom level (satellite view,
i.e cars are roughly of the size of the mouse pointer ;-),
which is I think level 19 in google map terms).
Accept these coordinates by "OK".
Then invoke "Edit geographical coordinates" again
and compare the resulting longitude/latitude coordinates.
For example I get:
51.02370459056218, 13.710897266864777
vs.
51.0236666667   ,  13.7108333333
So it seems that more digits are lost than expected?

Well, let's have a look where these digits get lost:

Output of `exiv2 -p t`:

Exif.GPSInfo.GPSVersionID                 Byte        4  2 0 0 0
Exif.GPSInfo.GPSLatitudeRef               Ascii       2  North
Exif.GPSInfo.GPSLatitude                  SRational   3  51deg 1.42000'
Exif.GPSInfo.GPSLongitudeRef              Ascii       2  East
Exif.GPSInfo.GPSLongitude                 SRational   3  13deg 42.65000'
Exif.GPSInfo.GPSAltitudeRef               Byte        1  Above sea level
Exif.GPSInfo.GPSAltitude                  SRational   1  0 m
Exif.GPSInfo.GPSMapDatum                  Ascii       7  WGS-84

I.e.
51.023666666666666666, 13.71083333333333332

Alright, so to me it seems that the
"Edit geographical coordinates" tool does not write
the necessary number of digits.

As a test:
With `exiv2 -p v` one gets:
0x0002 GPSInfo      GPSLatitude          SRational   3  51/1 142/100 0/1
0x0004 GPSInfo      GPSLongitude         SRational   3  13/1 4265/100 0/1

Manual modification:
exiv2 -M "set Exif.GPSInfo.GPSLatitude 51/1 14222/10000 0/1 "  IMG_5356test_manip.JPG
works fine both in digikam display and the "Edit geographical
coordinates" tool.
Only on save not enough digits are used ...

Best Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

On Monday 27 November 2006 13:43, Arnd Baecker wrote:

> Hi,
>
> thanks for looking into this!
>
> On Sun, 26 Nov 2006, Andreas Huggel wrote:
> [...]
>
> > I've tweaked the exiv2 logic a bit for the upcoming 0.12 release. Since
> > the exiv2 output is shown in digikam if I'm not mistaken, here is what
> > it is now:
> >
> > Consider
> >    3.14159292 degrees, which can also be written as
> >    3deg 8.4955752' or
> >    3deg 8' 29.734512"
> >
> > Depending on how the value is encoded in the Exif data (*), exiv2 will
> > show 7 decimal places for degrees, 5 for minutes and 3 for seconds,
> > i.e.,
> >    3.1415929deg (**)
> >    3deg 8.49558'
> >    3deg 8' 29.735"
> >
> > Converting this to distance, the corresponding accuracies of such values
> > are (at least):
> >    10^-7deg ~ 1.1cm
> >    10^-5'   ~ 1.9cm
> >    10^-3"   ~ 3.8cm
> >
> > i.e., all much lower than the best GPS accuracy you can ever get, so
> > there shouldn't be a concern that the numbers shown do not correspond
> > to a location determined by GPS accurately enough.
>
> These numbers do indeed sound accurately enough.
> However, it seems this is not yet achieved
> (current exiv2 svn and digikam svn):
>
> Take any image and use the "Edit geographical coordinates"
> to provide a position on the highest zoom level (satellite view,
> i.e cars are roughly of the size of the mouse pointer ;-),
> which is I think level 19 in google map terms).
> Accept these coordinates by "OK".
> Then invoke "Edit geographical coordinates" again
> and compare the resulting longitude/latitude coordinates.
> For example I get:
> 51.02370459056218, 13.710897266864777
> vs.
> 51.0236666667   ,  13.7108333333
> So it seems that more digits are lost than expected?
>
> Well, let's have a look where these digits get lost:
>
> Output of `exiv2 -p t`:
>
> Exif.GPSInfo.GPSVersionID                 Byte        4  2 0 0 0
> Exif.GPSInfo.GPSLatitudeRef               Ascii       2  North
> Exif.GPSInfo.GPSLatitude                  SRational   3  51deg 1.42000'
> Exif.GPSInfo.GPSLongitudeRef              Ascii       2  East
> Exif.GPSInfo.GPSLongitude                 SRational   3  13deg 42.65000'
> Exif.GPSInfo.GPSAltitudeRef               Byte        1  Above sea level
> Exif.GPSInfo.GPSAltitude                  SRational   1  0 m
> Exif.GPSInfo.GPSMapDatum                  Ascii       7  WGS-84
>
> I.e.
> 51.023666666666666666, 13.71083333333333332
>
> Alright, so to me it seems that the
> "Edit geographical coordinates" tool does not write
> the necessary number of digits.
>
> As a test:
> With `exiv2 -p v` one gets:
> 0x0002 GPSInfo      GPSLatitude          SRational   3  51/1 142/100 0/1
> 0x0004 GPSInfo      GPSLongitude         SRational   3  13/1 4265/100 0/1
>
> Manual modification:
> exiv2 -M "set Exif.GPSInfo.GPSLatitude 51/1 14222/10000 0/1 "
> IMG_5356test_manip.JPG works fine both in digikam display and the "Edit
> geographical
> coordinates" tool.
> Only on save not enough digits are used ...

Right Arnd,

This is relevant of following Exiv2Iface methods :

- setGPSInfo()
- convertToRational()

... where digits are lost during double to rational conversion.

http://websvn.kde.org/trunk/extragear/libs/kipi-plugins/common/exiv2iface/exiv2iface.cpp?rev=606701&view=auto

Andreas,

There is method in Exiv2 to do this conversion without lost digits ?
If i can use it instead Exiv2Iface::convertToRational()...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Fabien-5]

Fabien wrote:

> Hi,
>
> Gilles Caulier wrote:
>
>>On Friday 24 November 2006 16:26, Arnd Baecker wrote:
>>
>>>when specifying a location with the new
>>>"Edit geographical coordinates" tool   (Brilliant, BTW!!)
>
>
> I agree :)
>
>
>>>on the best zoom-level,
>>>this leads to coordinates like
>>>51.02370121634948, 13.710897266864777
>>>Assigning this to the image and checking
>>>the location with "google maps", "more info"
>>>leads to "51.0235,13.7103333333"
>>>which is off by several meters.
>
>
> I just tried and for me, it works perfectly...
> Note: I open the location for more info in firefox, not konqueror, but
> it should be the same I guess.

Well, sorry. I just had a quick look and didn't check carefully the
values... I saw on the map that it was a the same place, but I didn't
look with very high zoom :)

But, be careful about google map values, they are not always accurate.
On some places, when I use a mixed view, roads are off by more than 10m
than satellite view (in that case, it's the satellite view that's not
correctly georeferenced)...

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

-------- Original-Nachricht --------
Datum: Mon, 27 Nov 2006 13:48:18 +0100
Von: Gilles Caulier

> On Monday 27 November 2006 13:43, Arnd Baecker wrote:
> >
> > Manual modification:
> > exiv2 -M "set Exif.GPSInfo.GPSLatitude 51/1 14222/10000 0/1 "
> > IMG_5356test_manip.JPG works fine both in digikam display and the "Edit
> > geographical
> > coordinates" tool.
> > Only on save not enough digits are used ...
>
>
> Right Arnd,
>
> This is relevant of following Exiv2Iface methods :
>
> - setGPSInfo()
> - convertToRational()
>
> ... where digits are lost during double to rational conversion.
>
> http://websvn.kde.org/trunk/extragear/libs/kipi-plugins/common/exiv2iface/exiv2iface.cpp?rev=606701&view=auto
>
> Andreas,
>
> There is method in Exiv2 to do this conversion without lost digits ?
> If i can use it instead Exiv2Iface::convertToRational()...

There is no such method in Exiv2. If you are happy with 7 decimal places, you could use a simple conversion algorithm similar to that in crwimage.cpp, from line 1015; that should just fit into 32 bit unsigned ints. (Search for "primitive conversion" in the file.)

http://dev.robotbattle.com/~cvsuser/cgi-bin/ns_viewcvs.cgi/exiv2/trunk/src/crwimage.cpp?rev=861&view=markup

Regards,
Andreas

--
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel