bcgov / bcgov/wps

Theme, Epics & Capabilities for SFMS Insights

Open
#3,130 0 comments 0 reactions 0 assignees View on GitHub
Collaboration Required Epic UX-Research
Dominant language
Python
Stars
65
Forks
11
Avg merge
21h 25m
Merged PRs (30d)
70

Description

**Timelines:**
Epic 1 by end of February to allow for integration w/ WF1 + Geospatial Apps
Epics 2 + 3 completed by April 1, 2024
Provisional start date = OCT 19, depending on MoreCast 2.0 completion

Total involvement: 6mos = 12 sprints
Refinement: TBD

**Dashboard Target Users:**
Predictive Services Unit + Geospatial Unit BUT All Outputs will be consumed by the Entire BC Wildfire Service
Cost savings vs current contractor costs: TBD by PO week of SEP 25

**Geospatial Team Wants:**
Access to our API to consume outputs for their other apps; they uses the danger rating/fire weather on a map via Spatial Database Engine (SDE to be replaced via a postgres db: servers on order, pilot mid July)
Automatic notification/reporting when/if something fails
Easier way to adjust/change summer vs weather modes
Being able to Rerun indices that are missing (related to server outages/missing weather)
Being able to update/edit weather timestamps
A UX friendly way of Changing/updating any SFMS input value (like grass curing, for example)

**Geospatial Team Future Opportunities:**
What other data do we want, apart from the current SFMS outputs?
It would be great to have a provincial HFI threat analysis: 50 vs 90 percentiles? A combination of values + how these change vs weather, fuel type, elevation?
Ability to easily change/experiment with a new input and see the outputs – do these look correct?
Can we update the fuel grid more often? Can we update the fuel types more often?

# Product Name = SFMS Insights

**Q to the PO:** "what will people be doing differently if we succeed?"

**PRIMARY Product Goal:** Ensure continuity of SFMS functionality through automation (no reliance on contractors or Geomatics Unit). Archive Information for future reference + analysis (currently only 2 days are archived; we need to push this to the entire Fire Season)
**SECONDARY Product Goal:** Enhance calculations to include gridded weather forecast inputs, snow masking, and grass curing and green-up layers from the CWFIS. Incorporate changes to the FWI and FBP Systems when next generation is published and available. Otherwise ensure code flexibility in anticipation of next generation FWI and FBP Systems.
**TERTIARY Product Goal:** Allow for the Spatial Calculations to be extended further out in time (currently 2 days into the future; requirement is 2 weeks out).

**Key Performance Indicator:** 100% Automated Data Service (w/o human interaction)

## Release Plan
### Epic 1: 100% Emulate current SFMS functionality (Should we fail this, services will be cut and we must ensure continuity of service)
- Service should spatially interpolate all fire weather inputs
- Service should calculate spatial fire weather indices into the future
- Service should calculate spatial fire behaviour prediction system outputs into the future
- Service should provide the outputs in an API endpoint for integration w/ other applications
- All the above should be automatically provided twice a day: Once per forecast and updated after Noon Standard time for the observed values

**All work after stage 1 will need to occur in a separate environment to avoid service interruptions during the fire season**

### Epic 2: Enhancing the source of weather inputs to the application (Leveraging MoreCast 2.0)
- We will shift from interpolated weather station forecasts to the use of bias-corrected numerical weather model outputs
- We will leverage numerical weather inputs to perform hourly FFMC calculations; this will enable critical hours calculations for Auto Spatial Advisories
- We will build a dashboard to view the outputs
- The minimum 2 weeks out requirement is to allow for the on time ordering, scheduling, and deployment of human + operational assets based on the expected fire load

### Epic 3: Extending the calculation period from 2 days to 2 weeks
- Current SFMS system only calculates 2 days into the future; only archives the past 2 days
- NEW system will calculate 2 weeks into the future and archive the entire fire season

### **Caveats**
- Starting the Weather Stations for the new 2024 season is dependent on the absence of snow on the ground. Testing will be completed on WF1 archived data. Production testing will be accomplished once the stations are turned on.
- ASA production release = APR 1 for '24 fire season. ASA will stop working if Epic 1 is not live.

### **Value Metrics**
TBD w/ Agile PSU
Time & Effort Now vs Future
Sensitivity: 2 Days vs 2 Weeks
API: Data as a Service

**Inception Workshop planned for November '23**
- Need to fully explore all data inputs and parameters for SFMS.
- Need to document all other applications with SFMS output dependencies.

**Additional Agile PSU assets = 2x Opportunity Market Garden Full Stack IT DEVs (w/ Data Science)**

**Sprint Review Invitee List**
PSU, BCWS Geospatial Team, NRIDS WF1 Integration staff, WF1 PMs, BCWS BI Managers

**Agile PSU Reporting/Connection w/ WF1**
Deputy Ops director BM

Contributor guide

Open the contributing guide

Research direction

Start with the Epic 1 release plan, the API endpoint requirements, and the WF1 archived-data testing caveat; no files or tests are named. Review the dashboard, automation, archival, and two-week calculation goals to separate implementable work into scoped issues. Done should be an agreed implementation scope with dependencies, acceptance criteria, and a release sequence.

Written by the indexing model from the issue text.

Assessment

Tech stack
fastapi, postgresql, python
Domain
backend-api-design, data, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.