search

aodn / nrmn-application

A web application for collation, validation, and storage of all data obtained during surveys conducted by the NRMN
GNU General Public License v3.0
4 stars 3 forks source link

Use superseded_by length-weight information in biomass calulation after superseding #1230

Open bpasquer opened 1 year ago

bpasquer commented 1 year ago

Currently biomass calculation are done in the endpoints using Length-Weight (LW) coefficient related to the observable_item itself. Therefore, a superseded species biomass is estimated using its original LW characteristics, ignoring superseding information.

Task:

utas-raymondng commented 1 year ago

Please ref to https://github.com/aodn/backlog/issues/4804 for issue tracking

bpasquer commented 1 year ago

Copying email correspondance for reference: E mail from Bene:

Raymond is working on copying biomass coefficients from parent to child after superseding. Here are some assumption we made:

When user superseded a species (child c) with (parent p) , biomass info is copied from p to c If the value of biomass of p is altered, then the new value will be copied from p to c again Editing the biomass values of c on screen with will be disabled after superseding However, what happens in the case of un-superseding? Noting that at this stage there is no database field to store multiple sets of biomass coefficient for a single species, do we want the biomass coefficients of the child to be restored to their original state?

Response from Lizzi:

Thanks for following this up. Regarding the assumptions for the biomass information flow, we think that the biomass information should not necessarily be copied from p to c. In many cases, p is a new species, added to the database when a name change occurs. In these cases p will have a blank biomass, so it is actually better if the biomass is copied from c to p in these cases – we definitely do not want to wipe the biomass for c. Regarding locking the biomass of c after superseding, it is probably not necessary either. When a recorded species observation for c is inserted into an endpoint the species_name is updated to p. The biomass should really come from p for this record too, no? If this is not the case then we do have to make sure that the biomass for p and c are the same, and if one is updated or blank then the other gets populated (perhaps with a warning flag?).

Hopefully this makes sense?