[Digikam-devel] database fields in the future

[Arnd Baecker]

Hi Marcel,

thanks for your reply, and sorry for me being slow - I
was pretty busy and also had to think about your e-mail.

On Thu, 7 Jun 2007, Marcel Wiesweg wrote:

> > Hi,
> >
> > currently the database for digikam is pretty fixed in the sense
> > that there is no way to add new fields on the side of the user.
> > With the database consolidation, on which Marcel is working,
> > there will be several additional fields,
> > http://wiki.kde.org/tiki-index.php?page=Digikam%20development%20discussion
>
> Feel free to add your suggestions to the wiki page.

OK, added some bits; hope I did not vandalize too much ;-)

> > Is there a way to make upcoming framework so flexible,
> > that new fields could be added by users
> > (and changed and searched for within digikam)?
>
> Until now (and until after the Qt4 port), the focus was to get the ability to
> do schema upgrades, not doing the actual schema upgrade that brings new
> fields to the DB.
>
> I see two ways to add new data:
> 1)The fixed-size table:
>
> CREATE TABLE PhotographImageProperties
>  ( id INTEGER PRIMARY KEY,
>  aperture TEXT,
>  focallength TEXT
>  ...
>  exposure TEXT);
>
> This becomes more interesting if the type is not TEXT, but INTEGER and can be

Maybe also FLOAT (for apertures like 5.6 etc.?)

> searched for ranges ("all images with aperture between 5 and 8")in SQL.
>
> 2)the properties table as we have now
> CREATE TABLE ImageProperties
>  (imageid  INTEGER NOT NULL,
>   property TEXT    NOT NULL,
>   value    TEXT    NOT NULL,
>   UNIQUE (imageid, property));
>
> where the value is TEXT and cannot be searched.
>
> Currently I think that (1) is the way to go, having the ability to upgrade the
> databasee schema. For this we need to identify those data fields that are
> usually available together: You might not have GPS information for all
> images, but if you have, you usually have latitude _and_ longitude, so they
> belong into the same table (this example is trivial, for other fields it
> might not be that easy).

Well, then there is the altitude information, which might be
present, or not ...

> Adding such a new table with information does not even break backwards
> compatibility of the database.
>
> (2) has the advantage that it is more flexible in adding and removing fields,
> and can easily be used by plugins, so there are indications to use it, but in
> my feeling it's not the way how a db should be used.

Hmm, I have to admit that I don't understand enough about
designing such a database to make any qualified comment here.
If (2) is more flexible and useable by plugins that sounds like a plus
to me...

Best, Arnd

> > Some examples of possible additional fields
> > -------------------------------------------
> >
> > - heading, tilt information   (see gipfel, new google earth)
> >   This would precisely describe the captured scene.
> >   Note, that the upcoming google KML 2.2 Specs,
> >   has a photooverlay
> >
> > http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#photoover
> >lay which
> >   """allows you to geographically locate a photograph on the Earth and
> >      to specify the placement and orientation of the Camera that views
> >      this PhotoOverlay. The PhotoOverlay can be a simple 2D rectangle, a
> >      partial or full cylinder, or a sphere (for spherical panoramas). The
> >      overlay is placed at the specified location and oriented toward the
> >      Camera."""
> >
> > - There is a very interesting programm called gipfel,
> >   http://www.ecademix.com/JohannesHofmann/gipfel.html
> >   which allows for finding the names of mountains
> >   or points of interest on a picture.
> >   For this the coordinates of the camera are needed
> >   and then by specifying known mountains, an association of
> >   others is displayed.
> >   For this the relevant parameters  are
> >   - View direction
> >   - Nick angle
> >   - Tilt angle
> >   - Focal Length
> >   - Visibility
> >
> > - weather conditions, like
> >   - temperature
> >   - sun/rain/fog/clouds/
> >   - wind: speed/direction
> >   (This type of information could be automatically fetched
> >    from some weather data servers, based on time and GPS location
> >    for each image ;-)...
> >
> > - surely more, depending on the users imagination ... ;-)