Problem
bcfishpass species parameters (gradient thresholds, channel width ranges, observation count thresholds) are scattered across SQL scripts. Need a single way to load parameter sets from any source for the frs_break() / frs_classify() pipeline.
Proposed Solution
frs_params() — load parameter sets from pg table, custom table, or local CSV. Returns a list ready for purrr::walk() over the pipeline.
# Default: bcfishpass parameter tables already in pg
params <- frs_params(conn)
# Custom: your own table with experimental thresholds
params <- frs_params(conn, table = "working.my_thresholds")
# Offline: CSV for rapid iteration without touching the database
params <- frs_params(csv = "my_experimental_thresholds.csv")
Design decisions
- Returns a list of per-species param sets, each containing gradient thresholds, channel width ranges, species codes, observation thresholds
- CSV enables scenario testing without DB access: edit locally, run both, compare
- Schema for the default bcfishpass tables is configurable (same
options() pattern as other fresh functions)
- No opinion on what the params mean — just loads and normalizes them. The consuming functions (
frs_break(), frs_classify()) interpret the values
Depends on
- None (can be built first)
Problem
bcfishpass species parameters (gradient thresholds, channel width ranges, observation count thresholds) are scattered across SQL scripts. Need a single way to load parameter sets from any source for the
frs_break()/frs_classify()pipeline.Proposed Solution
frs_params()— load parameter sets from pg table, custom table, or local CSV. Returns a list ready forpurrr::walk()over the pipeline.Design decisions
options()pattern as other fresh functions)frs_break(),frs_classify()) interpret the valuesDepends on