[Digikam-devel] database fields in the future

[Marcel Wiesweg]

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

>
> 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 
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).
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.


>
> 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 ... ;-)
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel