mfrasca
commented
9 years ago if we use http://copy.com, we could keep all pictures under a folder which has a public link.
the public link would be stored in the database. it could be part of the institution information. this piece of information is independent of the client running Bauble.
if copy is installed on the computer running Bauble, then the same information that can be recovered using the public link (the pictures) would also be already available locally. retrieving the pictures directly from the HD would let one save network traffic, but the location would be installation-dependent. the local root location of the pictures folder could fit in the connection information.
(initially) Bauble would not do anything with putting information in copy, it would just let the user input the file name of the pictures, and show the pictures.
(in perspective) Bauble could accept drag&drop pictures while editing plant information, could reduce the picture size and upload the picture to copy. if necessary, it could rename the uploaded picture in order to avoid conflicts or so that it's easier for us humans to see which pictures are associated to which plants.
currently, you can associate pictures to species, something which is useful for presentation but totally irrelevant when it comes to helping the garden identify plants. the Quito Botanical Garden (JBQ) keeps a list of their plants in a FileMaker "database" (actually a single table), but that software does offer the people at the JBQ to associate two different pictures to each indvidual plant (with and without flowers). this enables the JBQ to ask specialized people identify plants in batches, something which saves them quite a bit of time, as compared to having the specialized person examine the plants in person when the plant is flowering.