Closed lucy-schick closed 2 months ago
can sort of see an inlet drop in the barrel photo. good eye though - from inlet photo we don't really see it
8478_us
was fished solid for a long way and time was really tight that day so we did not log a separate site for the electrofishing that happened. This causes it to not have utms in hab_fish_collect
object with our scripts/tables.R
script.
hab_fish_collect
maps the location of the fish. It's build with scripts/outgoing-mapping.R
but this script will move to scripts/02_reporting
directory
Same thing for Gramaphone (extra detail about that one in separate issues). there is nothing in the name
to tell the script to capture the UTMs within the enroute component hab_loc2
object.
We will add custom call to keep those UTMs in hab_loc2
, reference this issue with commit and make a new issue in fish_passage_template_reporting
so that we know that next time we need to be sure to name our sites.
Also of relevance - a valid way to break up long electrofishing sites with low fish densities is to georeference each fish (ie. join gps track_points
times to fish capture times) and break up the site into components randomly. Something we hoped we might do - but something we can put on the backburner. Pehaps a tutorial for that one makes sense. it would be fun
Above was dealt with in scripts/tables.R
https://github.com/NewGraphEnvironment/fish_passage_skeena_2023_reporting/blob/f0f72a43acac0ee52f41c94d470e61fda15378b1/scripts/tables.R#L265 zoneish
Added site length to 8478_ds_ef1
as the 3 downstream sites were fished sequentially with no gaps. Measured distance in QGIS. Added to {qgis}/Project Specific/Field Data/2023/form_fiss_site_2023
and {repo}/data/habitat_confirmations.xls
Electrofisher seconds were missing from 8478_us_ef3. Review of photos shows a count of 1385s. this jogged my memory that we had forgotten to reset the counter for all 3 upstream sites so recorded total seconds with intent to subtract site from site as follows
Should have noted this on the card!!
ef3 = 1385 - 1017 = 368 ef2 = 1017 - 604 = 413 ef1 = unchanged at 604
Will change in {repo}/data/habitat_confirmations.xls commit and close with push
looks like site 8478 imports raw time represented in PDT so is converted incorrectly in places like habitat_confirmation_priorities.xls
. not sure why but seems not related
to method of time conversion. Maybe doesn't matter but flagging here. Very strange and potentially not the only site it happened at. Guessing is related to some sort of manual manipulation of the forms in Q but not confirmed.
this is where it was noticed - https://github.com/NewGraphEnvironment/fish_passage_skeena_2023_reporting/commit/87840dfb0f5c6f7dc4159ee2ee1131a2a7ae8888
upstream gradients include one incidence at 20% however this was taken at very top of site in separate reach to get estimate of gradient beyond likely fish bearing limit. this skews the gradient in the fish bearing reach so it appears steeper than it is.
should be removed with detail added to comments in submission form and report memo.
Surveyors observed a 0.7m high cascade roughly 200m upstream of the crossing and a second cascade, 1m in height, is noted 200m further upstream in the FISS database
not worth submitting to province since 0.7 is really small and expected in a 10% system. Also we captured fish upstream of here so its not relevant to fish distribution. Will remove from hab con and form_fiss_site
"cascade outlet" is not common terminology. step pool morphology and plunge pool are though. 1.5m of road fill is actually really shallow vs deep. large amounts of fill is like 5m to 30m type of thing. 1m is almost a minimum (although occasionally there is less)
"cascade outlet" is not common terminology. step pool morphology and plunge pool are though. 1.5m of road fill is actually really shallow vs deep. large amounts of fill is like 5m to 30m type of thing. 1m is almost a minimum (although occasionally there is less)
Okay good to know thank you
removed the cascade feature from habitat_confirmations.xls
and form_fiss_site
inlet_drop_yes_no