View
1
Download
0
Category
Preview:
Citation preview
Version 2.2 FINAL 01/25/2016
Page 1 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
Version 2.2 FINAL 01/25/2016
Page 2 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
Version 2.2 FINAL 01/25/2016
Page 3 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.
Version 2.2 FINAL 01/25/2016
Page 4 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.
Version 2.2 FINAL 01/25/2016
Page 5 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
Version 2.2 FINAL 01/25/2016
Page 6 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.
Design Consideration: Software generated value. This field is not editable and is
automatically populated with the date in which the feature is created.
Note: This attribute is included for purposes of replication and tracking purposes only.
Version 2.2 FINAL 01/25/2016
Page 7 of 39
GIS Name Logical Name Physical Definition & Design Consideration
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.
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.
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.
Design Consideration: Software generated value. This field is not editable and is
automatically populated with the date in which the feature is updated.
Note: This attribute is included for purposes of replication and tracking purposes only.
Version 2.2 FINAL 01/25/2016
Page 8 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
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
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
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
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
Version 2.2 FINAL 01/25/2016
Page 9 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.
Version 2.2 FINAL 01/25/2016
Page 10 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.
Version 2.2 FINAL 01/25/2016
Page 11 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.
Version 2.2 FINAL 01/25/2016
Page 12 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.
GIS Name Logical Name Physical Definition & Design Consideration
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
Version 2.2 FINAL 01/25/2016
Page 13 of 39
GIS Name Logical Name Physical Definition & Design Consideration
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
Version 2.2 FINAL 01/25/2016
Page 14 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
Version 2.2 FINAL 01/25/2016
Page 15 of 39
Wildland Fire Perimeter Polygon Attributes
GIS NAME ALIAS DATA
FORMAT
ALLOW
NULLS
DEFAULT
VALUE DOMAIN NAME DERIVED
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.
Version 2.2 FINAL 01/25/2016
Page 16 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.
Ex: USAKADD = United States + Alaska + Anchorage Field Office
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.
Version 2.2 FINAL 01/25/2016
Page 17 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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.
Ex: USAKADD = United States + Alaska + Anchorage Field Office
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.
Version 2.2 FINAL 01/25/2016
Page 18 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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.
Version 2.2 FINAL 01/25/2016
Page 19 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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.
Version 2.2 FINAL 01/25/2016
Page 20 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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.
Design Considerations:
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
Version 2.2 FINAL 01/25/2016
Page 21 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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.
Design Considerations:
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
Version 2.2 FINAL 01/25/2016
Page 22 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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.
Version 2.2 FINAL 01/25/2016
Page 23 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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.
Version 2.2 FINAL 01/25/2016
Page 24 of 39
GIS Name Logical Name Physical Definition and Design Considerations
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
Version 2.2 FINAL 01/25/2016
Page 25 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.
GIS Name Logical Name Physical Definition and Design Considerations
UNQE_FIRE_ID Unique Fire
Identifier
Physical Definition: Concatenation of the Fire Discovered Year, the Reported Unit
Identifier, and the Fire Incident Number.
Design Considerations:
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 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.
Version 2.2 FINAL 01/25/2016
Page 26 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.
Version 2.2 FINAL 01/25/2016
Page 27 of 39
GIS Name Logical Name Physical Definition & Design Consideration
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.
Ex: USAKADD = United States + Alaska + Anchorage Field Office
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.
Version 2.2 FINAL 01/25/2016
Page 28 of 39
GIS Name Logical Name Physical Definition & Design Consideration
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.
Version 2.2 FINAL 01/25/2016
Page 29 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.
Version 2.2 FINAL 01/25/2016
Page 30 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
VALUE DOMAIN NAME DERIVED
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.
Version 2.2 FINAL 01/25/2016
Page 31 of 39
GIS Name Logical Name Physical Definition & Design Consideration
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.
Version 2.2 FINAL 01/25/2016
Page 32 of 39
GIS Name Logical Name Physical Definition & Design Consideration
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
Version 2.2 FINAL 01/25/2016
Page 33 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.
Version 2.2 FINAL 01/25/2016
Page 34 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
Version 2.2 FINAL 01/25/2016
Page 35 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.
Version 2.2 FINAL 01/25/2016
Page 36 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)
Version 2.2 FINAL 01/25/2016
Page 37 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)
Same data, renamed to
follow NWCG data
standards
FIRE_COL_DATE 5 Charact
er (8) - - -
Removed from Version
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) - - -
Removed from Version
2.0
FIRE_DAY 8 Charact
er (2) - - -
Removed from Version
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
Same data, renamed to
follow NWCG data
standards
FIRE_CODE 10 Charact
er (8) FIRE_CODE_ID 5
Character
(4)
Reduced from 8 to 4
characters.
Version 2.2 FINAL 01/25/2016
Page 38 of 39
FIRE_DSCRV_DA
TE 11
Charact
er (8) FIRE_DSCVR_DT 8 Date
Same data, renamed to
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)
Same data, renamed to
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)
Same data, renamed to
follow BLM naming
standards
- - - IRWIN_ID 17 Character(5
0) New in Version 2.0
Version 2.2 FINAL 01/25/2016
Page 39 of 39
COMMENTS 17 Charact
er (255) COMMENT 18
Character
(255)
Same data, renamed to
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,
Recommended