Open smnorris opened 2 months ago
Can user falls table be removed entirely? Probably not but it should be checked against CABD https://github.com/smnorris/bcfishpass/blob/v0.5.0/data/user_falls.csv
Can user falls table be removed entirely? Probably not but it should be checked against CABD https://github.com/smnorris/bcfishpass/blob/v0.5.0/data/user_falls.csv
Feedback is that CABD will include Bonnington falls but I'll just leave the table as is for now.
Next redundant data clean should be user_barriers_definite_control.csv
:
Note that for falls, the usage of this table is now just to prevent falls with observations upstream from being ignored. Data and tables could probably be reorganized/renamed.
For CABD features I'm thinking a table like below, supporting:
blue_line_key
cabd_id
cabd_feature
barrier_ind
barrier_pin_ind
blue_line_key
reviewer_name
review_date
source
notes
source_fix_requested
A barrier_pin
column might have to be per species?
Or we could presume that for falls, any pin related to observations is for salmon/steelhead only.
Currently, if a falls is flagged as a barrier in this table (based on salmon review, such as falls on blue_line_key=356364051
, Herrick Ck), the stream is excluded from BT
habitat output - regardless of how many observations are upstream. I'll treat this as a bug in the BT
model for now but the fix table could be adjusted.
Examine fix tables and remove records that do not actually apply a fix.
Note that this could also be done as an action on PR but that isn't worth implementing until we have better docs on what fixes go where.