RBGE-Herbarium / Specify_forms

For files required for the editing of forms within Specify
1 stars 0 forks source link

CollectingEvent:Locality #46

Closed Sally-K closed 3 years ago

Sally-K commented 3 years ago

Describe the bug Locality data not displaying full hierachy

To Reproduce Steps to reproduce the behavior:

BGB specimen records that have have sub_cnt3 data present SELECT barcode, COUNTRY_CODE, SUB_CNT1, SUB_CNT2, SUB_CNT3 FROM specimens WHERE sub_cnt3 IS NOT NULL AND barcode IS NOT NULL;

Looking at records that have sub_cnt3 level data in BGB http://clonedspecify.rbge.org.uk/specify/query/40/ select co.CatalogNumber, ROUND(p.number2, 1) AS bg_base_num, p.BarCode, ce.localityid, l.localityName, ce.VerbatimLocality, co.yesno1 FROM preparation AS p LEFT JOIN collectionobject AS co ON p.CollectionObjectID = co.CollectionObjectID LEFT JOIN collectingevent AS ce ON co.CollectingEventID = ce.CollectingEventID left join locality as l on ce.localityid = l.localityid where p.BarCode in () and ce.localityid is null ;

Expected behaviour Wild collections Where subcountry data has been standardised and entered into the specimens_to_code table in the MySQL BGBase Dump, collecting event records should have a locality record associated displaying country down to lowest subcountry level in the aggregated locality field subview in collectingEvent . If subcountry data cannot be standardised it should be entered into verbatimLocality with :-: delimiting between each level. Cultivated collections When Garden Location field is not null data should pull into verbatimLocality and wild subcountry data ignored.

Actual behaviour

Screenshots Specimen: E00095895 image

image

Desktop (please complete the following information):

Additional context Add any other context about the problem here.

redrinkwater commented 3 years ago

I think that this is due to how the data are being imported into Specify by Martin. There are two fields in Geography that are used for displaying the position of a place in the Geography tree - name and fullName. Name is just the name of a place e.g. Worcestershire, fullName is the name plus its parents in the hierarchy e.g. United Kingdom, England, Worcestershire. The data are currently the same for name and fullName, just showing the equivalent of name in both. This isn't an issue that needs to be remapped, as there is an 'update tree' function in Specify, if this is run it corrects the incorrect fullName records.

The fullName is used to provide more information in the locality result that is displayed on the ColllectionObject form. Hopefully we should find that once the tree has been updated these records will show more helpful infomation, providing context for the position of the locality in the overal Geographic structure.

redrinkwater commented 3 years ago

This is being ocrrected as part of the work to prepare the production database