Beta1 for Digikam 0.10.0 ?

Hello there,

on the digikam website, I read that the release of the first beta for digikam
0.10.0 (kde4 version) is scheduled for today ...
So I wanted to ask if someone knows if it will really be released today, and
if yes, where to get it.

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

[Arnd Baecker]

Hi Gandalf,

On Sun, 17 Feb 2008, Gandalf Lechner wrote:

> Hello there,
>
> on the digikam website, I read that the release of the first beta for digikam
> 0.10.0 (kde4 version) is scheduled for today ...
> So I wanted to ask if someone knows if it will really be released today, and
> if yes, where to get it.

0.10 is still alpha, and not yet considered to be ready
for a beta. So things are (for various reasons) a little
bit behind the release plan (which was done in December,
if I remember correctly).

So if you want to try (at your own risk, and not for production),
you could install from svn.

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

Am Sonntag, 17. Februar 2008 23:21:34 schrieb Arnd Baecker:
> 0.10 is still alpha, and not yet considered to be ready
> for a beta. So things are (for various reasons) a little
> bit behind the release plan (which was done in December,
> if I remember correctly).

Yes, I would like to have a look at 0.10 nonetheless. Is it possible to run a
kde3 and a kde4 version of digikam on the same set of images?
Is there some information similar to http://www.digikam.org/?q=download/svn 
available as how to do the check out of the 0.10 version?

Cheers,
Gandalf

>
> So if you want to try (at your own risk, and not for production),
> you could install from svn.
>
> Best, Arnd
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Gerhard Kulzer-3]

On Monday 18 February 2008 Gandalf Lechner wrote:

> Am Sonntag, 17. Februar 2008 23:21:34 schrieb Arnd Baecker:
> > 0.10 is still alpha, and not yet considered to be ready
> > for a beta. So things are (for various reasons) a little
> > bit behind the release plan (which was done in December,
> > if I remember correctly).
>
> Yes, I would like to have a look at 0.10 nonetheless. Is it possible to run a
> kde3 and a kde4 version of digikam on the same set of images?
> Is there some information similar to http://www.digikam.org/?q=download/svn 
> available as how to do the check out of the 0.10 version?

It is very possible to run them in ||, it is more a question to Kde3 and Kde4  || install (whic depends on your distro), if that works, just call digikam from their different runtime folders. The databases are not the same, the 2 versions cannot mix up things.

Gerhard

> Cheers,
> Gandalf
>
> >
> > So if you want to try (at your own risk, and not for production),
> > you could install from svn.
> >
> > Best, Arnd
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>
>

--
><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º>
http://www.gerhard.fr

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

Am Montag, 18. Februar 2008 08:33:17 schrieb Gerhard Kulzer:
> It is very possible to run them in ||, it is more a question to Kde3 and
> Kde4  || install (whic depends on your distro), if that works, just call
> digikam from their different runtime folders. The databases are not the
> same, the 2 versions cannot mix up things.

Ok, that's sounds good. I have both kde3 and kde4 running here without major
problems, so I think I might give the 0.10 a try. Any hints for the svn
checkout?

Best,
Gandalf

>
> Gerhard
>
> > Cheers,
> > Gandalf
> >
> > > So if you want to try (at your own risk, and not for production),
> > > you could install from svn.
> > >
> > > Best, Arnd
> > > _______________________________________________
> > > Digikam-users mailing list
> > > [hidden email]
> > > https://mail.kde.org/mailman/listinfo/digikam-users
> >
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users

--

Gandalf Lechner
Erwin Schroedinger Institute for Mathematical Physics
Boltzmanngasse 9
A-1090 Vienna
Austria

phone: ++43-(0)1-4277 28268 (office)
skype: gandalflechner
fax:   ++43-(0)1-4277 28299 (institute)
mail:  [hidden email]
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Arnd Baecker]

On Mon, 18 Feb 2008, Gandalf Lechner wrote:

> Am Montag, 18. Februar 2008 08:33:17 schrieb Gerhard Kulzer:
> > It is very possible to run them in ||, it is more a question to Kde3 and
> > Kde4  || install (whic depends on your distro), if that works, just call
> > digikam from their different runtime folders. The databases are not the
> > same, the 2 versions cannot mix up things.
>
> Ok, that's sounds good. I have both kde3 and kde4 running here without major
> problems, so I think I might give the 0.10 a try. Any hints for the svn
> checkout?

Hmm, I don't use 0.10.
The only thing I found was
  http://mail.kde.org/pipermail/digikam-users/2007-October/004286.html

Together with the instructions for 0.9.x this might
get you going ....

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

Am Montag, 18. Februar 2008 14:41:44 schrieb Arnd Baecker:

>
> Hmm, I don't use 0.10.
> The only thing I found was
>   http://mail.kde.org/pipermail/digikam-users/2007-October/004286.html
>
> Together with the instructions for 0.9.x this might
> get you going ....

Thanks Arnd, but given my non-existing experience with cmake and all this, I
think it's better for me to wait a bit longer until some more detailed
instruction or the first beta is released.

Best regards,
Gandalf


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


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

[Gilles Caulier-4]

2008/2/17, Gandalf Lechner <[hidden email]>:

Hello there,

on the digikam website, I read that the release of the first beta for digikam
0.10.0 (kde4 version) is scheduled for today ...
So I wanted to ask if someone knows if it will really be released today, and
if yes, where to get it.

Well, 0.10 is not yet ready for beta1.

All Search tool are broken. The new search framework from Marcel is just include to svn. The Search GUI is not yet update. Timeline is broken too. Code must be adapted to work with new Search Framework...

I have planed too to include marble as GPS search tool : find image accordingly with location over the globe !

kipi-plugins are not yet ported to KDE4 at all. I have ported all my tools : JPEGLossLess, RawConverter, MetadataEdit, GPSSync, etc... All others are not yet ported...

So, you must be patient (:=))))

Best

Gilles
 

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

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

Am Dienstag, 19. Februar 2008 12:05:45 schrieb Gilles Caulier:

> I have planed too to include marble as GPS search tool : find image
> accordingly with location over the globe !

Oh, that sounds great!

> kipi-plugins are not yet ported to KDE4 at all. I have ported all my tools
> : JPEGLossLess, RawConverter, MetadataEdit, GPSSync, etc... All others are
> not yet ported...
>
> So, you must be patient (:=))))

Alright, then it's a bit more patience for me. Although this is really hard in
view of the cool new features in 0.10 ... are there any vague estimates when
0.10 beta1 will be out?

Best,
Gandalf

> Best
>
> Gilles
>
>
> Best,
>
> > Gandalf
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users

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

[Gilles Caulier-4]

2008/2/19, Gandalf Lechner <[hidden email]>:

Am Dienstag, 19. Februar 2008 12:05:45 schrieb Gilles Caulier:

> I have planed too to include marble as GPS search tool : find image
> accordingly with location over the globe !

Oh, that sounds great!

> kipi-plugins are not yet ported to KDE4 at all. I have ported all my tools
> : JPEGLossLess, RawConverter, MetadataEdit, GPSSync, etc... All others are
> not yet ported...
>
> So, you must be patient (:=))))

Alright, then it's a bit more patience for me. Although this is really hard in
view of the cool new features in 0.10 ... are there any vague estimates when
0.10 beta1 will be out?

Good question (:=)))

See below a TODO list of more important pending tasks :

- There are few works to do with current search tools, outside  marble integration witch can be added later.
Marcel work on this part currently.

- There are few improvements to do in all tree view witch uses QT3 to QT4 transition classes. Pure Qt4 are require everywhere.

- Also the model of multiple root paths view in tree-view is wrong. All is merged in the same root branch. This is a temporaly solution   of course.

- The thumbnail KIOslave is obsolete, but a lots of sub-part continue to use it (currently only the main icon view use it). A new multithreading thumbnail loader is used instead. This way is more fast because serialization of image data is slow between a kio-slave and digiKam. Also, using a thread, we can adjust the priority to run it, this is not possible with a kioslave.

- A new image editor plugin have been implemented by a new contributor to fix lens aberation (vignetting, distorsion, and chomatic aberations). This plugin use a new Lens database to process fixes automaticly ! This plugin still under developement
 
- The database now support a flag to identify witch image have been already downloaded from camera. interface from DB is done by Marcel, but i have not yet fixed camera interface to use it.

- Another search tool based on Haar algorithm is planed to process dupplicates/fuzzy searches. The last one is to search an image using a drawing template like imgseek do...

... and i forget certainly few items here (:=))))

What work fine in 0.10 :

- XMP : implemented and used everywhere. My plugin MetadataEdit support it now and you have a new XMP metadata editor (the first one and the more complete under Linux)

http://digikam3rdparty.free.fr/Screenshots/MetadataEditor/

- GPS : I have implemented a new tracklist editor (more than one pictures can be geolocalized at the same time using  googlemaps). Gerhard currently improve it...

http://digikam3rdparty.free.fr/Screenshots/gpstracklisteditor.png

- GPS again :  Database host now GPS position : all image files format can be geolocalized (RAW for ex.) !

- Multiple root paths including remote one hosted by NFS or SAMBA

... and i forget certainly few items here (:=))))

Currently i work on a patch to libkdcraw to support DNG file in writting mode... It's do not work yet... Adobe DNG sdk is not really well documented...

Best

Gilles

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

Hi all,

This list of new features is impressive ! thanks for the good work.

By the way concerning GPS, does the database (in Digikam 0.10) contains
a field to represent the precision of the GPS data ?

I think it would be usefull, let me explain why:
If you localize the picture using google maps at a large zoom : for
instance you localize a picture using the full world view, you just
click on one country lets say "france". If you zoom on france it does
not make sense to display this picture somewhere in france because that
position will be more or less a "random position".

I think database should contain the information that a picture is
located at position x, y, z at precision p meters.
If p is larger than a few pixels at current zoom level then the picture
tag should not be displayed at this zoom level.

If you think it makes sense I can add this as a wish.

Best,

Julien


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

[Gilles Caulier-4]

2008/2/20, Julien Narboux <[hidden email]>:

Hi all,

This list of new features is impressive ! thanks for the good work.

By the way concerning GPS, does the database (in Digikam 0.10) contains
a field to represent the precision of the GPS data ?

yes, as a floating point value.
 

I think it would be usefull, let me explain why:
If you localize the picture using google maps at a large zoom : for
instance you localize a picture using the full world view, you just
click on one country lets say "france". If you zoom on france it does
not make sense to display this picture somewhere in france because that
position will be more or less a "random position".

I think database should contain the information that a picture is
located at position x, y, z at precision p meters.
If p is larger than a few pixels at current zoom level then the picture
tag should not be displayed at this zoom level.

If you think it makes sense I can add this as a wish.

No need for the moment. This is exactly what i would to do with marble.

To have contacted lead marble developper by irc, the current version of marble widget shared as lib is not yet ready to use  with digiKam. I need to wait next stable release planed for KDE 4.1

But i have aready extracted the source code from digiKam core where marble widget need to be included. One c++ file need to be changed for that to use marble  as GPS map browser (not search tool yet)

In 0.10, you will see a new GPS side bar tab on the right. This is where marble will be used. The old GPS tab from metadata  sidebar as deseapear.  Why ?  because, GPS  info are hosted by DB for all items, including read only files. GPS info continu to be written to RW file format of course, but GPS info are become main informations, not only a simple metadata included in files.

 Best

Gilles

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

Hi Gilles,

> But i have aready extracted the source code from digiKam core where
> marble widget need to be included. One c++ file need to be changed for
> that to use marble  as GPS map browser (not search tool yet)
>
> In 0.10, you will see a new GPS side bar tab on the right.
I understand taht you want to move it outside metadata. It makes sense.
Naively I would have thought of a new tab rather on the LEFT of Digikam.
Then you could browse your pictures by album, timeline, or location.

Maybe it would be nice to have both :
 
Use a new tab on the LEFT to display the pictures located on the current
map.
Use a new tab on the RIGHT to display the position of the currently
selected pictures.

What do you think ?

Best

Julien


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

[Marcel Wiesweg]

> Hi all,
>
> This list of new features is impressive ! thanks for the good work.
>
> By the way concerning GPS, does the database (in Digikam 0.10) contains
> a field to represent the precision of the GPS data ?

No, we do not have this field in the database so far.
It would be a double floating point value in meters (or degrees?), which can
be regarded as expected imprecision of the longitude/latitude values (the
correct value lies in the range longitude/latitude +/- precision).
For GPS tags, it could be derived from the "GPS Dilution of Precision" value
if available, and a constant value assumed for GPS.
For coordinates set by Google map or Marble, it would be derived from the zoom
level at setting the point.
We could not store it in the image metadata with standard exif tags.

The question is, do we need this, will we make use of it?
One could argue that real GPS data is very exact, and if you set your
coordinates yourself, do it as exactly as you want.
Viewpoints

>
> I think it would be usefull, let me explain why:
> If you localize the picture using google maps at a large zoom : for
> instance you localize a picture using the full world view, you just
> click on one country lets say "france". If you zoom on france it does
> not make sense to display this picture somewhere in france because that
> position will be more or less a "random position".
>
> I think database should contain the information that a picture is
> located at position x, y, z at precision p meters.
> If p is larger than a few pixels at current zoom level then the picture
> tag should not be displayed at this zoom level.
>
> If you think it makes sense I can add this as a wish.

If we want this for 0.10, we will add it here and now, or not.

>
> Best,
>
> Julien

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

[Gilles Caulier-4]

2008/2/20, Julien Narboux <[hidden email]>:

Hi Gilles,

> But i have aready extracted the source code from digiKam core where
> marble widget need to be included. One c++ file need to be changed for
> that to use marble  as GPS map browser (not search tool yet)
>
> In 0.10, you will see a new GPS side bar tab on the right.
I understand taht you want to move it outside metadata. It makes sense.
Naively I would have thought of a new tab rather on the LEFT of Digikam.
Then you could browse your pictures by album, timeline, or location.

Maybe it would be nice to have both :

Use a new tab on the LEFT to display the pictures located on the current
map.

This is planed. All search tools wil be on the left side.

Use a new tab on the RIGHT to display the position of the currently
selected pictures.

This is already the case...
 
Gilles

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

[Gilles Caulier-4]

2008/2/20, Marcel Wiesweg <[hidden email]>:

> Hi all,
>
> This list of new features is impressive ! thanks for the good work.
>
> By the way concerning GPS, does the database (in Digikam 0.10) contains
> a field to represent the precision of the GPS data ?

No, we do not have this field in the database so far.
It would be a double floating point value in meters (or degrees?), which can
be regarded as expected imprecision of the longitude/latitude values (the
correct value lies in the range longitude/latitude +/- precision).
For GPS tags, it could be derived from the "GPS Dilution of Precision" value
if available, and a constant value assumed for GPS.
For coordinates set by Google map or Marble, it would be derived from the zoom
level at setting the point.
We could not store it in the image metadata with standard exif tags.

The question is, do we need this, will we make use of it?
One could argue that real GPS data is very exact, and if you set your
coordinates yourself, do it as exactly as you want.
Viewpoints

I vote for it if this have a scence for GPS searches..
 
GPS guru viewpoints are welcome here...

Gilles

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

[Gerhard Kulzer-3]

I too vote for it (as a frequent GPS user, including digiKam) :-)

Gerhard

On Wednesday 20 February 2008 Gilles Caulier wrote:

> 2008/2/20, Marcel Wiesweg <[hidden email]>:
> >
> > > Hi all,
> > >
> > > This list of new features is impressive ! thanks for the good work.
> > >
> > > By the way concerning GPS, does the database (in Digikam 0.10) contains
> > > a field to represent the precision of the GPS data ?
> >
> > No, we do not have this field in the database so far.
> > It would be a double floating point value in meters (or degrees?), which
> > can
> > be regarded as expected imprecision of the longitude/latitude values (the
> > correct value lies in the range longitude/latitude +/- precision).
> > For GPS tags, it could be derived from the "GPS Dilution of Precision"
> > value
> > if available, and a constant value assumed for GPS.
> > For coordinates set by Google map or Marble, it would be derived from the
> > zoom
> > level at setting the point.
> > We could not store it in the image metadata with standard exif tags.
> >
> > The question is, do we need this, will we make use of it?
> > One could argue that real GPS data is very exact, and if you set your
> > coordinates yourself, do it as exactly as you want.
> > Viewpoints
>
>
> I vote for it if this have a scence for GPS searches..
>
> GPS guru viewpoints are welcome here...
>
> Gilles
>

--
><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º>
http://www.gerhard.fr

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

[Marcel Wiesweg]

> 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?

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

[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 ;-)
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2008/2/21, Marcel Wiesweg <[hidden email]>:

> 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?

As well, meters sound more easy to use...

But take a ook in marble code from svn. This subject have been certainly studied. Code is clear in marble.

Gilles

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