[Nomad FR]: Saving maps for formal communications and official records

[Den-Boychuk]

Contact Details

GitHub @Den-Boychuk

What is needed?

Overview

• A request was made elsewhere for Nomad to save maps
• This long post (apologies) has examples and outlines suggested requirements and considerations for saved maps, based on my experiences with FireSTARR-in-Ontario (“FireGUARD”) and FireSTARR-WMS
  • People who make and use fire growth maps will have better judgement
• I’m not implying that the mapping suggested here should be done in Nomad or by its developers
  • It can be done in other applications or scripts, or it can be done by agency or other people
  • E.g., Nomad could export shapefiles (like Prometheus) or PNG files, or users could take screenshots
• This post also outlines a difference due to:
  • FireSTARR-WMS running nearby fires only as groups
  • Nomad running nearby fires as either as groups or individually
  • This raises a question of whether Nomad could or should produce fire size statistics

How Ontario saved maps before (now broken)

• Most of my suggestions in this post are based on the design and use of FireSTARR-in-Ontario (“FireGUARD”), which made comprehensive 15-page PDFs (with burn probability, weather forecast, impact, and risk)

Caption: Thumbnail of FireSTARR-in-Ontario’s (“FireGUARD”) summary page

• Example 15-pg PDFs:
  • Large fire: https://pubs.cif-ifc.org/doi/suppl/10.5558/tfc2025-015/suppl_file/tfc2025-015supp6.pdf
  • Small fire: https://pubs.cif-ifc.org/doi/suppl/10.5558/tfc2025-015/suppl_file/tfc2025-015supp7.pdf
  • FYI, these are scaled to print on 11”x17” paper or view on screen
• The PDFs were to be a temporary delivery method, until on-screen delivery was developed, which never happened
  • But the PDFs were integrated into operational processes, including the “Fire Assessment Report”, and became official records
  • FireGUARD was completely automated to run every new fire and update all active fires twice daily
  • Each run generated a new, timestamped PDF, which was automatically added to the existing share drive folder hierarchy that collected documents about each fire
  • The PDFs remain in demand for resurrection

How Ontario saves maps now (partly broken)

• FireSTARR-in-Ontario (“FireGUARD”) is not functioning
• Ontario’s “AFFES Mapper” web app displays the latest FireSTARR-WMS map as a layer
  • This temporary implementation has friction and limitations
  • FireSTARR in AFFES Mapper has no legend, simulation metadata, checklist, warnings, disclaimers, or other information that is suggested in this post
• AFFES Mapper:
  • Shows fire operational information layers, e.g., basemap, satellite imagery, values, fuel type, fire weather, real-time suppression resource locations, lightning, fire perimeters, etc
  • Runs on end-of-life technology
  • Has a broken save-the-current-map button
    • The workaround is to manually save screen clips in documents and manually add metadata, which busy people shouldn’t have to do

Suggested requirements and considerations for saved maps

• This is an attempt at an exhaustive list to consider
• It’s too much content for a 1-page map
• Some items are debatable about inclusion

Operation and design requirements or considerations

Should be efficient to produce

• Ideally, one click to generate (and archive?)

Should be quick and easy to distribute, view, print, and archive

• E.g., PDF or PNG, i.e., not requiring others to launch Nomad or GIS software
• Some people will use maps in briefings and reports

Should have a multi-map view for fast and easy interpretation

• Traditional progression maps can’t be constructed out of burn probability maps
• Having multiple maps on one page is a way of showing potential growth over time in one view
• This helps people quickly assess and compare fires for initial triage
• A multi-map view may also be useful in the Nomad UI

Content requirements or considerations

Should include standard cartographic information

• Legend, scale, north arrow, location, projection?, others?

Should include relevant operational information

• Fire ID(s)
• Weather forecast source, e.g., “GEPS 21-member ensemble”, and starting indices
• Alternative scenarios are possible, so a title and maybe brief description of the scenario, e.g.:
  • “Baseline”, “M2 changed to M1”, “Grass curing 30%”, “Custom wx no. 3 worst case”, “Perimeter updated manually”, “South flank marked ‘held’”
• Timestamp/ID of the starting perimeter
• Start and end time of the fire growth simulations

Should include run time and app versions

• Timestamp when the run was done and the analyst
• Nomad and FireSTARR software versions

Could include a checklist, reminder, warnings, disclaimers (see FireGUARD examples)

• A checklist for verifying map accuracy
• A reminder of the meaning of burn probability maps
• Boilerplate warnings about model assumptions and limitations and using-software-at-your-own-risk
• These seem suitable for separate, accompanying page(s)

May need to include document management information

• In Ontario, documents that support decisions are official business records that require ~7-yr retention and discoverability
• Sensitivity classification (Ontario uses Unclassified/Low/Medium/High)

Misc: privacy, accessibility, languages

• Are any maps restricted from public distribution? Story: a threatening-looking FireSTARR map once frightened the public. FireSTARR doesn’t represent suppression or quiet flanks, so the threat can look overstated. So, Ontario started restricting and password protecting PDFs, so maps for the public would only be accompanied by a person to interpret the maps.
• Ontario may need to have an offer for alternate formats for accessibility, per legislation
• Are other languages needed or desirable?

Differences between FireSTARR-WMS and Nomad

• The same FireSTARR C++ executable is used by FireSTARR-WMS and Nomad, but they use different processes and make somewhat different products for somewhat different purposes
  • (If inputs are identical, then outputs are expected to be identical)
• Many differences are outlined in the table below
• A complicating difference is the number of fires in a single run
  • FireSTARR-WMS runs all nearby fires only as groups
    • A script assembles groups onto a raster, which is read by the C++ executable
    • The C++ executable:
      • Propagates fires from all burning edge cells myopically
      • Isn’t aware of individual fires or their IDs (any individual fire can be non-contiguous per its GIS perimeter)
      • Merges fire fingers and multiple fires implicitly
  • Nomad:
    • Runs individual fires
    • Can presumably run non-contiguous fires per their GIS perimeter
    • I don’t know if multiple fires can be selected without first merging their perimeters
  • FireGUARD:
    • Ran only individual fires
    • Produced fire size statistics and a histogram of fire sizes (see examples below)
    • In contrast, FireSTARR-WMS doesn’t produce the statistics or histogram, because it wouldn’t make sense with groups
  • Question: should Nomad produce fire size statistics and a histogram of fire sizes for individual fires?

Caption: Example of FireGUARD run information and fire size statistics

Caption: Example of FireGUARD histogram of simulated fire sizes

Table showing many differences between FireSTARR-WMS and Nomad (this seems useful for future documentation because people may reasonably assume that they are more similar than this):

Characteristic, Attribute, or Feature	FireSTARR-WMS	Nomad
Purposes	Initial triage of fires according to growth potential Landscape-wide situational awareness	Similar to Prometheus (?) FBAN forecasting and analysis of individual fires’ growth potential
No. of alternative scenarios (fire weather, fire behaviour, starting perimeter, fuel type)	None; uses only default settings	Unlimited alternatives can be manually created by the analyst
Operation	Automated, on a schedule	Manual, on request
Can run fabricated fires	No	Yes
Platform	Cloud (can be installed on a local machine)	Local machines (and server/cloud?)
No. of fires in a run (any one fire can be non-contiguous per its GIS perimeter)	Variable: fires are assembled into a group by a script that selects a fire from a list, and adds other fires that are within X km of fires already in the group (this is so burn probability is correct if fires merge)	A fire is selected (or fabricated) to run I don’t know if multiple fires can be selected without first merging their perimeters
Saving method	All WMS outputs are archived automatically A UI to access the archive is planned	Presumably a project file is saved manually I don’t know if map image files and metadata can be exported separately from the presumed project file

How will this improve the project or tool?

The suggested requirements and consideration can help inform the saving of maps and other outputs useful for analysts and decision-makers.

[emdiaz0031]

We will continue to refine map export to NOMAD.