Closed Mateo9569 closed 1 year ago
Good find.
that is the correct approach for waterfall.
Looks like 0100-extract-inputs.R
is using co_rearing_km
but we should be using st_rearing_km
(since that is what we say in the methods and because it is more conservative). For the bcfishpass
object in our repo we are using the mean annual discharge model from the remote DB (we will switch to the channel width model soon) and that does not seem to be functioning correctly for that watershed (happens alot). We can see all these outputs by viewing the bcfishpass.crossings
layer for the associated site. On my local build the Perow crossing shows >5km of both CO rearing and spawning habitat and this will be our final results once I take the time to run bcfishpass
again locally and build the new object in our sqlite (we will need to update the priorities table again once that is done). Regardless - we should use ST vs CO for our overall .
Tables 4.2 and 4.4 need the caption changed to reflect ST vs CO modelling (done - will push)
Table 3.1 should include rear_channel_width_min
(done - will push)
@Mateo9569 - for now - can you revise the 0100-extract-inputs.R
script to give us st_rearing_km
estimates vs the co and populate the priorities csv with those numbers. Good to keep in mind that we will do this again once I re-run the model locally with the channel width method and resave our bcfishpass object to the sqlite though.
When I ran the habitat gain estimate section in
0100-extract-inputs.R
and get the resulting csv it gives me a value of 0 in theupstream_habitat_length_m
column. Can I estimate the upstream habitat using GIS (similar to https://github.com/NewGraphEnvironment/fish_passage_bulkley_2022_reporting/issues/30#issue-1508431753)? For the waterfall creek site I estimated the us habitat length up to the waterfall, I'm not sure how far or where to measure for Perow and Stock.