ghini / ghini.web

web and geo interface to ghini.desktop database

ghini

a web based interface to botanical garden databases

rationale

ghini, the name is inspired to Luca Ghini, has the aim to offer a web-based interface to a database complying to the ITF2 reccomendations.

the idea is born in august 2012, after Mario Frasca (mathematician) and Saskia Bantjes (agronomist, environmentalist) get in contact with the cuchubo garden in Mompox. the wish to describe it, the thankful words by the president of the foundation named after the cuchubo garden, pushes the two to seek formal help at the botanical garden of the utrecht university, where they get support by the conservator Eric Gouda.

current plan

this program presents botanical collections in geographic context. the collection is managed with an independent program and we advocate usage of line 1.0 of ghini.desktop.

the user exports the complete plants collection in json format and we import it into ghini.web.

you need a script to import your data from the json export to the ghini.web database.

ghini.web is the code running at the site http://gardens.ghini.me

Setting Up

Simply put: download the code, and install the dependencies.

First of all, you need a recent version of nodejs. The one bundled with Debian8, and possibly with anything based on Debian, is v0.10.29, and that's far too old. Follow the instructions on nodejs.org, or trust me and do the following:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs

ghini.web is a npm-based program. To get all further dependencies: npm install. To start the server: nodejs web.js.

If npm gets confused, rm -fr ./node_modules/ and try again.

Database Connection

ghini.web keeps its data in a mongodb database. You can set up a sample database by running the some_trees.json script, or you can initialize it by running the import tool, feeding it the ghini.desktop 'export to ghini.web'.

using it

• use ghini.desktop to export your database in json format,

• not yet decided how to do this, but you need define the coordinates of the plants,

  • keep coordinates in a text note, with category coords, value decimal degrees separated with a semicolon, first the latitude.

• start nodejs web.js,

• look at your data on http://localhost:5000/,

• open issues to suggest how to change ghini.web.

ghini.web's Issues

script to import json export

user exports based on plants, the script enters the data into a mongodb database.
target collections: taxa; plants.

search by accession number

implement the search by accession number. that is: describe and implement.

include estimate of dimensions for image elements

markers for photos contain a thumbnail. the dimension of the thumbnail is known in the software but not used in the interface, so when we display the thumbnail, the browser reserves space just by guessing. this does not look good in cases where the title is very short so the browser reserves too little space.

let ghini.web serve gardens and panels for ghini.tour

we do not want to distribute huge amount of data with ghini.tour, nor that every time we have a new panel, we need a new version of ghini.tour. we want to keep this information somewhere else, and one option is to keep it in ghini.web.
so, my idea is to keep infopanels in ghini.web, more precisely in the database managed by ghini.web on ghini.me. I have tested the quality of the audio produced by pico2wave, and even worse espeak, and they're really not acceptable for professional distribution. so the data in the database would be the coordinates and the text id, while the audio would be next to it, available for download on demand.

keep user on one single garden

I'm not so sure how to handle this, but once we have users from different gardens, and all using the same accession-number policy (YYYY-####), we will have name clashes, unless we:

• add a field to the accessions, specifying the garden
• make sure the client only looks at one garden at a time.

produce tiles at higher resolution

we can rely on openstreetmap.org and openstreetmap.fr for tiles up to zoom 19 or 20, but for deeper zoom levels, we need keep our own tiles. for the cuchubo prototype we used to reach zoom 22, and we produced that from a very high resolution map of the garden, but I did not put the script under version control so I don't know any more.
I think I was using a svg image, and the imagemagick suite.

upon successful connection, what do we do ?

currently, the server states and does this:

// Upon a successful connection, we send the complete list of plants for
// which we have the geographic coordinates, and register three handlers that
// will be used as receivers of client changes. The client will emit
// messages of type 'move', 'insert', 'delete'.

we have now a different approach:

• Upon a successful connection, we display gardens.

• the user selects one garden, (client tells the server about the choice),

• server replies passing the client plants for that garden.

• user leaves garden - client tells server it's not any more looking at specific garden and deletes from memory list of plants.

we only want very special clients to be allowed to edit plant location information. I suppose I will implement this with some sort of tokens.

gardens still miss a short id

In ghini.web, mongodb automatically assigns a unique code to all objects, as field _id, and it looks like ObjectId("58557201967f5a8bccdf422b").

😔 This is internally useful, but do we want to use it?

In ghini.tour, we ask that sqlite assigns a unique sequential integer number to gardens, field id.

👎 ¡this is too late!, ghini.tour is a pure data consumer …

ghini.web receives gardens (now it's still from a script, and in perspective it is straight from ghini.desktop)

❓ by the way, where is the script?

and it is ghini.web that has to keep plants, panels, pictures from different gardens associated to the garden.

👷‍♂️ it is only in ghini.web that we create the garden id. it can't be earlier, because each ghini.desktop instance is isolated, it can't know of its globally unique garden id.

there are two streams into ghini.web:

when we export (botanic) garden data from ghini.desktop into ghini.web (stream d2w), we should let ghini.web define the garden id. and we need to include this information in the gardens export from g.web to g.tour.

but: if we update from the same garden, ghini.web should be able to recognize it's receiving data from a known garden, not from a new one. I suggest we add a uuid to a garden database upon database creation.

when we finally write (non-botanic) garden data (stream g2w4t), we have to manually specify the garden id, or uuid.

update 'phonetic' field according to new shorten

I've updated the 'shorten' function in cuchubo.js, so we have the same definition in both g.web and g.pocket. We should also update the 'phonetic' field in the database, or we won't be able to find our plants.

Introduction garden short text

Is it possible to create space to write a short text of Country, name garden, location garden, coordinates, hectares, special collection as an introduction.....

find out why we're not showing all plants for Tanager

Tanager has many more plants than just 6, yet this is what we're showing:

Separate icons for different types of vegetation

Is it possible to have different icons for different types of vegetation like trees, palms, bushes, herbs, grasses, orchids.....

garden icon to turn orange and accept dblclick

just as the search results turn orange and react to double clicking, it seems natural to expect the same behaviour also from the garden icon. maybe we could consider removing the link "zoom to garden".

spot or area - location of planting

a plant like a tree can be put on the map as a single point, but what about shrubs, Cyclantaceae, Poaceae, Heliconiaceae, or whatever that occupies an area rather than be on a single spot?
also, is there a zoom level at which we would want to jump from spot to area?

Exporting gardens collections as OpenData

One additional service could be liberate gardens data for public, so scientist, data analyzers or communities around the globe can use this data for any purpose. The export process could include license and file format selection by the author or institution, then the extract appear as a register in a table with: name, date, user, license and file format to download.

Global garden data. This page could suggest to carry this data to OpenStreetMap, as a way to aggregate this data in a global geographic way or a global instance of ghini.web can work this manner too.

script to import pictures into the database

pictures with exif:GPS information can be imported into the database, we only need a script that does that.

add a favicon to the site

there's http://realfavicongenerator.net/ helping people write a favicon that will work on most browsers, and I've used it to generate a rather large set of files starting from our ghini icon. now we should put it on the site.

chrome & explorer "move" the map controls up by some 30px

when you use the map with chrome, or explorer, the first thing you see looks fine just as on firefox.
you click anywhere in the map,
map controls (zoom +/-, scale, and copyright statement) move up
by an amount sufficient to hide the zoom + under the black top menu

visibility of plant layers not safe for zooming

case for the cuchubo garden:
activate the garden,
toggle visibility of plants (plants disappear),
zoom in (plants that would become visible at zoom 22 appear even if plants toggled off)
toggle visibility of plants (visible plants disappear, invisible appear),
zoom out and the mess is complete.

clean up taxon collection structure

I think this would be practical and quick: if taxon collection would contain the fields:
epithet and rank, then, for all ranks at its own rank and above, the rank name associated to the containing taxon name.

to be concrete, Olea:
{rank:"genus", epithet:"Olea", authorship:"L.", family:'Oleaceae', tribus:'Oleeae'}
Phalaenopsis:
{rank:"genus", epithet:"Phalaenopsis", authorship:"Blume", family:"Orchidaceae", subfamily:"Epidendroideae"}
Inga:
{rank:"genus", epithet:"Inga", authorship:"Mill.", family:"Fabaceae", subfamily:"Mimosoideae", tribe:"Ingeae"}

save full-res pics in public server area

not necessarily served by node, we can also configure an independent http service with nginx. maybe better, maybe just the same. but anyhow we have to put the high-res pics somewhere.

do not repeat insertion of same items

when a connection falls and is again established, the server will repeat sending information to the client. this can result in messing up the data in the client if it does not check for repeated elements.

what search results when zoomed into garden?

when you look for a species name, you now get names of gardens having matching plants.
this not so relevant when you are already looking into a garden, you would then want to see the accession code of the matching plants.
you would also want, if zoomed into a garden, to be able to search per accession code.
and I guess we should remove the current 'highlight' menu item, which suggests considering tags, too.

import prototype

import the ghini prototype into this "official" repository.
see also issue 82 in the desktop repository.

what about species match based on metaphone

the binomial name match is now based on a very simple strategy: the user input is considered a sequence of letters and anything containing the same sequence will match.
so you type coca and you get L. leucocephala, E. coca, Coccoloba sp, E. cyclocarpum, I. coccinea, Chrysalidocarpus sp.
some of these matches look surprising to me.
worse: you type coccene, and you don't get I. coccinea.

structure code relative to collections

todavía tengo que mover la lógica de presentación de varios if/case/else en una estructura de clases...

it is possible to freeze-highlight more than one group

zoom into the cuchubo garden
search for '- indica'
freeze-highlight the 'M. indica'

option one to replicate problem:

• click once on Tamarindus indica - this thaws selection, but does not reset it.
• move from table cell for T. indica to table cell for 2014.0030.1
• move back to T. indica cell
• click once - this freezes both selections.

option two,

• click on a palm-tree icon, for example 2014.0158.1, this shows a popup window,
• click on search species, this replaces the search input but does not reset the highlight,
• go to C. nucifera cell and freeze selection - this freezes C. nucifera on top of M. indica.

option three:

• enter a different search term - highlight is not reset.
• continue as option two.

Map of greenhouse

Can you also make maps of greenhouses so that plants can be also located in greenhouse areas

save link to garden and/or coordinates

you cannot send links to gardens, you can only explain how to open a specific garden.
it would be nice if we could send a link to a status of the browser, like:

1. garden; 2) selection; 3) zoom.
   maybe more?

review the statement/disclaimer

• currently still stating this is part of bauble.
• this is not any more only about the cuchubo garden.

server should send client information about presence of species per garden

something like this, and who knows better please tell me better.

db.plants.aggregate({$group: {_id: {species:"$species", garden: "$garden"}, count: {$sum: 1}}}, 
        {$project: {species: "$_id.species", garden: "$_id.garden", count: 1}}, 
        {$sort: {species: 1}}, 
        {$group: {_id: {species:"$species"}, garden: {$push: "$garden"}, count: {$push: "$count"}}})

add fern icon

case 'Thelypteridaceae':
case 'Thyrsopteridaceae':
case 'Woodsiaceae':
    // doc.icon = 'fern'; // there is no such icon yet
    break;

where is the initialization script?

we should have a script for installing and or initializing ghini.web on a new server.
where is it?

make highlight sticky

plants or gardens get now highlighted when you hover on the result line, or on the icon itself.
it would be useful if we could keep a selection highlighted, as to be able to move around in the map keeping the highlight.

store low-res pics in database documents

mongodb database documents can contain binary data, as long as it's less than 16Mbytes.
this looks good enough for pictures at low and high resolution. other considerations however suggest we do not use the database for big images, even if they might fit.
if we do use the database for thumbnails, we want to send them immediately when the server sends the geographic information about the collection.
if we use the file-system for pics at high res, we can choose to keep them somewhere else, so we do not consume available bandwidth to our server.

offer short links or slugs

when sharing garden links, it's quite cumbersome having thinks like http://web.ghini.me/#garden=Jard%C3%ADn%20Bot%C3%A1nico%20de%20Quito
I don't know if I would like a short name, maybe the same as Django slugs.
so that the above would become http://web.ghini.me/#garden=jardin-botanico-de-quito
or maybe something non-mnemonic, shorter, like a unique code: http://web.ghini.me/#g=ro2Xaeyo

add clickable list of participating gardens

offer the user the possibility to look for gardens by name,
then zoom into the selected garden.
at this point the server should push to the client the list of plants, not before.

maybe the client could log out from the selected garden once the user zooms out to the global view.

show gardens at low zoom level

when zooming out to, say, zoom 12 or less, there is little point in showing individual plants.
what about we add icons for gardens, and that they are clickable just the same way as the idea in issue #4
at even lower zoom, we could cluster gardens.