Edit Event Data
Event data is intended to be edited in the Offline Copy with off the shelf tools available in ArcGIS. Custom tools can be used, but none are required.
The GISS Workflow assumes the user is comfortable with ArcGIS Pro and has a solid understanding of basic GIS concepts and components. Additional training is available directly from Esri with a NIFC Org Account.
Incident and Event Schema specific editing operations and requirements will be presented here, but this is not intended as a GIS training.
Esri has extensive documentation on editing tools and options in ArcGIS Pro.
Job Aid - Editing Event Data (Instructions for common editing tasks on the Event data)
Best Practices for Editing
Be Mindful of the Coordinate Reference System
When working with Event data in ArcGIS Pro, it is recommended that the data’s coordinate reference system (CRS) be a local projected coordinate system. Event data can be successfully maintained and edited in any CRS; however, the use of a local projection has been determined to be best practice as it provides the most consistency in the workflow.
When working with the NIFS, this means setting the data frame CRS in the map view in the Pro Project Template before creating any other projects, including the Edit Project, and the Offline Copy.
There are no edit sessions in ArcGIS Pro.
However, all edits must still be saved. Once edits are made in a map, the Save and Discard buttons will become available on the Edit ribbon tab.
Because editing is enabled on all available workspaces, it is vitally important to pay close attention to the Feature Template being used when creating features.
Renaming layers in the Table of Contents can help avoid confusion without affecting the underlying data.
Avoid Editing Conflicts
SYNC – Edit – SYNC. Sync the Offline Copy immediately before and after each editing session. Limit editing sessions to short time periods. Sync can also be performed any time during an editing session.
Only ever download and/or edit an incident you are assigned to. The NIFS is a shared editing environment. Be respectful and conscientious of everyone’s data.
Make edits throughout the day. Don’t put off edits until the end of the day – avoid the rush.
Read the Offline-Editing Conflict Resolution job aid. The NIFS is a “last in wins” system.
If there are multiple editors, establish clear geographic, feature type (point, line, poly), or temporal boundaries and communicate frequently about who is editing what.
Educate field data collectors on editing conflicts (link in the bullet above) and coordinate their assignments to avoid them. Geographic boundaries work best for field editors.
Extra care and communication should be paid to suppression repair tracking to ensure Resource Advisors (READs) and other field editors do not conflict.
Only edit the records that require edits. Don’t field calculate a whole column when only a few records are necessary. Unnecessary edits can cause conflicts with other editors using Pro or Field Maps. Unnecessary edits also cause issues with the Archiving and backup services.
DO NOT delete ALL data in the Offline Copy and replace with new features from another database. Maintaining a separate database for edits is not best practice and adds to the GISS workload. Do all editing in the Offline Copy.
Edit the Wildfire Daily Fire Perimeter feature in the Event Polygon layer first, then the Perimeter Line to match the Wildfire Daily Fire Perimeter, then Event Line, Event Point, and Accountable Property features in a logical order. Create and update Label Points for assignments (Division, Branch, Zone) and other labels, if needed.
Divisions and Branches
Divisions and Branches divide an incident into geographic areas for the purpose of work assignments and delineating areas of operation. A Division Supervisor (DIVS) supervises the resources assigned to a division. A Branch is the organizational level having functional or geographic responsibility for major parts of incident operations such as divisions. Divisions exist within specific Branches. The Operations Branch Director (OPBD) supervises DIVS on large incident that contain branches.
Characteristics of Divisions
- Divisions are identified by letters of the alphabet.
- Usually start with “A” at the fire origin and progress in a clockwise order around the incident.
- It’s common to skip some division letters to allow for expansion of the incident (e.g., Div A, Div B, Div Y, Div Z).
- Division map label example: Div A
- Division assignment labels are placed away from the fire edge, between the break symbols, and should not obstruct key features on the map.
- As an incident winds down, adjacent divisions may merge into a single division or be combined (e.g., Div M/N/O), usually temporarily.
- Division break symbols should be rotated so that they are perpendicular to the fire perimeter. Divisions may not occur on the fire perimeter. These are commonly referred to as “floating” divisions.
- Division labels for divisions that are not on the fire perimeter are placed outside of the imaginary line between the division breaks.
Characteristics of Branches
- Branches are identified by Roman numeral labels (or by functional name).
- Geographic branches typically consist of 2 or more divisions. Functional branches oversee a specific function on the incident: Fire Suppression, Air Operations, Law Enforcement, HAZMAT, Structure Protection, etc.
- Fire Suppression and Air Operations Branches are the most common found on wildland fire incidents.
- Map label example: Branch IV
- Branch assignment labels are placed away from the fire edge, between the break symbols, and should not obstruct key features on the map.
- Branch break symbols should be rotated so that they are perpendicular to the fire perimeter. Branch break symbol may serve as both the break between branches and the break between divisions (i.e., replace a division break).
- Branches may not occur on the fire perimeter. A branch may be assigned to an isolated area of an incident or another smaller incident within the main response area. These are commonly referred to as “floating” branches. Branch labels for branches that are not on the fire perimeter are placed outside of the imaginary line between the division breaks.
Attribution and Labeling of Divisions and Branches
The Event Point feature class contains the Division and Branch Break features. The Comment field is used for reference (metadata) to indicate which divisions are separated by a break. This is especially important on larger incidents with potentially dozens of divisions and several branches. Maintaining Comments in the Event Point feature class helps identify those point features. When branches exist on the incident, also indicate in the Comment field which branch the division is in.
The Label Point feature class is an invisible point feature that is labeled directly on top of the point and is used to place Division and Branch Assignment labels in between Division and Branch Breaks. Labels should be in a clear area and not cover any incident or map features.
Use the Attributes Pane
The Attributes pane is the preferred method for both single and bulk attribute updates because domains are set for many of the fields. Field Calculate, custom tools, and scripts will overwrite a domain, introducing typos and breaking queries. To bulk update with the Attributes pane, click the layer heading in the top section after selecting the desired features and edit the table below as normal.
When all features are properly attributed, it is easy to change the Display Field setting under layer properties to leverage the Attributes pane for efficient features updates.
Setting it to a field that best differentiates data for the task at hand (for example Feature Category or Label) allows features to be quickly selected and updated.
If storing the GeoOps Incident Directory Structure in FireNet SharePoint and syncing with OneDrive, pick a folder that is not syncing in OneDrive to store your Edit Project (.aprx) and Offline Copy. This has been shown to reduce Sync errors.
Follow the guidance provided in the Sharing GISS Data Using FireNet365 job aid shared in the Wildfire Response Community Group.
- Save Often! Both the project and edits.
- SYNC – Edit – SYNC. Sync immediately before and after each editing session. Limit editing sessions to short time periods. Sync can also be performed any time during an editing session.
- Perform all edits in an Offline Copy. Avoid editing services live.
- Editing is enabled on all workspaces available. Pay close attention to what layer is being edited. Edits must be saved.
- Edit the Event Polygon first, then Perimeter Line to match, then Event Lines, Event Points, Accountable Property, and Label Points in a logical order.
- Use the Event Point feature class to place Division and Branch breaks that are rotated perpendicular to the fire perimeter.
- Use the Label Point feature class to place Division and Branch labels in between Division and Branch breaks.
- Utilize the Attributes pane for single and bulk updates.
- DO NOT delete ALL data in the Offline Copy and replace with new features from another database.
Editing for Public Data Sharing
Editing the NIFS affects systems and services beyond IMT and local operations. Care must always be taken to follow best practices and ensure proper attribution.
NIFC Open Data Public Perimeter Services
The WFIGS Wildland Fire Perimeter Services shared publicly on the NIFC Open Data site pull features from Event Polygon in the NIFS and are used by individuals and popular applications such as InciWeb. Proper data attribution is essential to ensuring the data is visible where it is needed.
The key in this relationship is the IRWIN ID. The perimeter for each incident must have the correct IRWINID attribute in Event Polygon. Perimeters must also be a single feature. If a perimeter consists of multiple shapes, they must be merged after editing.
NIFS Perimeters will only display in the Public Service with the Attributes FeatureStatus = Approved, FeatureAccess = Public, and IsVisible = Yes. These are the default values for Event Polygon. Any of these values can be changed to remove a perimeter from public view should it be necessary.
View Only Web Maps and EGP Viewers (Situation Analyst)
While only Event Polygon is used in the public services, the other Event Features are available in applications such as Situation Analyst in EGP and web maps based off the View Only Incident Web Map Template. These automatically exclude features with FeatureStatus = Archive, DeleteThis = Yes, and IsVisible = No values, so their proper attribution is required as well.