Manage Suppression Repair Data

As an incident matures, the tracking and reporting of suppression repair efforts may make up a large portion of the Situation Unit’s workload. The National Incident Feature Service (NIFS) has inherent feature categories and attributes to assist with the organization of this data.

Repair Attributes

Multiple attributes are provided to track repair details for each feature. When used in combination, they provide a structured path to track and manage repair efforts from start to finish.

Repair Status

Denotes the feature’s current status with regard to repair activities.

This attribute is the primary driver for suppression repair tracking and should be kept as up to date as possible by all users (with care to avoid editing conflicts).

Summaries and Dashboards are commonly made using this attribute to provide repair statistics.

Domain:
In Use – Fire Management (default)
Needs Assessment
Repair Needed
In Progress
Completed – Ready for Inspection
Completed – Inspected
No Repair Needed
Repair Deferred
Other – See Comments

Repairs Needed

Open text for defining repair work and/or equipment necessary for features that differs from or goes beyond the repair standards set in the Incident Suppression Repair Plan.

If the necessary repairs are standard for the feature, they do not need to be outlined.

Repair Comments

Open text for notes pertaining to the repair work done or in progress. A good practice is to include date and initials along with the comments as they are added.

Repair Priority

Use to designate the priority of repairing certain features over others based on potential impacts and the guidance of the Incident Suppression Repair Plan.

Domain uses coded integers for potential Repair Score calculations of designated areas.

Domain:
0 – Unknown (default)
1 – Low
2 – Medium
3 – High

Archeologist Clearance

Suppression activities have the potential to do more damage to cultural resources than the fire itself.
Many teams do their best to consult archeologists (ARCH) and local Resource Advisors (READ) to minimize that damage.

Planned features can be assessed and Cleared for Operations before they are implemented.

A feature can be assessed and Cleared for Hand Crew or Mechanical Repair before repairs are started.

Domain:
Not Cleared (default)
Cleared for Operations
Cleared for Hand Crew Repair
Cleared for Mechanical Repair

Repair Features

In addition to the repair attributes included for every feature, within the Event Point and Line layers are specific feature types categorized as Repair.

These are common elements of repair work, grouped and standardized to speed data collection and symbol recognition.

Repair Status Symbols

A set of standard symbols built on the Repair Status attribute can be applied to the Accountable Property, Event Point, and Event Line layers.

This allows for a visualization of repair progress on the incident.

A layer file is provided in the GeoOps Folder Structure \tools\Event_Layer_Files folder.

Repair Status Service

The Repair Status Service is one of the many Views of the NIFS. It has been symbolized and filtered to reflect only features that typically require repairs and their current state.

Only the Accountable Property, Event Point, and Event Line are used in the Repair Status Service as only these three layers have features that would possibly need repair.

Planned and other management features that don’t physically exist on the ground, such as Temporary Flight Restrictions and Aviation Routes, are filtered out.

This service must be used in conjunction with another NIFS View. Alone there is no indication of the Feature Category. It is designed to provide a ‘halo’ around the feature.

The Suppression Repair Web Map Template

The Suppression Repair Web Map Template is configured with the Mobile Edit Service and the Repair Status Service, providing both the feature category and repair status information.

• Suppression Repair Web Map Template 2025

Instructions for saving and configuring the Suppression Repair map for use in Field Maps are included in the template’s item description.

Working with READs and Field Observers

Suppression repair tracking results in more data editing and therefore a higher potential for editing conflicts than general operations.

Best Practices for GISS

• Read Offline-Editing Conflict Resolution in the NIFS. The NIFS is a “last in wins” system.   
• If there are multiple editors, establish clear geographic, feature type (point, line, polygon), or temporal boundaries, and communicate frequently.   
• Educate field data collectors on editing conflicts and coordinate their assignments to avoid them. Geographic boundaries work best for field editors.
• Only edit the records that require edits. Don’t calculate a whole column when only a few records are necessary. Unnecessary edits can cause conflicts with other editors using Pro or Field Maps.
• Sync at the start and end of every edit session: Sync – Edit – Sync.
• Utilize Feature Templates to minimize bulk edits and calculations.

Best Practices for Field Users

• Get a clear assignment from Situation Unit Leader (SITL) or lead READ and do not edit features that you have not been asked to edit.
• Beware of offline editing conflicts with the NIFS – “Last in Wins.”
• If working in pairs (e.g., a READ and ARCH), designate one user to make all data edits.
• Sync before shift and at the end of shift to make sure you receive and send edits: Sync – Edit – Sync.
• Set Delete This to Yes for features that are no longer needed. The GISS will review and remove the features from the NIFS.
• Optional: add date, field user’s name, and their role to Repair Comments since there will be multiple edits to a single feature during its lifecycle (e.g., 11/18 READ Flaherty handline still needs repair).

Lifecycle of a Suppression Feature

There is no national workflow for tracking suppression repair.

Utilizing the NIFS provides the flexibility and access to allow each agency, district, or team to implement the process that best suits the incident.

Regardless of workflow, all coordination should go through the incident Situation Unit and communication is key to data integrity.

Below is an example of one possible scenario for the lifecycle of a particular hand line segment.

On an actual incident, there may be more or fewer steps in tracking the Repair Status depending on the available resources and preferred procedures of the Incident Management Team (IMT) or local unit.

Most features will not move through each phase incrementally and that is ok. The process is intended to be flexible to meet the real world needs of wildfire incidents.

1. A Division/Group Supervisor (DIVS) identifies a line for a hand crew to put in during the next operational period.
   The default values for RepairStatus and ARCHClearance are In Use – Fire Management and Not Cleared respectively, but Planned Lines are not displayed in the Repair Status Service because they don’t actually exist on the ground.
   
    
2. An ARCH is monitoring the data in Field Maps and sees the Planned Hand Line. They are aware of an important cultural resource along the ridge the line follows and immediately consult with Operations to protect it.
   The planned handline is moved to follow another ridge, protecting the resource from the fire and suppression efforts.
   The ARCH updates the feature’s ARCHClearance to Cleared for Operations.
   (Note that this is not a required duty for an ARCH and would be uncommon, but shows the potential for real time data management)
   
    
3. When the crew completes the handline the next morning, they update the Feature Type to Completed Hand Line.
   It now displays in the Repair Status Service as In Use – Fire Management.
   
    
4. A week later, as suppression efforts wind down, Operations asks that the GISS set all completed line north of the fire to Needs Assessment to turn it over for suppression repair.
   
    
5. The READ assigned to the area walks the line with an ARCH to assess it. They determine that repairs are necessary and change the Repair Status to Repair Needed and the ARCHClearance to Cleared for Hand Crew Repair.
   (They do not both edit the feature to avoid conflicts, one of them makes both edits)
   
   If no repairs were necessary, the Repair Status could be set to No Repair Needed and the feature’s repair life cycle would end here.
    
6. Once the repairs are completed by the hand crew, the crew boss sets the Repair Status to Completed – Ready for Inspection
   If the repairs had taken longer than one operational period, the In Progress Repair Status could have been applied to track the work.
   
    
7. The READ returns and walks the line one final time before marking the Repair Status Completed – Inspected.