add code for generating gradient barriers about bcfishpass HOT 12 CLOSED

Old code to create gradient barriers is in here:
https://github.com/smnorris/FWAToolsArchive/blob/main/fwatools/stream.py#L421

To create gradient barriers for a given stream (blue_line_key):

from FWATools import FWA
from FWATools import Stream 

wsg = 'COWN'
blueLineKey = 354101673
windowSize = 100
slopeThreshold = [.03, .05, .08, .15, .22, .30]


# load stream profile
stream = Stream(blueLineKey, FWA, wsg)

# generate gradient barrier events
# ie, linear events along stream where slope > than given value
# the events are stored as list of tuples:
# [(threshold, blueLineKey, wsCode, localCode, toLocalCode, fromMeasure, toMeasure, fromElev, to Elev, length, slope)]
events = stream.get_multi_gradient_barrier_events(windowSize, slopeThreshold)
eventList = []
if events:
    for e in events:
        eventList.append(e)

# append watershed group code to the end of each tuple
if eventList:
    sql = """INSERT INTO my_table
                 (threshold,
                  blue_line_key,
                  fwa_watershed_code,
                  local_watershed_code,
                  upstream_local_code,
                  downstream_route_measure,
                  upstream_route_measure,
                  length_metre,
                  from_elevation,
                  to_elevation,
                  gradient,
                  watershed_group_code)
              VALUES (?,?,?,?,?,?,?,?,?,?,?,'{wsg}')
           """.format(wsg=wsg)
    FWA.db.execute_chunks(sql, eventList, 500)

Update could easily do the windowing / slope calculation in db. I'm sure it could all be wrapped up into sql but a Python script may still be the simplest way to go for processing many streams/different thresholds

from bcfishpass.

This new script generates the breaks and fixes #7 (but outputs still need QA):
https://github.com/smnorris/bcfishpass/blob/gradientbreaks/01_prep/gradient_barriers/sql/gradient_barriers.sql

@NewGraphEnvironment @nickw-CWF @CaptainMarmot
The method is almost the same - the script starts at the bottom of each distinct blue_line_key and considers each vertex on the stream. But now instead of calculating slope between a given vertex and the next vertex at least 100m along, the slope is calculated between the initial vertex and a point on the stream exactly 100m distant.

The results won't be much different and the added precision is not necessary for fish passage - but it was an easy modification and it seems preferable that the distance along which the grade is calculated is consistent. Down side is that there are more points, but that shouldn't matter.

from bcfishpass.

The best way to do it is probably to take the 100m slope at 50m intervals, regardless of where vertices are. I might try that as well, it should be a simple adjustment.

No - processing the vertices along individual geoms is much easier - it avoids issue of re-setting the 50m counter when dealing with non-contiguous streams, and even just merging the blue lines is fussy. I'll leave it at is - there are far more points output than needed but we generally just care about the one most downstream anyway.

Using 15/20/25 thresholds, these are the record counts:
new method = 5.16million
old method = 4.08million

from bcfishpass.

Very cool. Nice work!

Should line 39 and 40 cover .25 - .30 somehow?

WHEN gradient >= .2 AND gradient < .25 THEN 20 WHEN gradient >= .3 THEN 30

?

from bcfishpass.

Good eye. I've fixed that locally but am still not sure if I want to include all of .10/.15/.20/.25/.30 or just .15/.20 that we are using right now and add the rest as needed.

from bcfishpass.

As you know, .30 is extremely relevant for stream classifications and barrier hunting for any watershed with potential bull trout presence. They can all be really useful for one thing or another though in my opinion. I think I have come across some literature about some applications for ~0.05.... I'll look into it.

from bcfishpass.

Yes, I think I'll just generate every step 5-30. It will be a huge table but that isn't really a big deal, generating the barrier tables from it filters the results down as needed.

from bcfishpass.

This is the record count when running every gradient from 5-30 at 5% intervals:

select gradient_class, count(*) from bcfishpass.gradient_barriers group by gradient_class;
 gradient_class |  count
----------------+---------
              5 | 1790760
             10 | 1845462
             15 | 1887282
             20 | 1885062
             25 | 1856432
             30 | 1633786

A lot of records. But because the table is so basic it is only ~1/4 the size (542MB) of the existing gradient_barrier table that includes geoms and other additional (redundant) fields.

from bcfishpass.

When using these new gradient breaks as barriers in the existing WCRP models, length of potentially accessible habitat is reduced slightly, as expected (GBa=old gradient breaks, GBb=new gradient breaks, all numbers are km):

from bcfishpass.

Looks like you just sharpened the swords. ⚔️

from bcfishpass.

Pretty much. The result does look slightly tidier. Almost ready to merge into main.

from bcfishpass.

fixed with e1a1d68

from bcfishpass.