[Digikam-users] Beta1 for Digikam 0.10.0 ?

[Arnd Baecker]

On Thu, 21 Feb 2008, Marcel Wiesweg wrote:

> > I too vote for it (as a frequent GPS user, including digiKam) :-)
> >
> > Gerhard
> > >
> > > I vote for it if this have a scence for GPS searches..
> > >
> > > GPS guru viewpoints are welcome here...
> > >
> > > Gilles
>
> Ok, I will add this field to the database as a pre-alpha change, and add
> support for it in the ImagePosition class.
>
> Will it be more pratical to have the field with the unit "meters", or in
> degrees? Meters seems to me more straightforward to use; the size of a degree
> on the surface of the earth depends on the latitude. Gilles, any opinion?
> Someone who votes for degrees?

Sorry, I am a bit late in this discussion here, but
I am not yet fully convinced that
a field to represent the precision of the GPS data
is necessary, as the GPS data itself could always be made
as precise as possible (i.e. the usual GPS accuracy should
suffice for most situations ...)
 However, my impression is, that we need something which is
a bit more general and more adapted to the features offered by kml.

Below is a longer explanation, but it boils down to use the parameters
needed for a  LatLonAltBox
http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#latlonbox

For a placemark, one then uses an additional Region which
contains the LatLonAltBox with properly adjusted parameters,
to specify, when a given point is visible.
In particular the LatLonAltBox contains
minAltitude and maxAltitude.
It is also possible to not use the altitude information,
but to specify a rectangle in which the placemark becomes visible:

    <Placemark>
      <name> Name of the point </name>
      <Point>
        <coordinates>14.156127,51.522713</coordinates>
      </Point>
      <Region>
        <LatLonAltBox>
          <north>51.6180</north>
          <south>51.3992</south>
          <west>14.0625</west>
          <east>14.4141</east>
        </LatLonAltBox>
        <Lod>
          <maxLodPixels>-1</maxLodPixels>
          <minLodPixels>100</minLodPixels>
        </Lod>
      </Region>
      <LookAt>
        <longitude>14.156127</longitude>
        <latitude>51.522713</latitude>
        <range>1100</range>
      </LookAt>
      <styleUrl>#UserdefinedMarker777</styleUrl>
     <description>
        <![CDATA[  html text description here    ]]>
      </description>
    </Placemark>

One way to specify the LatLonAltBox is to employ the zoom levels
(E.g. zoom=0: zoomed out, zoom=18: large magnification)
used by google maps, and convert these into north/south/west/east.
But of course the same could be done using a direct specifcation
of a length.
In either case some conversion formulae
(zoom-level to degrees or "meters" to degrees).
In my opionion, the zoom-level has the slight advantage
of being "logarithmic". I.e. Increasing the value by one
corresponds to halving the viewing distance.
This leads to smaller numbers, which are easier to memorize.

So I would propose to use [minZoom, maxZoom] to
specify when a given point should be visible.

For some background on tiles and zoomlevels, see eg.
 http://mapki.com/wiki/Lat/Lon_To_Tile
 http://dunck.us/collab/Simple_20Analysis_20of_20Google_20Map_20and_20Satellite_20Tiles
(Note that for some reason, the zoom levels used by google
 are ordered such that eg. zoom=17 is zoomed out while zoom=0
 is zoomed in. Therefore zoom values can even be negative ...)

Now an attempt at the slightly "broader" picture
of the usage of GPS data in the context of digikam:

A) From an excursion one gets
   a) a bunch of images
   b) a GPS track (using some GPS logger)
   and can geolocate all images afterwards.

   ((If one does not have a GPS logger, one could still
   geolocate each image by hand and even provide a fake track ))

   In terms of an organization of directories (=folders),
   something like
     Excursions
     - Excursion1
     - Excursion2
   etc. would be optimal for the following.

B) Search for images within a specified region
   (like Tags or Dates View)

C) Display locations of images on a map

   If one has many images, one has to find a way,
   to only display a subset of them as dots on the globe (eg. marble)
   because otherwise at certain locations with many
   images, nothing (else) can be seen.
   Google earth solves this pretty well for the images
   coming from panoramio.
   However, there still is the problem, that for example
   Tour Eiffel is buried below a cloud of blue dots.

   One possible approach to solve this, is to
   only display *one* point for each folder.
   And even then, this point should only be displayed
   from a certain magnification (zoom level) on, to avoid
   clutter.

   Now, there are certain regions, which contain
   many points, and others with less.
   Maybe there are some algorithms which ensure that
   in each case a reasonable number of points is displayed
   on the map
   (i.e. when zooming in, an isolated point should be displayed much
    earlier than those belonging to a cluster of points, where
    initially just one should be visible).

   In terms of the kml standard, one could think of using
   - LatLonAltBox
     http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#latlonaltbox
     to specify, when a given point is visible.
     (see above for more details)

   - and maybe Region-Based Network Links, see
     http://code.google.com/apis/kml/documentation/regions.html

   ((Slight extension: for a longer excursion, there
    could be several "key" locations, spatially sufficiently separated,
    so that each should be visible for a given folder))


   Then, for each of these "key" locations, one could
   activate (e.g on mouse-click, via a network link) the
   display of the locations of all images in that particular
   folder and also display the recorded track.

So, instead of specifying the accuracy of the GPS data,
I would suggest to provide [minZoom, maxZoom]
which is the converted to the corresponding fields in latlonaltbox.

This allows to cater for
  i)   always visible
  ii)  visible from a certain zoom on
  iii) visible only up to a certain zoom
  iv)  visible in a certain zoom-interval

Of course, this, to some extent assumes,
that internally kml files are generated and passed to marble
for display. Whether this is the most efficient way,
is not clear to me (E.g. I don't know anything on the performance
of marble wrt to loading and displaying large kml files).
Another option is to generate the kml files on-the-fly, triggered
by "View-Based Refresh Queries", see
http://code.google.com/apis/kml/documentation/kml_tut.html#network_links

Well, this got pretty long, so don't hesitate to ask
questions, if something is not understandable ... ;-).

Best, Arnd

P.S.: Of course there will be more wishes in the future
like: GPS track editing/smoothing, track analysis, ...
(but this is better left for a different thread ;-)