Flood Map Modernization

NFIP Metadata Profiles Specifications

Version 1.1

April 6, 2006

Table of Contents

1.     Introduction

2.     Reference Documents

2.1.     Applicable Documents
2.2.     List of Reference Documents

3.     Overview of NFIP Metadata Profiles

3.1.      Mandatory, Recommended, and Optional Metadata Elements
3.2.      Controlled Vocabularies
3.3.      MIP Searchable Elements
3.4.      MIP Metadata-Element Business Rules
3.5.      Metadata Requirements for Submitting Packages

4.     NFIP Metadata Profile Element Summary

5.     NFIP Metadata Profiles

6.     Glossary of Terms

1.  Introduction

This document contains specifications for the National Flood Insurance Program (NFIP) metadata profiles, which are used to characterize and inventory DFIRM datasets and associated data artifacts in the Mapping Information Platform (MIP).  The ability to describe, search, discover, and reuse DFIRM artifacts is a key requirement of the Flood Map Modernization (MOD) program.  To achieve this, metadata about DFIRM artifacts must be recorded and updated throughout the DFIRM life cycle, from study scoping to collection, storage and management, production, publication, dissemination, and use.

The MOD program developed operational procedures that institutionalize metadata production and maintenance as part of MIP workflows, content management infrastructure, and maintenance tools.  Metadata based on industry-standard information models is a key component of the data development and management process.  Guidance regarding the development and submission of NFIP metadata may be found in the companion document titled NFIP Metadata Profiles Guidance.

This document contains an overview of the NFIP metadata profiles, a table that summarizes the required metadata elements for these profiles, and the actual NFIP metadata profile specifications.

2.  Reference Documents

This section identifies the documents that are referenced directly in the metadata requirements or were used to derive the metadata requirements.

2.1.  Applicable Documents

Applicable documents contain content that is considered to be part of the requirements.  The specified parts of the applicable documents carry the same weight as if they were stated within the body of this document.  The applicable documents are:

• FEMA Internet Publication Standards, v.4.0, Revised February 23 2004.
• Federal Geographic Data Committee (FGDC) Content Standard for Digital Geospatial Metadata (FGDC-STD-001-1998), located at http://www.fgdc.gov/metadata/geospatial-metadata-standards

2.2.  List of Reference Documents

Reference documents are those documents that, although not a part of this document, serve to amplify or clarify its contents.  The specific reference documents are:

• Federal Agency Guidance for Modules 2 and 3 of the Geospatial One Stop Initiative, available at: http://www.geo-one-stop.gov/docs/GOS2_3Guidance1.1.22.pdf
• Request for Comment, Geospatial One-Stop Portal Version 2, Annex A:  Functional Requirements, July 15, 2004, available at: http://www.geo-one-stop.gov/GosRfc/RFC_GOS_Ver_2_Portal_specs.doc
• FGDC "Contract for Interoperable Geospatial Portal Components" found at http://www.fgdc.gov/
• FGDC Metadata Quick Guide located at http://www.fgdc.gov/metadata/metadata-publications/metadata-quick-guide/
• FGDC Top Ten Metadata Errors at http://www.fgdc.gov/metadata/documents/top10metadataerrors.pdf
• FEMA Guidelines and Specifications for Flood Hazard Mapping Partners, Appendix L:  Guidance for Preparing Draft Digital Data and DFIRM Databases, April 2003, located at http://www.fema.gov/plan/prevent/fhm/gs_main.shtm
• FEMA Guidelines and Specifications for Flood Hazard Mapping Partners:  Data Capture Standards, Preliminary Draft April 2004 located at  http://www.fema.gov/plan/prevent/fhm/gs_main.shtm
• Hazard Metadata Assessment Deliverable located at http://extranet.lotus.com/QuickPlace/femamip/main.nsf
• Geospatial One Stop (GOS) Reporting Requirements http://extranet.lotus.com/QuickPlace/femamip/main.nsf

3.  Overview of NFIP Metadata Profiles

This section describes the NFIP metadata profiles, which are based on the FGDC CSDGM.  A CSDGM profile is a subset of the metadata entities and elements of the base standard that describe the application of the standard to a specific user community.  Adopting a profile permits modifications to the optionality or repeatability of non-mandatory elements and domains in the underlying standard, and may additionally contain extended elements.  The NFIP metadata profiles described in this document have been developed from the CSDGM using this profiling process.

FGDC publishes a set of guidelines that must be adhered to when creating a CSDGM profile, including:

• A profile must not change the name, definition, or data type of a standard element.
• A profile may impose more stringent conditionality on elements than the standard requires. (Elements that are optional in the standard may be mandatory in a profile.)
• A profile may contain elements with domains that are more restrictive than the standard. (Elements whose domains have free text in the standard may have a closed list of appropriate values in the profile.)
• A profile may restrict the use of domain values allowed by the standard.  For example, if the standard contains five domain values for a standard element, the profile may specify that its domain consist of three domain values identified in the profile.  The profile may require that the user select a value from the three domain values.
• A profile will not permit anything not allowed by the standard.  (If the standard element has a domain of three values, without a free text element, the profile will not allow a user to enter anything other than those three values.)
• Before creating a profile, the metadata producer will check existing registered profiles.
• A profile must be made available to anyone receiving metadata collected according to that profile.
• The profile document submitted to the FGDC for formal approval contains the same six sections as the introduction section of this standard.

A detailed set of NFIP metadata profiles based on the CSDGM was created to describe the metadata content and structure to be used for NFIP digital geospatial data.  Each of these profiles contains information on recommendations and/or business rules about specific elements in the underlying CSDGM. Information about each profile is provided below, with a focus on these recommendations and business rules.

3.1.  Mandatory, Recommended, and Optional Metadata Elements

The set of mandatory metadata elements for each NFIP metadata profile was specified by retaining all FGDC mandatory elements as mandatory in the NFIP metadata profiles, and also making mandatory selected FGDC, -if-applicable, and optional elements.  The mandatory designation of NFIP metadata-profile elements includes the following:

• Data quality information (specifically requiring lineage information in the form of a listing of data sources used for a particular submission and processing steps summarizing the submission production steps)
• Spatial data organization information (specifically specifying the direct spatial reference method)
• Spatial reference information (specifically horizontal system projection information, grid system information, datum information; and in the case of elevation, terrain and survey packages, and vertical coordinate system information)
• Entity and attribute information (especially requiring definitions of entity types enclosed within each submission, as well as the mandatory overview description)
• Distribution information (especially requiring information about the digital standard order process)

3.2.  Controlled Vocabularies

Controlled vocabularies are domain-specific taxonomies, thesauri, dictionaries, and schema for terms and data elements developed by "communities of interest" as an authority controlling the use and update of the vocabulary.  FEMA and MIP stakeholders involved in all or parts of the DFIRM life cycle may be considered a "community of interest."  For MIP data submission types, controlled vocabularies have been created for the following elements:

• Geospatial representation (controlled list of MIP data submission types)
• Theme keywords (controlled list of keywords per submission type)
• Place keywords (controlled list of States and counties)
• Native data set environment (controlled list of hydrology, hydraulic, coastal, and alluvial fan models)
• Lineage source information (controlled list of information sources per submission type)
• Entity type (controlled list of entities and their descriptions per submission type)

With this controlled vocabulary defined and consistently applied during the development of MIP metadata, automated search and discovery capabilities of MIP data holdings will be greatly improved in the future.  By using a common, controlled vocabulary for metadata, users can be confident that data granules being returned from one geographic location or project are consistent with other parts of the search area, even if the work was not completed as a part of the same study.

3.3.  MIP Searchable Elements

End users may perform searches of NFIP metadata using a number of metadata catalogs and services; the technologies and standards upon which metadata catalogs and services are based are described in Section 2.3, "Metadata Catalogs and Services," of the NFIP Metadata Profiles Guidelines document.  The NFIP metadata will be searchable through the Content Manager (CM) component of the MIP as well as through the Geospatial One Stop (GOS) portal, which is part of the National Spatial Data Infrastructure (NSDI).

When NFIP metadata is searched via the GOS portal, a search will be performed using the Z39.50 Geo Profile, which is described in Section 2.3.1 entitled "Z39.50 – Geo Profile" of the NFIP Metadata Profiles Guidelines document.  Table 1 shows the mandatory Z39.50 GEO Profile elements and their support within Content Manager for searching.  The table shows the CSDGM elements that are required to fully support external metadata searches from the NSDI and GOS systems, and the current support within Content Manager for searches by these elements.

Table 1.  Mandatory Searchable Elements of Z39.50 Geo Profile[1]

In addition to supporting NFIP metadata searches via the Z39.50 Geo Profile elements indicated in table 1, the MIP supports searching via the additional elements shown in table 2.

Table 2.  Additional Elements Used by MIP Content Manager (CM) for Search[2]

3.4.  MIP Metadata-Element Business Rules

In addition to specific guidance provided in the individual metadata profiles presented in Section 4 of this document, business rules that govern the content of metadata elements are provided in table 3.  These business rules include explanation and guidance that is driven by the relationship between individual metadata elements.  As an example, the distinction between Originator (element 1.1.1) and Publisher (element 1.8.1.2), and the relationship between date elements such as Publication Date (element 1.1.2) and Time Period (element 1.3.1), should be reviewed carefully and understood.

Table 3.  Business Rules and Meaning of Key Metadata Elements

3.5.  Metadata Requirements for Submitting Packages

The following requirements for metadata collection during the DFIRM production life cycle pertain to the package submissions as noted, and are based in part on the Guidance for Preparing Draft Digital Data and DFIRM Databases [6].

• To facilitate data discovery, access, and processing, the assigned Mapping Partner shall submit Federal Geographic Data Committee (FGDC) compliant metadata.
• The assigned Mapping Partner shall prepare and submit a metadata file with all digital data submittals to facilitate the use of these data and the transfer of data files between users.
• Only one metadata file is required for each submittal.  However, in this one file, the assigned Mapping Partner must distinguish between the different origins of the various datasets included.
• Source Citation:
• For each data source used, the assigned Mapping Partner shall add a Source Citation entry to the DFIRM metadata file in the Lineage section under Data Quality.  Within the metadata file, each data source is assigned a Source Citation Abbreviation.
• The metadata file must include a description of the source material from which the data were derived and the methods of derivation, including all transformations involved in producing the digital files.
• The description shall include the dates of the source material and the dates of ancillary information used for update.  The date assigned to a source must reflect the date that the information corresponds to the ground.  If the assigned Mapping Partner does not know this date, then the Mapping Partner may use a date of publication and indicate as such.
• Each data source in the metadata file must be assigned a Source Citation Abbreviation as described in Appendix L of FEMA’s guidelines & specifications.
• The assigned Mapping Partner shall describe any database created by merging information obtained from distinct sources in sufficient detail to identify the actual source for each element in the file.
• Entity and Attributes Information:
• Because not all DFIRM database tables are included in every draft DFIRM digital data submittal, the Overview Description Section of the Entity and Attribute Information of the DFIRM package metadata file must include a list of all DFIRM database tables included in the submittal.
• As part of data collection, coordination, and submittal, the assigned Mapping Partner shall document the following information for all of the digital data used and submitted:
• data sources
• date of collection or digitizing
• scale of digitizing
• projections
• coordinate systems
• horizontal datum and vertical datum
• Each source citation abbreviation for a distinct data source should be numbered (e.g., BASE1, BASE2, BASE3).
• The digital data deliverables must clearly identify the data structure options that were used.
• Raster data may be provided in many formats, but also require metadata.
• Digital orthophoto files may be submitted in Tagged Image File Format (.TIF), Georeferenced TIF (GeoTIF), Band Interleaved by Pixel (.BIP or .BIL), Multi-Resolution Seamless Image Database (MrSID), Portable Network Graphics (PNG), or Joint Photographic Experts Group (JPEG) format.
• Raster files must be accompanied with metadata that provides coordinate information so that they can be georeferenced.
• Vector data may be provided in many formats.
• ESRI export file – E00; ESRI shape file – SHP; MicroStation design file – DGN; MapInfo interchange format – MIF; MapInfo native table format – TAB; AutoCAD drawing file – DWG; Drawing exchange format – DXF; Digital Line Graph – DLG; or Spatial Data Transfer Standard – SDTS; other
• Wherever possible, the assigned Mapping Partner shall use the following metadata file naming convention for DFIRM submissions.
• The file should be named with the combination of the two-digit State FIPS code and community or county identification number (CID), followed by an "_" and the effective date of the study (using the YYYYMMDD format), followed by "_metadata" and the appropriate file extension (i.e., <ST_FIPS><PCOMM>_<EFF_DATE>_metadata.txt). The CID is the first through the sixth digits of the panel number.  For community based maps this corresponds to the FEMA CID. For countywide maps this is the county (or county equivalent) FIPS code with a "C".  For studies that are Draft or Preliminary and not yet effective, the word "DRAFT" or "PRELIM" should be used instead of the effective date. For example, the name of a metadata file for an effective study would be similar to 99001C_19980915_metadata.txt [.xml] while the same file for a preliminary study could be 99001C_PRELIM_metadata.

4.  FIP Metadata Profile Element Summary

Metadata profiles for the nine NFIP submission packages are described in Section 4 entitled "NFIP Metadata Profiles".  However, Table 4 provides a convenient summary of the required elements for each of the ten NFIP metadata profiles:

• Alluvial Fan
• Basemap
• Coastal
• DFIRM
• Floodplain Mapping/Redelineation
• Hydraulics
• Hydrology
• Orthoimagery
• Survey
• Terrain

In table 4, an "R" in a column indicates that the corresponding metadata element is required for the specific NFIP metadata profile.  As noted earlier, the NFIP metadata profiles are based on the CSDGM, which is a hierarchical organizational structure.  In both the CSDGM and the NFIP metadata profiles that have been derived from them, "parent" elements are used to organize "child" elements, and do not contain textual content; parent elements serve to group child elements, which in turn may serve as parents to other child elements, and so on.  It is only the lowest-level child elements that actually contain textual content.

Given this distinction between required parent and children elements, table 4 denotes all required elements (both parent and children) with an "R"; however, only the lowest-level children elements are indicated with a shaded "R" for which a value is required.  A review of the metadata examples provided in Section 5 entitled "NFIP Metadata Profile Examples" in the NFIP Metadata Profiles Guidelines document should readily clarify this distinction.  An asterisk (*) after an element name means that this element may be repeated an unlimited number of times.

Table 4.  Summary of required elements for NFIP metadata profiles

5.  NFIP Metadata Profiles

Metadata profile specifications for the ten different NFIP submission packages below are currently maintained as separate documents, as described in table 5.

Table 5.  NFIP Metadata Profiles and Corresponding Specifications Documents

6.  Glossary of Terms

Footnotes

[1] Source:  http://www.fgdc.gov/standards/projects/FGDC-standards-projects/metadata/base-metadata/v2_0698.pdf and http://www.blueangeltech.com/standards/GeoProfile/geo22.htm

[2] Sources: "Component Technical Design:  Content Manager Integration Components eXtensible Media Beans (XMB)" (01/11/2005); Source:  "Component Technical Design:  Search and Fetch Content" (12/03/2004)

[3] NSP assigned meaningful project case number or ID (e.g., 05-05-0001S)

[4] The current element [1.3.2] was recommended to be an additional searchable element within the MIP CM data model.

[5] The ‘metd’ element [7.1] is required for GOS harvesting of recently updated metadata records.

[6] The Horizsys.Geograph, Horizsys.Planar and Horizsys.Local elements are mutually exclusive (i.e., only one of these elements must be used). See profiles for details.

[7] The Horizsys.Geograph, Horizsys.Planar and Horizsys.Local elements are mutually exclusive (i.e., only one of these elements must be used). See profiles for details.

[8] The Planar.Mapproj, Planar.Gridsys and Planar.Localpd elements are mutually exclusive (i.e., only one of these elements must be used). See profiles for details.