Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bpasquer opened this issue Feb 2, 2023 · 4 comments

Comments

@bpasquer
Copy link
Contributor

bpasquer commented Feb 2, 2023

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:

  • apply superseding to biomass calculation
@bpasquer bpasquer modified the milestones: Maintenance - Data, Day 2 Feb 2, 2023
@utas-raymondng
Copy link
Contributor

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

@bpasquer
Copy link
Contributor Author

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?

@bpasquer bpasquer modified the milestones: Day 2, Maintenance - Data Oct 9, 2024
@bpasquer
Copy link
Contributor Author

@LizziOh @atcooper1

One detail that has been overlooked in our discussion about the Fishbase update is how we handle species traits (biomass coeff and Maxlength) updates to superseded species. Specifically, should the updated coefficient value for a current species also be applied to its superseded species?

One complication is that there are cases where biomass coefficients differ between the current species and the superseded one in both the current new Fishbase version. For example:
Chromis Kennensis and Chromis flavomaculata

Chromis kennensis Chromis flavomaculata
current a, b 0.0174, 3.01 0.0148, 3.00
new a, b 0.0178, 2.99 0.0126, 3.03

Let me know what you think

@bpasquer
Copy link
Contributor Author

Decision from catch-up on 20/11/2024:
a's and b's of all fish will be updated using FB values regardless of their superseding status except for spp, square bracket [ ] , and round bracket() observable items.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants