Uploading Shapes
When managing incidents, you might need to upload incident-level shapes that were created outside of WFDSS. These shapes may include fire perimeters collected by GPS units or drawn in a GIS. All shapes loaded into WFDSS require a projection file and are stored in the government standard NAD83 GCS. If you upload a shape as a NAD83 GCS, it will not need to be reprojected. If you upload a shape with a different projection, WFDSS will automatically reproject it to NAD83 GCS. A complex shape will be 'thinned' by WFDSS for display purposes, but the unmodified shape is stored in the system and all acreage and inventory calculations are made using the original upload file.
The following shape types can be loaded:
- Incident Owners and Editors can upload all incident-level shape types for an incident in WFDSS.
- Users assigned the Dispatcher role can upload all incident-level shape types except Incident Obj. Shapes and M.A.P.s for incidents in their geographic area.
- Users assigned the Fire Behavior Specialist role can upload all shape types for any incident, regardless of the geographic area.
- Users assigned the Data Manager role can upload Other Unit Shapes and Management Requirement shapes into WFDSS for their respective units. These shapes contain spatial information about local values data and are unit-level, not incident-level.
- Both zipped shapefiles and KMZ files can be uploaded into WFDSS.
CAUTION: It is not advisable to use the same perimeter for both the ignition file and the barrier file. If the two files overlap, or depending on the landscape resolution used, the barrier file could actually overwhelm the ignition file producing unexpected results.
Before uploading a shape, verify the following:
- The incident you want to upload the shape for exists in WFDSS, and that you have editing privileges for the incident or analysis.
- The files associated with the shape are current, correct, and belong with the incident or analysis.
- The shapefile is less than 3000KB (3MB).
- The shapefile is in a zipped format.
- If multiple shapes exist in the shape ZIP file, these must be merged into one individual multi-part shape (a single line in the attribute table) in a GIS before being uploaded into WFDSS.
- The shapefile should not contain more than approximately 150,000 vertices (points). Large and complex shapefiles with more vertices should be thinned in a GIS or broken into smaller shapefiles before upload. This link provides information on how to count vertices in ESRI’s ArcMap 10.
- The shape ZIP file must contain one shapefile with the following file extensions:
- .DBF
- .PRJ
- .SHP
- .SHX
- .SBN (optional)
- .SBX (optional)
- The files contained within the ZIP file are at the same directory level. (You can't have a folder inside the ZIP file or the shapes won't upload correctly.)
- Large and complex shapes often contain lines that cross and other problematic spatial artifacts. This ‘cartographic spaghetti’ is difficult to untangle and WFDSS may be unable to upload the files. If an upload fails, the shape may need to be examined in a GIS where stray vertices can be deleted to remove any ‘knots’ in the shapefile.
The Shape Upload menu option is available in the left hand menu from both the Incident and Analysis perspectives. The shapes you upload will be associated with the incident you are developing content or analysis for.
Consider the resolution of the shapefile you are uploading. Shapes that were drafted for detailed ecological studies, for example, may require a very fine resolution. Often, these shapes can be simplified for use in WFDSS where broad strategic decisions are being made. Biologists may have walked with a GPS collecting a point every meter along a stream containing an endangered species, for example. Though this fine detail is valuable for scientific analysis, it may be too detailed for fire management decisions. If drafting water or introducing retardant into the waterway is precluded, it is preferable, for fire management decisions, to use a courser shape that provides a better buffer for the sensitive area. Very narrow polygons, though calculated correctly under the hood, cannot be displayed in WFDSS and will look much better on screen if coarsened. Lastly, for analyses, the minimum resolution of the grids in 30m. Vertices collected at a finer resolution than this are not ‘seen’ by the fire behavior models.
Note: Though WFDSS uses NAD83, it will import and convert shapefiles that were created in other common projections and datums. In addition, shapes are downloadable in a local Albers projection that is based on the location of the incident.
To upload shapes for an incident:
- From the Incident List, select the incident you want to upload a shape for.
- Click View Information. The Edit Incident Information page appears.
- From the left menu, choose Shape Upload. The Upload Shape Files page appears.
- In the Shape Label field, type a descriptive name for the shape you are uploading (character limit is 64).
- Select the Shape Type.
- Select the Shape Date and Time. This is the effective date for the shape, and is beneficial for tracking the history related to the types of shapes uploaded.
- Mark the Source Types for the shape.
- Enter a Comment describing the shape you are uploading.
- Click Browse to navigate to where the shape ZIP file is stored. The Choose File window appears.
- Select the shape ZIP file you want to upload and click Open. The path and filename for the ZIP file appear in the File to Upload field.
- Click Upload. The shapes will be uploaded and associated with the incident. Uploaded shapes are available for viewing in map displays.
-----------
Last updated on 8/30/2021 2:38:04 PM.
To upload shapes for an analysis:
- From the Analysis List, select the analysis you want to upload a shape for. (This function is available only for Basic and Short-Term Fire Behavior, and FSPro runs.)
- Click View Information. The Analyses page appears.
- From the left menu, choose Shape Upload. The Upload Shape Files page appears.
- In the Shape Label field, type a descriptive name for the shape you are uploading (character limit is 64).
- Select the Shape Type.
- Select the Shape Date and Time. This is the effective date for the shape, and is beneficial for tracking the history related to the types of shapes uploaded.
- Mark the Source Types.
- Enter a Comment describing the shape you are uploading.
- Click Browse to navigate to where the shape ZIP file is stored. The Choose File window appears.
- Select the shape ZIP file you want to upload and click Open. The path and filename for the ZIP file appear in the File to Upload field.
- Click Upload. The shapes will be uploaded and associated with the analysis.
- To view the shape:
- In the left pane of the tab, verify that the Incident and Analysis layers are turned on.
- If the Incident and Analysis layers are not checked, click the + sign for each to expand the layer options.
- Select the shape you just uploaded (the description you entered when uploading the shape appears in the list).
The shape should appear on your map view. If it doesn't, that means that either the latitude/longitude are wrong in the shape or incident, or you uploaded the wrong shape.
Try zooming out until you see the shape description, then use the hand (panning) tool to move the shape to the center of your screen before zooming in.
-----------
Last updated on 8/30/2021 2:38:04 PM.
To load perimeters for multiple fires into one fire record in WFDSS:
WFDSS is designed with the idea of a 1:1 relationship between decisions and wildfires. Similarly, WFDSS is built in a way that when a perimeter is uploaded for an incident, the perimeter data are dissolved and the data becomes associated with that incident. The integrity of individual fire data is critical to an analysts ability to make sense of a situation and for upwards reporting. When data for multiple incidents is combined under one fire record, this integrity is compromised.
Impacts of loading perimeters for multiple fires into one fire record in WFDSS include:
- The “Latest perimeter Size” field in WFDSS is calculated based on the perimeter uploaded to the incident with the latest effective date in WFDSS. This value is shared with IRWIN as “Calculated Acres”. It then is displayed in other systems, including EGP and Inform. If perimeters for multiple fires are loaded into one record in WFDSS, it will inflate the Calculated Acres value reported resulting in a distorted picture of the fire situation, which can lead to confusion for those viewing the data.
- The National Incident Feature Service (NIFS) and it’s derivative products display the Calculated Acres field as shown in IRWIN. If perimeters for other fires are included in the wrong incident, this can result in a large disconnect between the acres shown from IRWIN, from NIFS, and from other authoritative sources such as Sit/209.
- Users occasionally download a fire perimeter from WFDSS to use in the National Incident Feature Service or for final fire reporting. If perimeters are loaded for multiple fires into one fire record in WFDSS, someone may inadvertently download a “perimeter” made up of the perimeters of multiple fires and upload that into a final fire reporting system, distorting the record. It can be very difficult for a user, looking at data collected during a fire, to tell if a perimeter consisting of multiple parts was from one fire that had spots or was actually two for more fires. The system, expecting that a fire perimeter shape was intended for the fire in which it’s loaded, does not maintain GIS attributes that allow a user to separate them later.
At the end of the calendar year, WFDSS perimeters are pulled together into a Historic Fire Perimeters dataset. Because there is no automated way to check perimeters to see if perimeters for multiple fires were loaded into a single fire record, all of those multiple perimeters become part of the Historic Fire Perimeters dataset, labeled with the name of the incident into which they were loaded. This can cause confusion for users who are later trying to use the data for situational awareness or in masks and barriers for fire behavior modeling.
Here are a few suggestions to effectively deal with needing to see or use perimeters from fires within a WFDSS record when they are perimeters for a different record.
- WFDSS does not provide support for creating complexes, adding incidents to complexes, or removing them, but WFDSS does provide a way to view the incidents in a complex through the WFDSS Groups tab. When viewing a Group Map, you can see current and published planning areas, fire perimeters, Management Action Points, Incident Objective Shapes, and points of origin for all fires in the group on the same map.
- When using the incident Situation Map, turn on the WFDSS Fires Since 1/1/2021 layer under Disturbance History and zoom so that you can see all of the relevant fires.
- On the Incident Situation Map, you can put fire perimeters into the Incident Objective Shapes layer. This has an added optional benefit of being able to associate an incident objective with the perimeter of a fire.
- When modeling for a group of fires under one incident, you do not need all of the perimeters in the Fire Perimeter for the fire. You can upload fire perimeters to be used as barriers, masks, and ignitions in those layers. If using ignitions for the various fires, the analysts can model their runs from the group of incidents, and agency administrators or other people can see the potential impacts of the fires on common values at risk or other management considerations.
-----------
Last updated on 8/30/2021 2:38:04 PM.