UX Research: FOP - How?

[tessmgood]

Describe the task Uncover how Kamloops fire centre handles fire occurrence prediction (human & lightning)

Acceptance Criteria

• [x] we know how KFC does FOP
• [x] knowledge is dropped in #1024

Additional context

• where should this information come from? historical data going back to 1950 for fire incidents and lightning strikes is retained in (separate) databases. There is migration happening from SQL server to Oracle meaning data might be in multiple places. APIs may exist — Action: Ask Vivid about APIs and see if we can extend them (go further back in time)
• how or who predicts lightning starts? BL @ KFC Operations suggesting taking the average of a 20 year history of lightning starts by day as a starting value
• how or who predicts human cause starts? We could factor in historical fire incidents by day, and/or allow modification of our default value - there is some context and human decision making to this
• is there a default value?
• how does the application account for long weekends, or events which may increase human related starts? do we even bother? input field, override default predicted value - maybe edit permissions are given to certain IDIRs, not all
• how does fire starts affect calculated prep level? or does it at all? critical: prep is a function of predicted fire starts and HFI

[tessmgood]

Findings from database chat with BM in IITD:

1. there are many databases

   • Fire incidents and Dispatch: have different schema, with some overlapping fields, would have fire starts data, goes back to 1950. Product Owner is GT (non-technical)
   • WF1 weather schema: there is a table named 'lightning', data goes back to 1981 in legacy SQL server, 2018 to current data has been migrated to Oracle, check migraiton progress with Vivid. Product Owner is DH.

2. there is a database migration happening from SQL server to Oracle

   • recent history should be in Oracle, further back is to be migrated — might pose a short-term challenge for us in accessing historical data.

3. APIs have been developed by Vivid to grab some of this same information we're interested in (starts, lightning)

   • ACTION: in our to-be-scheduled Vivid chats, ask about APIs and how we can extend them. They appear to only pull one year of data, whereas we are interested in 20 years.

[tessmgood]

On lightning, BL (Senior Wildfire Operations – Kamloops Fire Centre) shared the following (TLDR at the end):

Historically, folks have used Sparky, now they are running database reports to predict starts

• When running reports, e.g. for Lilooet, they run it for 20 years, for that specific date of interest, e.g. July 22, so are looking for the average fire starts over 20 years on that day -- They then look at that prediction over 3-7 days (prep period+). “More time = more opportunities for a fire” — the daily prediction approach affords ‘less precision and art’, but a good picture over the prep period
• BL suggested 20 years is a great start, but that we might want to allow flexibility in the future (5, 10, or 20 year historical average) -- 20 years gives a conservative estimate and regulates the historic/severe seasons
• BL said that if we have lightning starts predicted, we can then adjust the value (input field) for: -- Forecasted lightning (e.g. a lightning event on our radar), dry lightning events -- Heat domes and other shenanigans courtesy of Mother Nature -- Human activity (e.g. a large music festival being hosted on the upcoming weekend) -- Etc.
• On adjusting values such as predicted starts, BL suggested we might want to consider restricting that ability to some IDIRs (read vs edit rights) -- We discussed the challenges of this given the rostered approach to who does prep work each week -- He suggested it would be easy enough for him to define the ~8-16 folks at the beginning of the season who should have edit rights. --- Someone from a Zone (ZWCO) might do a plan section, Plans Chiefs, RWCOs should have access, etc.
• Interesting nugget: some Fire Centres break out weather preparedness areas differently, e.g. SE FC has 3 weather prep areas but 6 zones. Fortunately for Kamlopps, the prep areas map to fire zones. This may get interesting as we roll in other FCs? It’s an action item for me to dig into and better understand
• Interesting nugget 2: “at the end of the day, it’s not good if we have the entire prep calculation process automated” why? There’s a lot of value in having staff stop, think, and be encouraged to adjust inputs (FOP, grass curing) to reflect in-the-field observations and other context. If they blindly accept calculated prep levels, things might get missed, they don’t learn and develop their expertise. This comment pertained more to grass curing (site visits, grounds truthing) but relevant to lightning/starts as well. I’m hearing this sentiment from multiple stakeholders @ KFC.