Bigsdb

This version adds support to limit submissions and curators to specific database configurations. This can be useful if two distinct datasets, with harmonised isolate fields, are hosted in the same database. Configurations can filter the dataset using database views and sets. Setting:

`separate_database="yes"`

in config.xml (or in the system.overrides file for a particular config) means that the configuration will be treated as though it was a separate database when it comes to notifying curators of submissions and allowing them to handle them. Curators can be limited to specific configurations by populating the new curator_configs table. Fields can now also be hidden from specific configurations by setting the 'hide' attribute to 'yes' in config.xml (or more usefully in the field.overrides file for a specific config). If a default field value is set, this value is automatically included in the record even if the field is hidden.

An example of where this may be useful is in the recent merging of the PubMLST S. aureus and S. epidermidis databases, so that analysis can be performed across both closely-related species. These appear as distinct when accessed from their respective species pages (https://pubmlst.org/organisms/staphylococcus-aureus and https://pubmlst.org/organisms/staphylococcus-epidermidis) and they each have their own curators. They are, however, also accessible as a merged dataset (https://pubmlst.org/organisms/staphylococcus-spp), where the species field is available to select between the two (this field is hidden in the specific species views).

In addition, the rMLST species id tool now provides text and Excel output files.

This version adds new optional query dashboards to isolate databases. These visually summarise the results of a query.

The new query_dashboard attribute needs to be set within bigsdb.conf to enable these.

Support has also been added for GPS maps to be included within dashboards
.

Version 1.36.0 allows isolate fields to be linked to GPS lookup tables to facilitate mapping. This allows, for example, a field for town_or_city to contain place names, which can then be mapped within the isolate information page and in the Field Breakdown and Microreact plugins.


In order to enable this, the PostgreSQL PostGIS module needs to be installed and an optional table created in the isolates database using the isolatedb_geocoding.sql script. A field described in config.xml can then be linked to GPS lookups by setting the geography_point_lookup attribute to 'yes'.

GPS lookup values can then be set in the curator interface by administrators or curators with the 'modify geopoints' permission set.

Alternatively, lookup GPS values can be set in bulk by using the gp_town_lookups.pl script found in the scripts/maintenance directory. This uses the Geonames database, containing coordinates of town and cities with populations of at least 1000 worldwide, that is distributed with BIGSdb.

Version 1.35.3 improves on the GPS mapping available in the Field Breakdown plugin.

Users can now dynamically change pointer colour and size, and the map is automatically centred and zoomed on the displayed points.

In addition, a race condition was fixed that could occasionally mix up visualisation controls if users rapidly switched between country and GPS fields before the current visualisation was fully loaded.



In addition, record locations are mapped within the Field Breakdown plugin.


You can also use the field as the source for mapping information when exporting to Microreact so that sub-country level mapping can now be used.

The field type 'geography_point' needs to be set as the type attribute for the field within the database config.xml file.

In order to create the field within the isolate table you will need to install the PostGIS module for PostgreSQL and enable this within the isolate database with the following:

`CREATE EXTENSION postgis;`

and then add the field as below, in this case for a field called location:

`ALTER TABLE isolates ADD location geography(POINT,4326);`

[SRID 4326 represents spatial data using longitude and latitude coordinates on the Earth’s surface.]

Geographic data are entered within the curation interface as a single string in the format '[latitude], [longitude]'. The latitude and longitude are individually queryable when performing an isolate search.

If you already have a database that contains separate latitude and longitude data as float values, you can use these to populate a new location field as follows:

`UPDATE isolates SET location = POINT(longitude,latitude)::geometry WHERE latitude IS NOT NULL AND longitude IS NOT NULL;`

Version 1.35.0 adds support for alternative codon tables. Databases can be set to use a particular codon table, as defined at https://www.ncbi.nlm.nih.gov/Taxonomy/Utils/wprintgc.cgi. This can be done by setting the codon_table attribute in config.xml to the appropriate table id number. In addition, if the alternative_codon_tables attribute is set to 'yes', individual isolates can be set with different codon tables. This would be appropriate for databases that contain records of different bacterial species that may use different codon tables.

The selected codon table is used for translations and for checks that involve determining if a sequence is a complete coding sequence (has a start/stop codon in frame, with no internal stop codons).