database fields in the future
Locked
 
|
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 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)? 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#photooverlay 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 [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: database fields in the future
|
|
> 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 > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: database fields in the future
|
|
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 ... ;-) Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: database fields in the future
|
|
In reply to this post by Marcel Wiesweg
On Thursday, 7. June 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. > > > > > 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)? I've found no reference to nepomuk on the wiki page, but on http://liquidat.wordpress.com/2007/05/31/semantic-desktop-and-kde-4-state-and-plans-of-nepomuk-kde/ ... There is a Google Summer of Code project to replace digikam’s rating and tagging system with the one from Nepomuk-KDE. ... Marcel, Gilles are you in contact with whoever works on nepomuk for digikam stuff? Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [hidden email] _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: database fields in the future
|
|
2007/6/12, Achim Bohnet <[hidden email]>: On Thursday, 7. June 2007, Marcel Wiesweg wrote: Nobody have contacted me or marcel about Nepomuk stuff... Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: database fields in the future
|
|
On Tue, 12 Jun 2007, Gilles Caulier wrote:
> 2007/6/12, Achim Bohnet <[hidden email]>: [...] > > I've found no reference to nepomuk on the wiki page, but on > > > > http://liquidat.wordpress.com/2007/05/31/semantic-desktop-and-kde-4-state-and-plans-of-nepomuk-kde/ > > > > ... There is a Google Summer of Code project to replace digikam's > > rating and tagging system with the one from Nepomuk-KDE. ... > > > > Marcel, Gilles are you in contact with whoever works on nepomuk for > > digikam stuff? > > > Nobody have contacted me or marcel about Nepomuk stuff... Interesting ;-) I did not find more than this: http://code.google.com/soc/kde/appinfo.html?csaid=91931330FD7D8E30 Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: database fields in the future
|
|
In reply to this post by Arnd Baecker
Arnd Baecker wrote:
> If (2) is more flexible and useable by plugins that sounds like a plus > to me... For me this is the biggest thing. At the moment (as has long been discussed), I would really like a way to store key/value pairs from plugins against "items" and "albums" (including virtual albums - e.g. tag views, searches etc.) For me a key/value pair is enough and things like format conversion (storeing floats/integers can just be done in the plugin). I guess ultimately an interface like kconfig would do fine and could actually make the implementation in e.g. digikam quite simple - it just needs to store a big block of XML and we're laughing. A simple extension of kconfig for this purpose should suffice. WDYT? OK it's not as uber flexible as allowing plugins to add fields but it's a lot more transparent in terms of the kipi API.... unless I've totally misunderstood and you were referring to Digikam plugins rather than kipi plugins........ :S Col _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: database fields in the future
|
|
> > If (2) is more flexible and useable by plugins that sounds like a plus
> > to me... > > For me this is the biggest thing. > > At the moment (as has long been discussed), I would really like a way to > store key/value pairs from plugins against "items" and "albums" > (including virtual albums - e.g. tag views, searches etc.) > > For me a key/value pair is enough and things like format conversion > (storeing floats/integers can just be done in the plugin). For you as a plugin author, this is of course the way to go because an API shared by multiple applications cannot define any sort of database schema, and the application cannot provide a database table specific for one plugin. We do have a table CREATE TABLE ImageProperties (imageid INTEGER NOT NULL, property TEXT NOT NULL, value TEXT NOT NULL, UNIQUE (imageid, property)); right now, there is no problem to implement a kipi method to store values on images, and for albums a similar table can be added. > > I guess ultimately an interface like kconfig would do fine and could > actually make the implementation in e.g. digikam quite simple - it just > needs to store a big block of XML and we're laughing. A simple extension > of kconfig for this purpose should suffice. WDYT? > > OK it's not as uber flexible as allowing plugins to add fields but it's > a lot more transparent in terms of the kipi API.... unless I've totally > misunderstood and you were referring to Digikam plugins rather than kipi > plugins........ :S > > Col Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |