Securing Incident Information

One of the most important tasks for the SIT Unit is incorporating updated incident information into the current products for distribution.

There are a multitude of ways updates can be captured and this is an ongoing process throughout the entire incident which can quickly become an overwhelming workload if not organized.

Best practices include establishing and communicating hard deadlines for edits for the next operational period (e.g., 1900 hrs.), establishing deadlines for periodic edits based on meeting schedules (e.g., 1500 hrs. for afternoon planning meeting), and properly documenting all changes received.

Markup Maps


Updating fireline from red to black, Management Action Points, Division Breaks. Planning meeting will cause updates, also updates throughout the day from various sections.

Best Practices

Edit maps and markup maps become records and are saved in doc box in case they are needed later for review. Try and consolidate markups on as few maps as possible (preferably a single map). Document specific markups with comments, contact info for markup source, and Situation Unit Leader (SITL) approval.

Watch Outs

SITL approval needed for all updates. Safety zones need to be accurate dependent of scale on map (symbol on the map could show up in the wrong spot). Markups need to come through official channels (through the SITL), in a format that can be documented (no text messages!!)

Field Data Collection


New incident points, firelines, GPS perimeter, suppression repair. Updates to existing incident features.

Best Practices

  • Collector: SITL approval process in place, required use of the Collector Name field (name and position). Comment field is a critical element that should be filled out whenever possible.​
  • Avenza: Establish a standardized workflow for Avenza data. Example workflow documents (IMT2 CA).
  • GPS: Map and evaluate GPS data with data collector, capture additional comments and metadata with that person.
  • Coordinates: Capture on general messages whenever possible for documentation. Plot and map coordinates and reconfirm plotted locations with the person who provided the coordinates.
  • Standardize coordinate formats to degrees decimal minutes if possible. Communicate standard to incident staff.

Watch Outs

  • Offline-Editing Conflict Resolution in the National Incident Feature Service (NIFS) and Hosted Feature Services [below].
  • Collector: Data synced without Collector Name.
  • Features collected requiring other approval at a higher level (e.g., proposed helispots must be approved by Air Ops, safety zones must be approved by safety officer).​
  • Avenza: Do not attach pictures when emailing.
  • GPS: Datum, coordinate system issues. Clearing old data or data from other fires. Make sure contact info is attached to the GPS device.
  • Coordinates: Coordinates received without Datum or unclear format.

The National Incident Feature Service (NIFS) and ArcGIS Online hosted feature services provide huge advantages in terms of data sharing and a common operating picture. However, it is important to remember that these advantages are due to everyone using the same dataset. Editing this dataset is a responsibility not to take lightly and is often complicated by a lack of connectivity in typical wildfire environments. Offline editing allows us to mitigate this issue, but introduces its own complications and added considerations.

Offline editing in ArcGIS employs a “last in, wins” policy for conflict resolution. This applies to both offline maps in Collector and Local Copies in ArcMap.

Conflicts are detected at the feature level. Meaning if two users edit the same feature, even if they each edit different attributes, it is considered a conflict, and the feature from the user who syncs second (last) will completely overwrite the first (essentially deleting the first user’s edit).

Features that are included but not edited in an offline Collector map or Local Copy will not overwrite anything during a sync.

Example 1:

A Field Observer (FOBS) takes a collector map offline before leaving the ICP in the morning. The FOBS makes edits all day, including changing the Repair Status field on DP10 to Needs Repair.

While the FOBS in the field, the Geographic Information System Specialist (GISS) is instructed to move DP10 half a mile down the road.  The GISS creates a Local Copy, moves the point and updates the attributes, and syncs back to the NIFS.  

The FOBS returns that evening and syncs the edits.

The moved DP10 will be replaced with the feature present in the FOBS data, meaning it will return to the prior location with the prior attributes, with the Repair Status field update made by the FOBS.

Example 2:

A FOBS takes a collector map offline before leaving the ICP in the morning. The FOBS makes edits all day, including changing the Repair Status field on DP10 to Needs Repair.

Meanwhile, the GISS creates a Local Copy and adds several new drop points but does not edit DP10. The edits are synced back to the NIFS.

The FOBS returns that evening and syncs the edits.

Since no features were edited by both users, there are no conflicts and all edits are kept in the NIFS.

Example 3:

A FOBS takes a collector map offline before leaving the ICP in the morning. The FOBS makes edits all day to existing features.

A GISS creates a Local Copy and runs Calculate Geometry on all the features.

The FOBS syncs before the GISS checks in the Local Copy.

The GISS checks in the Local Copy, overwriting every edit the FOBS made that day.

Example 4:

The GISS on Fire 1 is unable to create a local copy of all the Fire1 features without including several points from Fire 2.

The GISS on Fire 1 creates a local copy first thing in the morning and makes edits all day but is careful not to touch any of the Fire 2 points.

The GISS on Fire 2 makes edits to the Fire 2 points that are included in the Fire 1 Local Copy and syncs them with the NIFS.

The GISS on Fire 1 finishes their edits and runs Calculate Geometry on the entire Event Point layer then syncs back to the NIFS.

Fire 2 sees their points revert back to as they were when Fire 1 created their Local Copy.

Example 5:

FOBS 1 and FOBS 2 are both assigned to Div A.

FOBS 1 is assigned to collect pump locations while FOBS 2 is assigned to assess the Repair Status of suppression features.

Both are using offline maps in Collector.

FOBS 1 decides to update the Comments on several of the line features throughout the day.

That evening FOBS 2 returns first and syncs the map. FOBS 1 returns and syncs the map second, overwriting all the features on which they updated the comments. All edits made by FOBS 2 on those features are lost.

GISS Watch Outs!

  • Creating a Local Copy in the evening when field editors are returning to camp and syncing their offline Collector maps.
  • Running bulk update tools such as Calculate Geometry or custom scripts on Local Copies where data from other incidents is present.
  • Multiple field editors working in the same area without coordinating assignments.

Remote Sensing

  1. NIROPS – National Infrared Operations.
  2. CO MMA – The Colorado Multi-Mission Aircraft can be requested through proper ICS channels for daytime Infrared (IR) data collection. Primarily a Colorado resource, they are often found serving other regions throughout the fire season.  Collected data can be accessed near real-time, through EGP Situation Analyst.
  3. Gray Sky Imagery Service – Imagery service provided by the Geospatial Intelligence Center. High-resolution aerial imagery collected over areas that experience significant structural damage or loss. This will only be available on select incidents, but features rapid collection and processing when it is.
  4. EGP Satellite Imagery.

Other Data

  • Data Source – TFR shapefile – shapefile download at top of page near NOTAM number.



Print This Page


Page Last Modified / Reviewed: