Optional enhancement: Redesign or refactor state-specific rules into the core workflow

[j23414]

Context

Currently, supporting state specific builds (PR which was merged on January 20th, 2025) was fast-tracked by splitting out state-specific rules into a custom rules file:

• https://github.com/nextstrain/WNV/blob/main/phylogenetic/build-configs/washington-state/washington-state-rules.smk

Optional future work was to refactor these rules such that they are either incorporated into the core workflow, converted to config-only changes, or dropped. Leaving these as custom rules would require explanation for other states to support their own builds, perhaps a benefit if they need their own custom items.

Description

• Pro for a refactor: Refactoring the state-specific rules into the core workflow would reduce the need for separate, state-specific rule files, making maintenance easier. This option would require rethinking how zip code lat/long values are being averaged by district, state, region. Some logic may be common across other state builds and incorporating into the core workflow would eliminate unnecessary duplication.
• Con for a refactor: Leaving these as custom rules provides an example for states to incorporate their own custom rules. They can still be directed to use the core workflow by only passing in a config.yaml file with their state-focused subsampling. Leaving these state-specific rules as custom files requires less development effort and would allow us to work on more high priority tasks.

Examples

Possible solution