Fire Occurrence and History Perimeter: Final Perimeters ...€¦ · Version 2.2 FINAL 01/25/2016...

Version 2.2 FINAL 01/25/2016

of 39

Fire Occurrence and History Perimeter: Final Perimeters

(FPER)

IMPLEMENTATION GUIDELINES

January 25, 2016

Version 2.2

United States Department of the Interior

Bureau of Land Management

National Operations Center

Division of Resource Services

Denver Federal Center

Denver, Colorado 80225

http://web.blm.gov/internal/wo-600/610/design_standards/images/blm_logo_transparent.png


of 39

Purpose of Implementation Guidelines

This document describes the physical design for the national data standard for the geospatial dataset. It is intended as a guideline for

implementation. States may extend and expand upon this guideline in order to meet their specific needs, provided that when the data is pushed

up to the national level, it will meet the minimum requirements as set forth in the Data Standard.

Table of Contents

INTRODUCTION .......................................................................................................................................................................................... 3

Data Guidelines .................................................................................................................................................................................... 3

Dataset Review Cycle ........................................................................................................................................................................... 4

National Dataset Update Cycle ............................................................................................................................................................ 4

Records Retention ................................................................................................................................................................................ 4

Data Structures Implemented ............................................................................................................................................................... 4

Domains Implemented .......................................................................................................................................................................... 5

Global ID & Editor Tracking Fields .................................................................................................................................................... 6

Physical Database Diagram ................................................................................................................................................................ 8

Topology ............................................................................................................................................................................................... 9

Design Considerations ....................................................................................................................................................................... 10

DATA STANDARD IMPLEMENTATION DETAILS ............................................................................................................................ 12

Common Attributes ............................................................................................................................................................................. 12

Wildland Fire Perimeter Polygons (fper_poly) ................................................................................................................................. 14

Wildland Fire Perimeter Unit ID Table (fper_unit_id_tbl) ............................................................................................................... 26

Wildland Fire Perimeter Arcs (fper_arc) ........................................................................................................................................... 30

APPENDIX A: DOMAIN VALUE DOCUMENTATION ....................................................................................................................... 33

APPENDIX B: ATTRIBUTE METADATA TERMINOLOGY ............................................................................................................. 34

APPENDIX C: EDITOR TRACKING FIELDS ....................................................................................................................................... 35

APPENDIX D: COMPARISON OF CURRENT FPER VERSION TO PROPOSED VERSION ...................................................... 36

REVISION HISTORY ................................................................................................................................................................................. 39


of 39

INTRODUCTION

Data Guidelines

Implementation of the data standards will occur at those organizational levels of the Bureau as appropriate. The standards are intended

to be platform-independent.

There are some attributes that are intended to eventually become system generated when a system or application is developed to manage

this dataset. At the present time there is no specific application for maintaining this data layer and therefore those attributes will

currently need to be manually edited.

The attributes included in this implementation are those that have been established for the national data standard and cannot be modified

except through the Data Standards Maintenance process. If additional attributes or domain values are desired by individual

states/offices, create a new attribute and populate with a new attribute domain assignment. Metadata for the additional attributes must be

documented by that office.

The format for entering the date in the geodatabase (gdb) will be MM/DD/YYYY. The ESRI software displays the date field according to

how dates are formatted for display on the computer. The Federal Geographic Data Committee (FGDC)-compliant format for the date

field is MM/DD/YYYY. There are two methods in which the FGDC format could be used for storing the date. The date format on the

computer can be reset which may introduce unintended consequences within other programs, or the date field could be defined as a text

field which would leave ample room for errors being introduced to the data. Although the National Data Standards are intended to be

platform-independent, the ESRI GDB format is the current platform implemented throughout the Bureau of Land Management (BLM).

The Administrative State, District and Field Office codes were part of a three tier identification system, which has been replaced by the

ten-character DOI Federal Personnel Payroll System (FPPS) Organization Code. For BLM national data standards, we will be using

only the last eight characters of the FPPS organization code (the two-character BLM Administrative State Code and the six-character

Administrative Office Code). While using these codes in combination can contribute to the creation of a unique identifier, they are also

listed as separate attributes so that if the codes change at a single level, the concatenated code can then be regenerated. However, if the 8

character code is used as part of a unique identifier, the unique identifier is not re-generated if the organization code changes.

To populate the field for the Administrative Unit Code attribute in the geodatabase (ADM_UNIT_CD), individual offices should

download the Access database containing the common domains from the National Data Standards SharePoint located at

http://teamspace/sites/blmnds/default.aspx. Click on the link for “Access Database-Domains” in the left column to download the Access

database. The field should be populated with the office code for the lowest level of the organization that has jurisdiction.


of 39

Dataset Review Cycle

The national data steward for the FPER dataset should review the dataset annually for updates. The annual data review should be in

January by the data steward. The data standard itself will also be reviewed annually by the data steward.

National Dataset Update Cycle

The national level data for FPER should be updated at least monthly on the NOC EGIS server. This update shall occur through

replication, with the updated information reflected on the BLM external data server within 30 days of replication. Replication may

increase in frequency during the fire season which is typically April through September. State and local offices shall determine an update

cycle that fits their specific needs for local data. Metadata is available on the BLM Internal Geospatial Gateway (within the “Data

Navigation” section): https://blmspace.blm.doi.net/oc/intra/drs/Pages/GeoSpatialGateway.aspx. States and local offices shall keep all

geospatial metadata current by posting any updated metadata to this website on a regular basis.

Records Retention

Surrounding each fire season, the FPER dataset is active throughout each year. This dataset is continually maintained and updated. The

FPER geodatabase will be archived by February 15 annually after the data steward completes the annual data review. Note: Records

issues will be handled according to official policy for Records Management.

Data Structures Implemented

The data for inclusion in this dataset shall be collected in a known datum and coordinate system. The data stored on the National

Operations Center (NOC) EGIS server in Denver shall be stored in geographic coordinates for national layers using the Bureau

standard NAD 83 datum rather than in a specific projection. While the standard datum is NAD 83, there are multiple realizations of that

datum. The metadata for each dataset shall contain more specific labeling of the datum as appropriate. Examples of this include: NAD 83

(2007) or NAD 83 (CORS 96) (1997). Every effort should be made to be as specific as possible in delineating the appropriate datum.

Data Structures Implemented

There are 3 structures in this implementation:

fper_poly The polygon features that show the boundaries for the Wildland Fire Perimeter areas.

fper_arc The arc features that will define the polygons for the Wildland Fire Perimeter areas. These arcs will have the

feature level metadata attributes assigned to them.

fper_unit_id_tbl The non-spatial lookup table that displays the NWCG Unit Name that corresponds to the NWCG Unit_Id.

https://blmspace.blm.doi.net/oc/intra/drs/Pages/GeoSpatialGateway.aspx


of 39

Domains Implemented

There are domain tables that are common across multiple data standards and feature classes, and as such are implemented differently than

domains that are specific to this data standard (reference “Global Domains” document located on the National Data Standards SharePoint

(“Standards Support Information” tab > Document Type: Reference > Subject: Domains). Shared domains are not included in the

geodatabase associated with these implementation guidelines.

Global domain names that are common across multiple data standards and feature classes are listed below in italics. These global domain

values are located in the Access Database located on the Network Operations Center (NOC) Data Management National Data Standards

SharePoint site. Please refer to the “Domains Management” document for instructions on adding these global domains to the geodatabase

and linking them to the feature classes.

The following global domain is found in both FPER feature classes:

DOM_ADMIN_ST

The following global domains are found only in the FPER polygon feature class:

DOM_ADM_UNIT_CD

DOM_YES_NO_ONLY

The following global domains are found only in the FPER arc feature class:

DOM_COORD_SOURCE_TYPE

DOM_DEF_FEATURE_TYPE

The following domains are unique to the FPER dataset. Therefore, they are associated in the geodatabase and are included in the XML

schema. The FPER specific domain names are listed below, in normal text.

FPER_DOM_CLCTN_MTHD

FPER_DOM_FIRE_CAUSE

http://teamspace/sites/blmnds/Standards%20Support%20Information/global_domains_v3_0.docx

http://teamspace/sites/blmnds/domains/default.aspx

http://teamspace/sites/blmnds/Standards%20Support%20Information/domains_management_V3.docx


of 39

Global ID & Editor Tracking Fields

The following fields are attributes automatically generated across all feature classes in this data standard. Global ID’s will automatically

be populated upon geodatabase implementation from the XML file delivered from the National Operations Center (NOC). Editor tracking

must be turned on at the feature dataset level after the XML file is imported into the geodatabase. The user name used to populate the

created_user and last edited_user attributes will come directly from the credentials used to edit the local geodatabase. The dates used to

populate the created_date and updated_date attributes will come from the UTC (Coordinated Universal Time) at the time in which the

edits were made.

GIS Name Logical Name Physical Definition & Design Consideration

GlobalID Not Applicable Physical Definition: A 32-character alpha-numeric code that serves as the universal and

unique identifier for each feature within the feature class of a geodatabase.

Design Consideration: Software generated value. A field of type UUID (Universal

Unique Identifier) in which values are automatically assigned by the geodatabase when a

row is created. This field is not editable and is automatically populated when it is added

for existing data.

Note: This attribute is included for purposes of replication only. It is not used as a unique

identifier for relationships between feature classes/tables.

created_user Not Applicable Physical Definition: The name of the user who created the feature within the feature class

of a geodatabase.

Design Consideration: Software generated value. This field is not editable and is

automatically populated with the user name used to access and edit the geodatabase.

Note: This attribute is included for purposes of replication and tracking purposes only.

created_date Not Applicable Physical Definition: The date (UTC) in which the feature within the feature class of a

geodatabase was created.


automatically populated with the date in which the feature is created.



of 39


last_edited_user Not Applicable Physical Definition: The name of the user who most recently updated the feature within

the feature class of a geodatabase.


automatically populated with the user name used to access and edit the geodatabase.


last_edited_date Not Applicable Physical Definition: The date (UTC) in which the feature within the feature class of a

geodatabase was most recently edited.


automatically populated with the date in which the feature is updated.



of 39

Physical Database Diagram

The diagram below depicts the geodatabase as it will be configured after global domains are added and editor tracking enabled as detailed

in this implementation guide. The geodatabase provided as an XML file contains the basic structure for the final geodatabase but global

domains, topology and editor tracking must all be added as detailed in this document.

FPER

Simple feature classfper_arc Contains Z values

Contains M valuesGeometry Polyline

NoNo

Data typeField namePrec-ision Scale LengthDomain

Default value

Allow nulls

OBJECTID Object ID

SHAPE Geometry Yes

COORD_SRC_TYPE String No UNK DOM_COORD_SRC_TYPE 5

COORD_SRC2 String Yes 25

DEF_FET_TYPE String No UNK DOM_DEF_FEATURE_TYPE 15

DEF_FET2 String Yes 30

ACCURACY_FT Long integer No -1 0

ADMIN_ST String No DOM_ADMIN_ST 2

GlobalID No 0 0 38

CREATE_DATE Date No 09/09/9999 0 0 8

CREATE_BY String No UNK 30

MODIFY_DATE Date No 09/09/9999 0 0 8

MODIFY_BY String No UNK 30

SHAPE_Length Double Yes 0 0

created_user String Yes 255

created_date Date Yes 0 0 8

last_edited_user String Yes 255

last_edited_date Date Yes 0 0 8

Tablefper_unit_id_tbl

Data typeField namePrec-ision Scale LengthDomainDefault value

Allow nulls

OBJECTID Object ID

NWCG_UNIT_ID String No 9

NWCG_UNIT_NM String No 30

String Yes 3

STATE_PROVINCE String No 2





COUNTRY_CD

Simple feature classfper_poly Contains Z values

Contains M valuesGeometry Polygon

NoNo

Data typeField namePrec-ision Scale LengthDomainDefault value

Allow nulls

OBJECTID Object ID

SHAPE Geometry Yes

POO_JRSDCTNL_UNIT_ID String No 9

RPT_UNIT_ID String No 9

LOCAL_INCDNT_ID Long integer No 0

FIRE_CODE_ID String Yes 4

INCDNT_NM String No 50

FIRE_DSCVR_CY Short integer No 0

FIRE_DSCVR_DT Date No 09/09/9999 0 0 8

FIRE_DSCVR_DT_EST_FLAG String No NO DOM_YES_NO_ONLY 3

FIRE_CNTRL_DT Date No 09/09/9999 0 0 8

FIRE_CNTRL_DT_EST_FLAG String No NO DOM_YES_NO_ONLY 3

FIRE_CAUSE_NM String No Unknown FPER_DOM_FIRE_CAUSE 15

CLCTN_MTHD_NM String No Unknown FPER_DOM_CLCTN_MTHD 25

TOTAL_RPT_ACRES_NR Double No 0

CMPLX_NM String Yes 50

IRWIN_ID String Yes 50

COMMENT String Yes 255

ADM_UNIT_CD String No DOM_ADM_UNIT_CD 8

ADMIN_ST String No DOM_ADMIN_ST 2

GlobalID No 0 0 38





SHAPE_Length Double Yes 0 0

SHAPE_Area Double Yes 0 0

created_user String Yes 255

created_date Date Yes 0 0 8

last_edited_user String Yes 255

last_edited_date Date Yes 0 0 8

POO_PRTCT_UNIT_ID String Yes 9

GIS_ACRES

0 0

Double No 0 0 0


of 39

Topology

Geodatabase (gdb) and map topologies will be established to relate the active feature classes together, to maintain feature geometry, and

to aid in the editing of features. The implementation of this data standard requires that polygons be defined by bounding arcs. Therefore,

a minimum set of geodatabase topology rules are defined as part of the geodatabase to verify the coincidence between these two feature

classes.

Map topology shall be established during edit sessions. Edits to the polygon shape will be performed by modifying the bounding arc.

(Historical or archived polygons will not be edited once they become inactive). For additional information, refer to the Map Topology

and Geodatabase Topology documents located on the National Data Standards SharePoint (Standards Support Information tab

>Document Type: Instruction > Subject: Geospatial). It is recommended that these tools be used and implemented to improve data

quality and integrity.

Geodatabase Topology Rules

The following are the minimum that should be implemented for the FPER data standard. Additional topology rules may be added

depending on data requirements for each office. xxxx_arc, xxxx_poly, etc. represent the names of the feature classes that participate in

the rule.

Topology Rule Required?

fper_poly Boundary Must Be Covered By fper_arc Mandatory

fper_arc Must Be Covered By Boundary Of fper_poly Mandatory

fper_arc Must Not Self-Overlap Mandatory

fper_arc Must Not Have Dangles Optional

NOTE: Business requirements for wildland fire perimeters require that fire perimeter polygons and the associated metadata arc must be

allowed to overlap. For this reason, the “Must Not Overlap” topology rule is not implemented in this dataset.

http://teamspace/sites/blmnds/Standards%20Support%20Information/MapTopologyV2.docx

http://teamspace/sites/blmnds/Standards%20Support%20Information/work_with_GDB_Topology.docx


of 39

Design Considerations

National Unique Fire Identifiers for FPER

The national FPER unique fire identifier uniquely identifies a fire incident. The national unique fire identifier attribute is created by

concatenating three attributes collected at the state level.

The format for the national unique fire identifier is: YYYY-CCSSUUUU-XXXXXX.

YYYY = Fire Discovered Calendar Year

CCSSUUUU = Reported Unit Identifier

XXXXXX = Fire Incident Number

The CCSSUUUU portion of the National Unique Fire Identifier is the NWCG Unit Identifier of the governmental entity reported to the

authoritative fire reporting system. NWCG Unit IDs result from the concatenation of the Country Abbreviation, State Abbreviation and

Unit Code. Country code (CC) is a 2 character value. State code (SS) is a 2 character value. NWCG Unit Code (UUUU) is a 3-4

alphanumeric value.

Ex: USAKADD = United States + Alaska + Anchorage Field Office

The implementation detailed in this document for the Fire Perimeter (FPER) data standard is for state level implementation, except for the

implementation of National Unique Identifiers (as detailed above). Concatenation to create the National Unique Fire Identifiers will

only be implemented at the national level; they are not to be included within FPER geodatabases at the state level. The local and

state levels are responsible for entering the three fields (Fire Discovered Calendar Year, Reported Unit Identifier and Fire Incident

Number) which will be concatenated during replication to the national compilation.


of 39

Donut Holes

Donut holes for unburned islands 10 acres or less should not be created. Creating donut holes for unburned islands over 10 acres is not

required and are optional to collect. However, it may be advisable to consider including islands larger than 10 acres when fires occur in

sage-grouse habitat or other environments where unburned islands would be important to habitat quality. If choosing to create unburned

islands over 10 acres, these islands should be subtracted from the wildland fire perimeter total burned acres. See instructions below.

Creating a donut hole:

1. Open the Snapping Environment dialog box and turn on snapping for edit sketch vertices. The check box is at the bottom of the

dialog box. With edit sketch snapping, you can better construct a closed boundary defining the area you want to remove.

2. Set the task to Cut Polygon Features.

3. Click the Sketch tool .

4. Sketch the area you want to remove. Make sure the end vertex snaps to the first one, so you end up with a closed polygon.

5. Finish the sketch.

6. You now have two polygons. Select only the inner polygon and press the Delete key.

Wildland Fire Polygon Generation

The wildland fire polygons will be replicated back to the NOC. The wildland fire polygon can be generated in multiple ways. The

wildland fire polygon can be generated from the boundaries taken from the field when the wildland fire perimeter is collected. The

wildland fire polygon may also be generated by copying the last daily wildland fire perimeter if it is accurate for use.

WFMI Data

If a fire is reported in WFMI the data contained in this dataset must match what is reported in WFMI.WFMI is the System of Record for

non-spatial data about a wildland fire. FPER is the BLM System of Record for the geospatial perimeter information regarding the

wildland fire. Total Acres Reported should contain the same value as recorded in the authoritative fire reporting system. At the time of

writing this report, the authoritative fire reporting system is WFMI where the corresponding attribute is Control Acres.

http://webhelp.esri.com/arcgiSDEsktop/9.3/index.cfm?TopicName=Using_the_snapping_environment


of 39

DATA STANDARD IMPLEMENTATION DETAILS

Common Attributes

The following are attributes (data elements) that are common across all feature classes in this data standard.


ADMIN_ST State

Alphabetic

Code

Physical Definition: An administrative unit that identifies the state or geographic area

which has administrative jurisdiction over lands, and cases. The land for a case may not

be physically located in the associated administrative state. Only those states that are

BLM administrative states are in the domain for this entity. Example: Montana is the

administrative state for public lands in the geographic states of Montana, South and North

Dakota.

Design Consideration: Two letter, upper case abbreviation for the administrative state

office. The current list of values is: AK, AZ, CA, CO, ES, ID, MT, NM, NV, OR, UT,

and WY. In the FPPS Organization Codes, use the second two characters (after the LL,

e.g. LLAK030900).

Attribute Domain Assignment: DOM_ADMIN_ST

CREATE_DATE Location

Effective Date

Physical Definition: The month, day, and calendar year on which the position of the

Location was created.

Design Consideration: As a new feature is added to the system its creation date will be

collected and maintained. The date will be in the format of MM/DD/YYYY.

Default: 09/09/9999

CREATE_BY Not applicable Physical Definition: The User ID (BLM login ID) of the person who created or imported

the data into the BLM GIS system.

Design Consideration: This attribute will be deleted before providing the data to the

public.

Default: UNK


of 39


MODIFY_DATE Location

Modified Date

Physical Definition: The month, day, and calendar year on which the position of the

Location was modified.

Design Consideration: As a feature is edited or modified while in the system its

modification date will be collected and maintained. The date will be in the format of

MM/DD/YYYY.

Default: 09/09/9999

MODIFY_BY Not applicable Physical Definition: The User ID (BLM login ID) of the person who edited or modified

data in the BLM GIS system will be collected and maintained.

Design Consideration: This attribute will be deleted before providing the data to the

public.

Default: UNK


of 39

Wildland Fire Perimeter Polygons (fper_poly)

The features for Wildland Fire Perimeter Polygons are defined below. Domain values are used when appropriate.

Wildland Fire Perimeter Polygon Attributes

GIS NAME ALIAS DATA

FORMAT

ALLOW

NULLS

DEFAULT

VALUE DOMAIN NAME DERIVED

POO_JRSDCTNL_UNIT_ID Point of Origin Jurisdictional

Unit Identifier Char(9) NO NO

POO_PRTCT_UNIT_ID Point of Origin Protecting Unit

Identifier Char(9) YES NO

RPT_UNIT_ID Reported Unit Identifier Char(9) NO NO

LOCAL_INCDNT_ID Fire Incident Number Long Integer NO NO

FIRE_CODE_ID Fire Code Char(4) YES NO

INCDNT_NM Incident Name Char(50) NO NO

FIRE_DSCVR_CY Fire Discovered Calendar Year Short Integer NO YES

FIRE_DSCVR_DT Fire Discovered Date Date NO 09/09/9999 NO

FIRE_DSCVR_DT_EST_FLA

G

Fire Discovered Date Estimate

Flag Char(3) NO NO DOM_YES_NO_ONLY NO

FIRE_CNTRL_DT Fire Control Date Date NO 09/09/9999 NO

FIRE_CNTRL_DT_EST_FLA

G Fire Control Date Estimate Flag Char(3) NO NO DOM_YES_NO_ONLY NO

FIRE_CAUSE_NM Incident General Cause Name Char(15) NO Unknown FPER_DOM_FIRE_CAUSE NO

CLCTN_MTHD_NM Collection Method Char(25) NO Unknown FPER_DOM_CLCTN_MTHD NO

TOTAL_RPT_ACRES_NR Total Reported Acres Double NO 0.0 NO

GIS_ACRES GIS Acres Double NO 0.0 YES

CMPLX_NM Complex Name Char(50) YES NO

IRWIN_ID Irwin Identifier Char(50) YES NO

COMMENT Wildland Fire Perimeter

Comments Char(255) YES NO


of 39

Wildland Fire Perimeter Polygon Attributes

GIS NAME ALIAS DATA

FORMAT

ALLOW

NULLS

DEFAULT


ADM_UNIT_CD Administrative Unit Code Char(8) NO DOM_ADM_UNIT_CD NO

ADMIN_ST Administrative State Code Char(2) NO DOM_ADMIN_ST NO

GlobalID GlobalID UUID NO NO

CREATE_DATE Created Date Date NO 09/09/9999 NO

CREATE_BY Created By Name Char(30) NO UNK NO

MODIFY_DATE Modified Date Date NO 09/09/9999 NO

MODIFY_BY Modified By Name Char(30) NO UNK NO

Common Attributes are documented in Bold. Physical definitions and design considerations for common attributes can be found

above in the Common Attributes section.


of 39

GIS Name Logical Name Physical Definition and Design Considerations

POO_JRSDCTNL_UNIT_ID Point of Origin

Jurisdictional

Unit Identifier

Physical Definition: The active NWCG Unit Identifier of the governmental entity having

overall land and resource management for the specific geographical area as provided by law

for the piece of land where the fire started.

Design Considerations: Per NWCG data standards, NWCG Unit ID is comprised of the

Country Abbreviation, State Abbreviation and Unit Code.


Country code is a 2 character value. State code is a 2 character value. NWCG Unit Code is a 3-

4 alphanumeric value.

To populate this field, first join the NWCG Unit ID table to this feature class. Once joined,

proceed with the following steps in ArcMap:

1. Start an edit session (using the Editor toolbar).

2. Open the attribute table for this feature class.

3. Right-click on the header for this field. Select “Field Calculator”.

4. In the Field Calculator dialog box, within the “Fields” list, double-click the UnitID

field (the name will be similar to “Active.csv.UnitID”).

5. Select “OK” to populate this field with the appropriate unit identifier.


of 39


POO_PRTCT_UNIT_ID Point of Origin

Protecting Unit

Identifier

Physical Definition: The active NWCG Unit Identifier of the entity responsible for providing

direct incident management and services to the given area pursuant to its jurisdictional

responsibility or as specified by law, contract, or agreement.

Design Considerations: Per NWCG data standards, NWCG Unit ID is comprised of the

Country Abbreviation, State Abbreviation and Unit Code.


Country code is a 2 character value. State code is a 2 character value. NWCG Unit Code is a 3-

4 alphanumeric value.

To populate this field, first perform the steps described for how to join the NWCG Unit ID

table to this feature class (see Section C). Once this join has been performed, proceed with the

following steps in ArcMap:

1. Start an edit session (using the Editor Toolbar).

2. Open the attribute table for this feature class.

3. Right-click on the header for this field. Select “Field Calculator”.

4. In the Field Calculator dialog box, within the “Fields” list, double-click the UnitID

field (the name will be similar to “Active.csv.UnitID”). This step is commanding

ArcMap to equate this field with the UnitID field.

5. Select “OK” to populate this field with the appropriate unit identifier.

RPT_UNIT_ID Reported Unit

ID Physical Definition: The active NWCG Unit Identifier of the governmental entity reported to the

authoritative fire reporting system.

Design Considerations: The “CCSSUUUU” portion of the Unique Fire Identifier. Currently

the authoritative fire reporting system is WFMI but that may change in the future which is why

the column name is fairly generic.


of 39


LOCAL_INCDNT_ID Fire Incident

Number

Physical Definition: A number assigned by the Protecting Unit or the Dispatch Center that

has dispatch responsibilities over the point of origin for the fire. It is derived from a CAD

system for BLM and is used in multiple systems for tracking in programs such as FireCode,

ROSS, WFDSS, IQCS, and SIT209.

Design Considerations: The “XXXXXX” portion of the Unique Fire Identifier attribute. Used

by FireCode to generate a numeric Fire Code, which is then stored in the FIRE_CODE_ID

attribute field.

FIRE_CODE_ID Fire Code Physical Definition: Cost accounting tracking number.

Design Considerations: Assigned by the FireCode application. For BLM, pre-FY2004 (prior

to FireCode system), it is a four character alphanumeric code used for financial purposes. The

typical code format was one letter followed by three numbers; blocks of these codes were

assigned to BLM units.

Business Rule #13: To facilitate data migration, the Fire Code for a wildland fire is required if

it was discovered on or after January 1, 2004. The Fire Code is optional (i.e. null values are

allowed) for wildland fire perimeters discovered before January 1, 2004.


of 39


INCDNT_NM Incident Name Physical Definition: The name that is given to an incident for the purposes of providing a

common way to identify the fire incident.

Design Considerations: The incident name is assigned by the responsible land management

unit and may use geographic reference in the name. The name should be descriptive, brief, and

in good taste. Fires will be named with reference to their geographic location or nearby

landscape features. Avoid using the same name for more than one incident within any given

calendar year. The name is limited to 50 alpha-numeric characters and will allow for #, &,

apostrophe, space, period and hyphen. The Fire Name should exactly match the name used

reported to the Non-spatial System of Record, currently WFMI, for inclusion on the Individual

Fire Report.

If multiple incidents within a year are in the same geographic location, thus are being named

similarly, numbers are used to differentiate the incidents. Arabic numbers (NOT Roman

numerals) must be used, and the number 1 is not used, as the absence of a number indicates it

is the first, original incident to receive the name (for example: Red House, Red House 2, Red

House 3, etc., NOT Red House, Red House II, Red House III, etc.).

FIRE_DSCVR_CY Fire

Discovered

Calendar Year

Physical Definition: The calendar year when the fire was discovered.

Design Consideration: Date must be a four-digit year (YYYY).

This value is to be duplicated from the Fire Discovered Date field using the Field Calculator in

ArcMap using the following steps:

1. On the Editor toolbar, select “Start Editing”

2. Select this feature class as the target in the dialog box that appears in order to start an

edit session.

3. Open attribute table for this feature class.

4. Right click on the FIRE_YEAR_CY field, choose “Field Calculator”.

5. In the dialog box, select the radial button for VBScript in the Parser section at the top-

left.

6. In the expression box at the bottom, type the following text:

Right([FIRE_DSCVR_DT], 4)

7. Select “OK”. The year portion of the Fire Discovered Date should appear.


of 39


FIRE_DSCVR_DT Fire

Discovered

Date

Physical Definition: The calendar year, month and day when the fire was discovered.

Design Considerations:

Business Rule #10: If the year the fire was discovered is known, but not the month and date,

use Dec 31, <actual year> (12-31-YYYY). If the month and year the fire was discovered is

known, use <actual month> 31, <actual year> (MM-31-YYYY). If only the decade the year

was discovered is known, use Dec 31, <first year of the decade> (12-31-YYYY).

Examples:

Fire discovered in 1972: 12-31-1972 (for “Dec 31, 1972”)

Fire discovered sometime in July 2014: 07-31-2014 (for “July 31, 2014”)

Fire discovered sometime in the 1950’s: 12-31-1950 (for “Dec 31, 1950”)

Default Value: 09/09/9999

FIRE_DSCVR_DT_EST_FLAG Fire

Discovered

Date Estimated

Flag

Physical Definition: A flag to indicate that the exact Fire Discovered Date is not known.


Yes – The exact date on which the fire was discovered is not known and the date placed in the

Fire Discovery Date attribute is only an estimate.

No – The date in the Fire Discovery Date is the actual date the fire was discovered and is not

estimated.

Attribute Domain Assignment: DOM_YES_NO_ONLY

Default Value: No


of 39


FIRE_CNTRL_DT Fire Control

Date

Physical Definition: The date that a wildfire was declared under control.

Design Considerations: The fire control date may not always correspond to the date the

perimeter shown was captured.

Business Rule #10: If the year the fire was controlled is known, but not the month and date,

use Dec 31, <actual year> (12-31-YYYY). If the month and year the fire was controlled is

known, use <actual month> 31, <actual year> (MM-31-YYYY). If only the decade the year

was controlled is known, use Dec 31, <first year of the decade> (12-31-YYYY).

Examples:

Fire controlled in 1972: 12-31-1972 (for “Dec 31, 1972”)

Fire controlled sometime in July 2014: 07-31-2014 (for “July 31, 2014”)

Fire controlled sometime in the 1950’s: 12-31-1950 (for “Dec 31, 1950”)

Default Value: 09/09/9999

FIRE_CNTRL_DT_EST_FLAG Fire Control

Date Estimated

Flag

Physical Definition: A flag to indicate that the exact Fire Control Date is not known.


Yes – The exact date on which the fire was controlled is not known and the date placed in the

Fire Control Date attribute is only an estimate.

No – The date in Fire Control Date is the actual date the fire was controlled and is not

estimated.

Attribute Domain Assignment: DOM_YES_NO_ONLY

Default Value: No


of 39


FIRE_CAUSE_NM Fire Cause Physical Definition: Broad classification of the reason the fire occurred.

Design Considerations: N/A

Attribute Domain Assignment: FPER_DOM_FIRE_CAUSE

For specific domain values, see the Domains document referenced in Appendix A.

Default Value: Unknown

CLCTN_MTHD_NM Collection

Method

Physical Definition: Method by which data is collected in the field.

Design Considerations: N/A

Attribute Domain Assignment: FPER_DOM_CLCTN_MTHD

For specific domain values, see the Domains document referenced in Appendix A.

Default Value: Unknown

TOTAL_RPT_ACRES_NR Final Fire

Perimeter

Burned Total

Acres Quantity

Physical Definition: The total number of acres burned as reported to the authoritative fire

reporting system.

Design Consideration: The number of acres reported in the Total Reported Acres attribute

should be the same as the value reported to the authoritative fire reporting system. Any

unburned islands of 10 acres or more will not be included in the total acres burned. Mapping

of unburned islands is optional.


of 39


GIS_ACRES Polygon Form

Area Measure

Physical Definition: The total number of acres within the wildland fire perimeter, as

calculated from the GIS perimeter.

Design Considerations: This represents the GIS calculated acres of the digitized/digital

perimeter of the fire (this may not be equal to the reported acres). It is a calculated value of

area, in units of acres, based on the area field created by default within the ESRI Polygon data

structure. This figure is not adjusted for unburned areas within the fire perimeter.

For the purposes of a ‘national data layer’, the data are to be stored in geographic coordinates

which do not correspond to ground values. This requires that there be a standard method for

calculating this attribute. Calculating acres will only work if you have your data frame

projected. The following is a suggested workflow to use.

To calculate GIS_ACRES follow these steps:

1. If an edit session is currently active, stop editing.

2. Right click on data frame properties

3. Click the Coordinate system tab

4. Click the “+” next to the Projected Coordinate Systems folder

5. Click ContinentalNorth America USA_Contiguous_Albers_Equal_Area_Conic

6. Start new edit session. Hit “Continue” in the Start Editing dialog box.

7. Open attribute table of FPER_POLY

8. On the heading of GIS_ACRES field, right click and choose Calculate Geometry

9. Leave the radio button for “Use coordinate system of the data frame” selected. The

projected coordinate system of the data frame should already be populated.

10. Be sure to set your units to ‘Acres US [ac]’

11. After calculations are complete, save your edits and end the edit session.

12. Reset the projection from the data frame back to “GCS_North_American_1983”, to

align with this same geographic coordinate system that is set on FPER_POLY.

13. If a workflow is already in place defining a method of calculating GIS_ACRES

continue to use the method that works best.

Total should include one decimal place.


of 39


CMPLX_NM Complex

Name

Physical Definition: The name assigned to the fire complex, which is two or more individual

incidents located in the same general area that are assigned to a single incident commander or

unified command. Each fire within the complex has its own record.

Design Considerations: It is assigned by the responsible land management unit and may use

geographic reference in the name.

IRWIN_ID Irwin Identifier Physical Definition: The unique identifier that IRWIN assigns to the fire occurrence. Primary

key for linking to the Wildland Fire Locations Point dataset.

Design Consideration: This GUID originates from the wildland fire locations point data layer.

It is populated from this source. It should not replace the GeometryID core attribute.

COMMENT Fire Perimeter

Comments

Physical Definition: Additional comments or information about how wildland fire perimeter

data was collected and characteristics of the fire itself.

Design Considerations: N/A.

ADM_UNIT_CD State

Alphabetic

Code + BLM

Organization

Code

Physical Definition: The BLM administrative unit/office that is a combination of

Administrative State Code and Administrative Office Code that fully identifies the geographic

area which has jurisdiction over the lands.

Design Consideration: This is an eight-character code. In the FPPS Organization Codes, use

the last eight characters (e.g. LLAK030900).

Attribute Domain Assignment: DOM_ADM_UNIT_CD


of 39

The Unique Fire Identifier (UNQE_FIRE_ID) attribute will only be implemented at the national level and will not show in the state level

implementation.


UNQE_FIRE_ID Unique Fire

Identifier

Physical Definition: Concatenation of the Fire Discovered Year, the Reported Unit

Identifier, and the Fire Incident Number.


The format for the national unique fire identifier is: YYYY-CCSSUUUU-XXXXXX.

YYYY = Fire Discovered Calendar Year

CCSSUUUU = Reported Unit Identifier

XXXXXX = Fire Incident Number

The CCSSUUUU portion of the National Unique Fire Identifier is the NWCG Unit

Identifier of the governmental entity reported to the authoritative fire reporting system.

NWCG Unit IDs result from the concatenation of the Country Abbreviation, State

Abbreviation and Unit Code. Country code (CC) is a 2 character value. State code (SS)

is a 2 character value. NWCG Unit Code (UUUU) is a 3-4 alphanumeric value.


The XXXXXX portion of the National Unique Fire Identifier is the local fire incident

number as assigned by the organization with jurisdictional authority at the point of

origin of the fire.

The Unique Fire Identifier will be implemented only in the National Compilation

Database; it will not be collected at the state level. The three attributes which form the

Unique Fire Identifier will be collected at the state level and replicated to the National

Compilation Database. They will then be concatenated together to form the Unique

Fire Identifier.


of 39

Wildland Fire Perimeter Unit ID Table (fper_unit_id_tbl)

This table represents the non-spatial lookup table that displays the NWCG Unit Name that corresponds with each NWCG Unit ID. Each

geodatabase will contain a table of records for the NWCG Unit ID and Names pre-populated. There is no relationship class associated

with this table. This table is for reference purposes only and will not be replicated to the NOC.

Wildland Fire Perimeter Unit ID Table

GIS NAME ALIAS DATA FORMAT ALLOW NULLS DEFAULT VALUE

NWCG_UNIT _ID NWCG Unit Identifier Char(9) NO

NWCG_UNIT_NM NWCG Unit Name Char(30) NO

COUNTRY_CD Country Code Char(3) NO

STATE_PROVINCE State or Province Char(2) NO

CREATE_DATE Created Date Date NO 09/09/9999

CREATE_BY Created By Name Char(30) NO UNK

MODIFY_DATE Modified Date Date NO 09/09/9999

MODIFY_BY Modified By Name Char(30) NO UNK

Common Attributes are documented in Bold. Physical definitions and design considerations for common

attributes can be found above in the Common Attributes section.


of 39


NWCG_UNIT_ID N/A Physical Definition: NWCG Unit Identifiers are an interagency standard used by many

manual and automated systems throughout the interagency wildland fire community for

designating organizational units within the federal and state government that are

involved in wildland fire management.

Design Considerations: A limit of nine characters has been set to allow for the

maximum number of characters that exist among the values in the “UnitID” column of

the Active NWCG Unit ID report that are to be imported into this attribute field.

Per NWCG data standards, NWCG Unit ID is comprised of the Country Abbreviation,

State Abbreviation and Unit Code.


Country code is a 2 character value. State code is a 2-3 character value. NWCG Unit

Code is a 3-4 alphanumeric value.

The NWCG Unit Identifier is used to populate the Point of Origin Jurisdictional Unit

Identifier, the Point of Origin Protecting Unit Identifier and Reported Unit Identifier in

the Wildland Fire Perimeter Polygons feature class. Instructions for performing the initial

steps for this process are included in this section (on Pages 26-27). Final steps are given

within the Design Consideration statements for the Point of Origin Jurisdictional Unit

Identifier and the Point of Origin Protecting Unit Identifier attributes.

NWCG_UNIT_NM N/A Physical Definition: The name of the National Wildfire Coordinating Group (NWCG)

unit that corresponds to the NWCG Unit Identifier.

Design Considerations: A limit of 30 characters has been set to allow for the maximum

number of characters that exist among the values in the “Name” column of the Active

NWCG Unit ID report that are to be imported into this attribute field.

COUNTRY_CD N/A Physical Definition: The code for the country associated to the NWCG Unit Identifier.

Design Considerations: A limit of three characters has been set to allow for the

maximum number of characters that exist among the values in the “Country” column of

the Active NWCG Unit ID report that are to be imported into this attribute field.


of 39


STATE_PROVINCE N/A Physical Definition: The code for the state or Canadian province associated with the

NWCG Unit Identifier.

Design Considerations: A limit of two characters has been set to allow for the

maximum number of characters that exist among the values in the “State” column of the

Active NWCG Unit ID report that are to be imported into this attribute field.

How To Populate FPER_UNIT_ID_TBL

The Wildland Fire Perimeter Unit ID table should be populated from a fresh export of the Active NWCG Unit ID report located on the

NWCG Unit Identifier Reports webpage. Click on the Published Reports link on the left side of the screen. Click on the Active.csv link

and save the .CSV file generated. The UnitId column will be used to populate the NWCG_UNIT_ID attribute. The Name column will be

used to populate the NAME attribute. The Country column will be used to populate the COUNTRY_CODE attribute. The State column

will be used to populate the STATE_PROVINCE attribute. Populate the CREATE_DATE and MODIFY_DATE columns with the date

the values were retrieved from NIFC. Populate the CREATE_BY and MODIFY_BY columns with the identifier of the person updating

the Wildland Fire Perimeter Unit ID table from the Active NWCG Unit ID CSV file.

Currently there are over 5000 active NWCG Unit IDs. It is expected that not all of these values will be relevant to every office. It is

possible to delete lines from the CSV file generated above to remove entries which are not relevant. Import only those rows in the CSV

file that are relevant to the business needs.

If the list of domain values is small enough, it is possible to convert the Wildland Fire Perimeter Unit ID Table into a domain. Please refer

to “Section J: Create Geodatabase Domain from CSV File” of the Domains Management for Geodatabases document for instructions on

converting a CSV file into a geodatabase domain. In Step 4, select the NWCG_UNIT_ID field for the Code Field and the NAME field for

the Description Field. In Step 5, assign “DOM_FPER_UNIT_ID” as the domain name and “This domain contains Wildland Fire

Perimeter Unit Identifiers and their descriptions.” as the domain description.

https://wfmi.nifc.gov/unit_id/Publish.html

http://teamspace/sites/blmnds/Standards%20Support%20Information/Domains_Management_V3.docx


of 39

How to Populate POO_JRSDCTNL_UNIT_ID and POO_PRTCT_UNIT_ID Fields In FPER_POLY via FPER_UNIT_ID_TBL

To help populate the POO_JRSDCTNL_UNIT_ID and POO_PRTCT_UNIT_ID fields in the Wildland Fire Perimeter Polygons feature

class, the Wildland Fire Perimeter Unit ID Table can be joined to this feature class in ArcMap using the following steps.

NOTE: The geodatabase must be populated with records containing “Administrative State Code” for the following steps to work.

1. Open up the CSV file with the relative NWCG Unit IDs, and perform a “Save As” using the “Excel Workbook” format.

2. Open up a new map document in ArcMap.

3. Open ArcCatalog. Add the “fper_poly” feature class to the Table of Contents in ArcMap.

4. From ArcCatalog, also add the “Excel Workbook” created in Step #1 to the Table of Contents in ArcMap.

5. Right-click on “fper_poly” in the Table of Contents. Highlight “Joins and Relates”. Select “Join” on the pull-out menu.

6. In the “Join Data” dialog box that appears, the Excel Workbook file should already populated for Item #2.

7. For Item #1 in this dialog box, select “Administrative State Code” as the field in “fper_poly” that the join will be based on.

8. For Item #3 in this dialog box, choose “State” as the field in the Excel Workbook file to base the join on.

9. For Join Options in this dialog box, keep the radio button for “Keep all records” selected.

10. Hit “OK” in this dialog box to complete the join.

Populate the POO_JRSDCTNL_UNIT_ID and POO_PRTCT_UNIT_ID fields with the appropriate unit identifier. Steps for performing

this process are shown in the attribute description table for Wildland Fire Perimeter Polygons above.

The Active NWCG Unit ID report is updated monthly. Each state should refresh their local copy of the Wildland Fire Perimeter

Unit ID table at least yearly.


of 39

Wildland Fire Perimeter Arcs (fper_arc)

The arc features used to define the Wildland Fire Perimeter polygons are described below. These attributes store the feature level

metadata information for the polygon boundaries and document the origin and characteristics of each arc.

Wildland Fire Perimeter Arcs Attributes

GIS NAME ALIAS DATA

FORMAT

ALLOW

NULLS

DEFAULT


COORD_SRC_TYPE Coordinate Source Type Code Char(5) NO UNK DOM_COORD_SOURCE_TYPE NO

COORD_SRC2 Coordinate Source Code Char(25) YES NO

DEF_FET_TYPE Defining Feature Type Code Char(15) NO UNK DOM_DEF_FEATURE_TYPE NO

DEF_FET2 Defining Feature Code Char(30) YES NO

ACCURACY_FT Accuracy Measurement In Feet Long Integer NO -1 NO

ADMIN_ST Administrative State Code Char(2) NO DOM_ADMIN_ST NO

GlobalID GlobalID UUID NO NO

CREATE_DATE Created Date Date NO 09/09/9999 NO

CREATE_BY Created By Name Char(30) NO UNK NO

MODIFY_DATE Modified Date Date NO 09/09/9999 NO

MODIFY_BY Modified By Name Char(30) NO UNK NO

Common Attributes are documented in Bold. Physical definitions and design considerations for common attributes can be found

above in the Common Attributes section.


of 39


COORD_SRC_TYPE Location Source

Type Name

Physical Definition: State-adopted source codes that represent general categories for

origins of the location coordinate.

Attribute Domain Assignment: DOM_COORD_SOURCE_TYPE

Default: UNK

COORD_SRC2 Location Source

Description

Specific Name

Physical Definition: Names that specifically describe the location (coordinate source).

Design Consideration: Suggested code values appear in the Feature Level Metadata

Domains Definitions document. The user may leave this value “null”, choose one of the

suggested codes, or enter another value appropriate to the data. This list of values is not

intended to be all inclusive but may be used as the starting point for state-level lists of

domain values. This list is not intended to be a substitute for the accuracy values found in

the ‘Accuracy Measurement Table’.

DEF_FET_TYPE Defining

Feature Type

Name

Physical Definition: The names of the high-level categories of the physical or mapping

characteristics (features) from which the arcs are derived.

Attribute Domain Assignment: DOM_DEF_FEATURE_TYPE

Default: UNK

DEF_FET2 Defining

Feature

Description

Name

Physical Definition: The names that specifically describe the physical or mapping

features from which the arcs are derived.

Design Consideration: Suggested code values appear in the Feature Level Metadata

Domains Definitions document. The user may leave this value “null”, choose one of the

suggested codes, or enter another value appropriate to the data. This list of values is not

intended to be all inclusive but may be used as the starting point for state-level lists of

domain values.

http://teamspace/sites/blmnds/Standards%20Support%20Information/Feature_Level_Metadata_Domains_v3_0.docx





of 39


ACCURACY_FT Line Form

Accuracy

Measure

Physical Definition: The Accuracy Measurement defines how close, in feet, the actual

ground location is to the spatial depiction in GIS.

Design Consideration: This value would typically be determined by one of three

methods: 1) the map accuracy value, if a U. S. Geological Survey (USGS) map was used

to define the boundary; 2) the expected spatial accuracy achieved with GPS; or 3) the

measurement of that accuracy as is noted in the National Standard for Spatial Data

Accuracy (NSSDA)1 which is a data usability standard issued by the Federal Geographic

Data Committee (FGDC).

A value of -1 indicates that the accuracy is unknown or that no reliable estimate can

be made. Below is an example table of accuracy measurements. (Attempting to list all

values in a domain table would produce an infinite list.)

Accuracy Measurement Example Table

1 +/- 1 Feet

10 +/- 10 Feet

15 +/- 15 Feet

20 +/- 20 Feet

100 +/- 100 Feet

1 Federal Geographic Data Committee. 1998. Geospatial Positioning Accuracy Standards

Part 3: National Standard for Spatial Data Accuracy, FGDC-STD-007.3-1998


of 39

APPENDIX A: DOMAIN VALUE DOCUMENTATION

Documentation about the nature and management of domain values is available on the BLM National Data Standards SharePoint.

Instructions are provided below for navigating to each document on this SharePoint page.

For further details about domains specific to this standard, see the “FPER Domains Document”:

Standards In Progress > Project (standard): FPER- Fire Polygons > Doc Type: 04-Domains

For further details about Global Domains, please see “Global Domains Definitions”:

Standards Support Information > Document Type: Reference > Subject: Domains

For instructions on implementing and maintaining domains in a geodatabase, see “Domains Management for Geodatabases”:

Standards Support Information > Document Type: Instruction > Subject: Domains

For further details about Feature Level Metadata Domains, please see “Feature Level Metadata Domains Definitions”:

Standards Support Information > Document Type: Reference > Subject: Domains

Domain values are maintained separately from the data standard. This is due to values being more likely to have an addition or change

that would not affect the data standard. Domain values cannot be added to attributes specific to the standard (except thru the data

standardization maintenance step). A state can extend the data standard with a new attribute which can have a state specific domain list.

However, all attributes that are required as part of the standard must have a value from the data standard domain list. Any additional

attributes and their associated domain values must be documented with metadata by that office.

http://teamspace/sites/blmnds/default.aspx


of 39

APPENDIX B: ATTRIBUTE METADATA TERMINOLOGY

The following matrix describes the metadata for the Data Standards Implementation Details.

Attribute Metadata

Field

Metadata Definition Example

GIS Name The abbreviated name of the field as it appears in the database. RCVR_TYPE

Alias An alternative name that is more descriptive and user-friendly than

the Logical or GIS Field Name.

GPS RECEIVER TYPE

Data Format Specific type of data allowed/# of characters or numbers/Precision &

Scale.

Char(15)

Allow Nulls? If an attribute is or is not allowed to have a “Null” value. If “NO”,

the attribute is required, if “YES”, the attribute is optional.

NO

Default Value Value that will apply if no other value is specified; included in

domain value list.

N/A

Domain Name Name of the table for that attribute, containing the Code,

Description, and Definition for each value in the table.

DOM_RCVR_TYPE

Derived? If the attribute value is derived from the value of one or more other

attribute values (YES) otherwise, (NO) the value is not derived. The

description of how the attribute is derived will be included in the

Definition/Design Consideration.

NO

Logical Attribute Name The business name of the attribute which includes the entity name,

and representation term. Definitions for Logical Attributes can be

found in the Data Standard Report.

Global Positioning System

Receiver Type Name


of 39

APPENDIX C: EDITOR TRACKING FIELDS

Editor Tracking will be enabled in ArcSDE for national datasets that will be replicated into the BLM EGIS system at the National

Operation Center. When Editor Tracking is activated in ArcGIS, four fields are automatically produced in a geodatabase. These four

editor tracking fields, created_user, created_date, last_edited_user, and last_edited_date hold data similar to four attributes detailed in

the table above. During replication, the editor tracking fields are updated to reflect the replication date and replication process owner.

Editor tracking automatically populates the created_user, created_date, last_edited_user, and last_edited_date attributes.

Four similarly named fields are included as common attributes for arc, line, and point feature classes in order to maintain the history of

each record. CREATE_DATE, CREATE_BY, MODIFY_DATE, and MODIFY_BY must be manually populated by BLM State Personnel.


of 39

APPENDIX D: COMPARISON OF CURRENT FPER VERSION TO PROPOSED VERSION

Fire Perimeter (FPER) Physical Attributes

Version 1.0 Version 2.0

Version 1.0 vs 2.0

explanation Name

Colum

n

Order

Data

Type Name Column Order Data Type

INC_ID 1 Charact

er (22) UNQE_FIRE_ID

Not in State

Version

Character

(22)

Same data, renamed to

follow NWCG data

standards

UNIT_ID 2 Charact

er (8) - - -

Removed from Version

2.0, Unclear as to what

was being stored in

UNIT_ID in version 1.0.

Description is vague.

- - - POO_JRSDCTNL_UNIT_ID 1 Character

(9)

Definition for AGENCY

in Version 1.0 contained

two contradictory

statements indicating it

was for both agency

responsible for fighting

the fire as well as the

NWCG listed agency

where the fire originated.

In Version 2.0, this

attribute was split into 2

attributes

POO_JRSDCTNL_UNIT

_ID and

POO_PRTCT_UNIT_ID.

- - - POO_PRTCT_UNIT_ID 2 Character

(9)


of 39

AGENCY 3 Charact

er (5) RPT_UNIT_ID 3

Renamed and redefined to

clarify the unit ID to enter.

Expected to be a short

term solution while

NWCG clearly identifies

where to report

Jurisdictional Unit ID or

Reporting Unit ID.

FIRE_NAME 4 Charact

er (50) INCDNT_NM 6

Character(5

0)


follow NWCG data

standards

FIRE_COL_DATE 5 Charact

er (8) - - -


2.0

FIRE_YEAR 6 Charact

er (4) FIRE_DSCVR_CY 7 Number

Renamed to make it more

apparent this is a calendar

year, not a fiscal year.

FIRE_MONTH 7 Charact

er (2) - - -


2.0

FIRE_DAY 8 Charact

er (2) - - -


2.0

- - - FIRE_CNTRL_DT 10 Date New in Version 2.0

- - - FIRE_CNTRL_DT_EST_FL

AG 11

Character

(3) New in Version 2.0

FIRE_NUM 9 Charact

er (8) LOCAL_INCDNT_ID 4 Number


follow NWCG data

standards

FIRE_CODE 10 Charact

er (8) FIRE_CODE_ID 5

Character

(4)

Reduced from 8 to 4

characters.


of 39

FIRE_DSCRV_DA

TE 11

Charact

er (8) FIRE_DSCVR_DT 8 Date


follow BLM naming

standards

- - - FIRE_DSCVR_DT_EST_FL

AG 9

Character

(3) New to Version 2.0

TOT_ACRES_RPT

D 12 Decimal TOTAL_RPT_ACRES_NR 14 Decimal

Name change to follow

BLM data standard

naming conventions.

GIS_ACRES 13 Decimal GIS_ACRES 15 Decimal No change

COL_MTHD 14 Charact

er (50) CLCTN_MTHD_NM 13

Character

(25)

Same type of data,

renamed to follow BLM

data standards and domain

value updated to match

NWCG. Refer to FPER

Domain document for the

crosswalk from existing

values to new values.

CAUSE_CAT 15 Charact

er (20) FIRE_CAUSE_NM 12

Character

(15)


follow NWCG data

standards. No crosswalk

needed but please check

spellings on existing

values, especially

“Unknown”.

COMPLEX_NAME 16 Charact

er (50) CMPLX_NM 16

Character

(50)


follow BLM naming

standards

- - - IRWIN_ID 17 Character(5

0) New in Version 2.0


of 39

COMMENTS 17 Charact

er (255) COMMENT 18

Character

(255)


follow BLM naming

standards

REVISION HISTORY

VERSION NO. VERSION TYPE DATE PURPOSE

1.1 Original 8/2/2014 N/A

2.0 Revision February 12, 2015 Updated to match new NWCG standard and address user concerns

2.1 Revision April 20, 2015 Updated to reflect changes and questions from the FPER 2.0 pilot.

2.2 Revision January 25, 2016 Added RPT_UNIT_ID, minor cleanup, updated link to NWCG Unit ID report, updated replication

portion to indicate frequency may increase during fire season, final formatting,

Fire Occurrence and History Perimeter: Final Perimeters ...€¦ · Version 2.2 FINAL 01/25/2016...

Documents

Transcript of Fire Occurrence and History Perimeter: Final Perimeters ...€¦ · Version 2.2 FINAL 01/25/2016...