Search Help Show/Hide Menu

Data Management Plan

DMP Template v2.0.1 (2015-01-01)

Please provide the following information, and submit to the NOAA DM Plan Repository.

Reference to Master DM Plan (if applicable)

As stated in Section IV, Requirement 1.3, DM Plans may be hierarchical. If this DM Plan inherits provisions from a higher-level DM Plan already submitted to the Repository, then this more-specific Plan only needs to provide information that differs from what was provided in the Master DM Plan.

URL of higher-level DM Plan (if any) as submitted to DM Plan Repository:
Always left blank

1. General Description of Data to be Managed

1.1. Name of the Data, data collection Project, or data-producing Program:
2003 Pearl River County, Mississippi Lidar: Flood Plain Management Project
1.2. Summary description of the data:

This lidar data was collected primarily for flood plain mapping within Pearl River County, MS. The data were

processed into separate Bare Earth and First Surface products. The two were subsequently classified (bare earth and

unclassified) and merged to create one data set. The data were collected from 1-8 Feb 2003. One flight was reflown

on 30 March 2003.

Original contact information:

Contact Name: Mr. Elijah Hunt

Contact Org: U.S. Army Corps of Engineers Vicksburg District

Phone: 601-631-7040

Taken From: Item Identification | Abstract
Notes: Only a maximum of 4000 characters will be included.
1.3. Is this a one-time data collection, or an ongoing series of measurements?
One-time data collection
Taken From: Extents / Time Frames | Time Frame Type
Notes: Data collection is considered ongoing if a time frame of type "Continuous" exists.
1.4. Actual or planned temporal coverage of the data:
2003-02-01 to 2003-02-08
Taken From: Extents | Time Frame - Start, Time Frame - End
Notes: All time frames from all extent groups are included.
1.5. Actual or planned geographic coverage of the data:
W: -89.512658, E: -89.201145, N: 31.010543, S: 30.263267
Taken From: Extents | Geographic Area Bounds, Geographic Area Description
Notes: All geographic areas from all extent groups are included.
1.6. Type(s) of data:
(e.g., digital numeric data, imagery, photographs, video, audio, database, tabular data, etc.)
No information found
1.7. Data collection method(s):
(e.g., satellite, airplane, unmanned aerial system, radar, weather station, moored buoy, research vessel, autonomous underwater vehicle, animal tagging, manual surveys, enforcement activities, numerical model, etc.)
No information found
1.8. If data are from a NOAA Observing System of Record, indicate name of system:
Always left blank due to field exemption
1.8.1. If data are from another observing system, please specify:
Always left blank due to field exemption

2. Point of Contact for this Data Management Plan (author or maintainer)

2.1. Name:
NOAA Office for Coastal Management (NOAA/OCM)
Taken From: Support Roles (Metadata Contact) | Person
Notes: The name of the Person of the most recent Support Role of type "Metadata Contact" is used. The support role must be in effect.
2.2. Title:
Metadata Contact
Always listed as "Metadata Contact"
2.3. Affiliation or facility:
NOAA Office for Coastal Management (NOAA/OCM)
Taken From: Support Roles (Metadata Contact) | Organization
Notes: The name of the Organization of the most recent Support Role of type "Metadata Contact" is used. This field is required if applicable.
2.4. E-mail address:
coastal.info@noaa.gov
Notes: The email address is taken from the address listed for the Person assigned as the Metadata Contact in Support Roles.
2.5. Phone number:
(843) 740-1202
Notes: The phone number is taken from the number listed for the Person assigned as the Metadata Contact in Support Roles. If the phone number is missing or incorrect, please contact your Librarian to update the Person record.

3. Responsible Party for Data Management

Program Managers, or their designee, shall be responsible for assuring the proper management of the data produced by their Program. Please indicate the responsible party below.

3.1. Name:
No information found
Taken From: Support Roles (Data Steward) | Person
Notes: The name of the Person of the most recent Support Role of type "Data Steward" is used. The support role must be in effect.
3.2. Position Title:
Data Steward
Always listed as "Data Steward"

4. Resources

Programs must identify resources within their own budget for managing the data they produce.

4.1. Have resources for management of these data been identified?
No information found
4.2. Approximate percentage of the budget for these data devoted to data management (specify percentage or "unknown"):
No information found

5. Data Lineage and Quality

NOAA has issued Information Quality Guidelines for ensuring and maximizing the quality, objectivity, utility, and integrity of information which it disseminates.

5.1. Processing workflow of the data from collection or acquisition to making it publicly accessible
(describe or provide URL of description):

Process Steps:

  • Flight Report A Cessna Skymaster 337, N111AT, was mobilized from Huntsville International Airport, Huntsville, AL to Picayune Municipal Airport, Picayune, MS on 30 Jan 2003. This aircraft was outfitted with an Optech ALTM 1210 LIDAR system. Mission planning for the project determined that 103 flight lines would be needed to successfully cover the specified area, including three control lines. These lines would be flown at a 120-knot ground speed, 1250 meters above ground level and would take approximately 37.5 hours to complete. Three GPS base stations supplied and operated by Sea Systems Corporation were used to support precise positioning and orientation of the ALTM's sensor head during the entire duration of flight. The GPS base stations were Trimble 5700 receiver units utilizing Zephyr Geodetic antennas. Each GPS base station was located within the boundary of the project area. The actual local flight times and duration of flights were controlled by fuel consumption of the aircraft, safety of flight operations in the particular airspace and during times when the GPS constellation was most favorable, producing the highest number of satellites visible in the best geometric configuration relative to the GPS receivers onboard the aircraft as well as at the master stations on the ground. A standard of flying with no less than 7 satellites visible and a PDOP (position dilution of precision) of less than 3.0 was adopted. The initial aerial survey was completed over the course of 8 days. Data collection started around 23h30 UTC on Saturday, 01 February 2003. Flightlines completed during this flight were lines one through 12. On 01 February the flight commenced at 02h50 UTC and completed lines thirteen through twenty-nine. The flight on 02 February began around 23h10 UTC and collected lines thirty through thirty-eight. A second flight was then flown beginning around 02h30 UTC on 03 February and completing lines thirty-nine through forty-five. On 04 February the flight commenced around 22h40 UTC and covered lines forty-five through fifty-four. The second flight followed a refueling stop around 02h30 UTC and completed lines fifty-five through sixty-six. The flight on 05 February covering lines 67-69 and 97 through 100 began around 22h10 UTC and ended around 00h30 due to weather. The final day of initial data collection occurred on 08 February. Two flights were flown this day. The initial flight began around 00h46 UTC and covered lines seventy through eighty-eight and line 103. The second flight began around 22h19 UTC and completed lines 67-69, 89-96 and 101 and 102. This completed the initial LIDAR data collection for the project and the ground crews continued in their remaining work in and around the project area.
  • The aircraft and personnel involved during the LIDAR portion of the survey were demobilized on the night of Sunday, 09 Feb 2003. Following a preliminary examination of the collected data it was determined that one flight was required to refly some of the collected lines. A Cessna Skymaster 337, N111AT, was mobilized from Huntsville International Airport, Huntsville, AL to Picayune Municipal Airport, Picayune, MS on 30 Mar 2003. This aircraft was outfitted with an Optech ALTM 1210 LIDAR system. Data collection commenced at approximately 22h35 UTC and constituted reflying lines 5, 9, 86-88, 92 and 103 for various technical reasons. This completed the LIDAR data collection for the project and the ground crews continued in their remaining work in and around the project area. The aircraft and personnel involved during the LIDAR portion of the survey were demobilized on Monday, 31 Mar 2003. A Cessna 210, N732JE, was mobilized from Huntsville International Airport, Huntsville, AL to Picayune Municipal Airport, Picayune, MS on 11 FEB 2003. This aircraft was outfitted with a RC30 Camera and AGFA Pan 80 film. Mission planning for the project determined that 40 flight lines would be needed to successfully cover the specified area at the various flying altitudes. These lines would be flown at 4800 feet above ground level with 80/30 overlap, 9030 feet above ground level with 60/30 overlap, 12000 feet above ground level with 80/30 overlap and would take approximately 18 hours to complete. Three GPS base stations supplied and operated by Sea Systems Corporation were used to support precise positioning and orientation of the photo centers during the entire duration of flight. Each GPS base station was located within the boundary of the project area. The actual local flight times and duration of flights were controlled by fuel consumption of the aircraft, safety of flight operations in the particular airspace and during times when the sun angle was most favorable. The aerial survey was completed over the course of 3 days. Data collection started around 11h19 local on Tuesday, 11 February 2003. Flightlines completed on this day ranged from one to nine at 4800 feet and one through five at 9030 feet.
  • Collection recommenced around 9h47 local on 12 February. Lines completed during this flight were six through 12 at 9030. On 13 February collection began around 09h26 local and lasting through 15h00 local. Lines collected during this flight included ten to eighteen at 9030 and ten through twenty-three at 12000 feet. This completed the photo collection for the project and the ground crews continued in their remaining work in and around the project area. The aircraft and personnel involved during the photo portion of the survey were demobilized during the afternoon of Thursday, 13 February 2003. Upon inspection of the film it was determined that reflights would be necessary. On 23 February 2003 a Cessna 335, N918AA, was mobilized from Huntsville International Airport, Huntsville, AL to Picayune Municipal Airport, Picayune, MS outfitted with a RC30 Camera and AGFA Pan 80 film. Collection took place between 09h34 and 12h31 local. Lines six, eight and nine at 9030 and lines sixteen, seventeen, twenty and twenty-three at 12,000 were reflown. GPS/IMU Data Processing Upon completion of the flight portions of the project the GPS data was post processed for quality and backed up. For redundancy and accuracy purposes, the airborne GPS data were processed from the base stations using GrafNav from Waypoint Consulting, Inc. Results from the LiDAR N111AT JD_032F01 Final Solution. The final solution for this flight is PR43/PR43 FWD/REV. The REV solution from PR15 and the FWD solution from B154 matched fairly well with the final, but are not used in the final due to the long baseline distances. PECK was not processed since an incorrect point was occupied during the flight. This solution is considered good. DLW 10 April 2003 JD_032F01 Final Solution. The final solution for this flight is PR43/PR43 FWD/REV. The FWD solution from both PR15 and B154 matched very well, within a couple of centimeters, with the final, but are not used in the final due to the long baseline distances. The REV solutions from PR 15 and B154 were both off by about 10 cm.
  • PECK was not processed since an incorrect point was occupied during the flight. This solution is considered very good. MWB 2 April 2003 JD_032F02 Final Solution The final solution for this flight is PR43/PR43 FWD/REV. The combined solution from PR15 matched, but adds noise. The FWD solution from B154 matched but is not used in the final due to the long baseline distance. PECK was not processed since an incorrect point was occupied during the flight. This solution is considered very good. MWB 2 April 2003 JD_033F01 Final Solution The final solution for this flight is B154/PR15 CMB/CMB. The solutions from PR43 matched, but added more noise. PECK processed ok and could have been processed to match, but it was not needed as part of the solution. This solution is considered very good. MWB 2 April 2003 JD_033F02 Final Solution The final solution for this flight is B154/PECK/PR15 CMB/CMB/CMB. All solutions from all bases processed very well. PR43 matched, but was not used because of the added noise. This solution is considered very good. MWB 2 April 2003 JD_035F01 Final Solution The final solution for this flight is B154/PR43 REV/CMB. The REV solution from PR19 matched, but added noise. The FWD solutions from B154 and PR19 did not process as well as the REV solutions. PR05 did not process well in either direction, probably because of baseline distance. This solution is considered good. MWB 2 April 2003 JD_035F02 Final Solution The final solution for this flight is B154/PR19/PR43 CMB/CMB/CMB. All solutions from all stations processed very well. PR05 was not used because of baseline distance. This solution is considered very good. MWB 3 April 2003 JD_036F01 Final Solution The final solution for this flight is PR05/PR19/PR43 REV/REV/CMB. All solutions from the three stations processed well. The FWD solutions from PR05 and PR19 could have been used with some work. B154 needed some reprocessing, but was not needed because of baseline distance. This solution is considered good. MWB 3 April 2003 JD_038F01 Final Solution The final solution for this flight is PR05/PR19/PR43 CMB/CMB/CMB. All solutions from all stations processed well. B154 was not needed because of baseline distance. This solution is considered very good. MWB 3 April 2003 JD_039F01 Final Solution The final solution for this flight is PR05/PR19/PR43 REV/CMB/CMB. All solutions from all stations processed well. The FWD from PR05 processed ok, but was rather noisy. B154 was not needed because of baseline distance. This solution is considered very good. MWB 3 April 2003 JD_089F01 Final Solution The final solution for this flight is PR17/PR17 FWD/REV. Station PR43 did not process well. External noise seems to be influencing the data. PR17 processed well during the data collection times of the flight. The data were noisy during the mobilization from the airport to the work site. This may be due to baseline distance. This solution is considered good. MWB 9 April 2003 These trajectories were used in the processing of the inertial data. The inertial data were processed using PosProc from Applanix, Inc. This software produces an SBET ("smooth best estimate of trajectory") using the GPS trajectory from GrafNav and the roll, pitch and heading information recorded by the POS (Position and Orientation System). Results were favorable for all flights and errors are estimated to be less than 5cm.
  • Respectfully Submitted, MD Atlantic Technologies, Inc. Darrick L. Wagg, P.Geo. 15Jun2004 Data Processing Report Data collection of the survey areas resulted in a total of 103 flight lines covering the project area including 3 control lines. The tapes, flight logs, raw air and ground GPS files were then taken to the office for data processing using Realm, a LiDAR processing software package from Optech. Processing began by downloading these files into a Realm database. Although Realm has the capability to perform GPS processing and to utilize real-time inertial data, MD Atlantic utilizes other methods of obtaining this information as Realm only has the capability to produce a single-baseline solution. For redundancy and accuracy purposes, the airborne GPS data were processed from two base stations using GrafNav from Waypoint Consulting, Inc. The agreement between a minimum of two solutions checked or combined between a minimum of two stations was better than 10 cm in each of X, Y, and Z. These trajectories were used in the processing of the inertial data. The inertial data were processed using PosProc from Applanix, Inc. This software produces an SBET ("smooth best estimate of trajectory") using the GPS trajectory from GrafNav and the roll, pitch and heading information recorded by the POS (Position Orientation System). Realm uses the SBET to generate a set of XYZ data points for each laser return. Data can be segregated based on the first- and last-pulse information. First and last pulse files were created during the processing of this dataset. This project's data were processed in strip form, meaning each flight line was processed independently. Processing the lines individually provides the data analyst with the ability to QC the overlap between lines. Raw lidar data are processed within the lidar manufacturer's software to produce XYZI files. These files are output in UTM coordinates with a corresponding Ellipsoid Height value. Output XYZI files from Realm were converted from UTM co-ordinates with GRS80 ellipsoid elevations into State Plane Coordinate System (NAD83) with NGVD29 orthometric heights using the U.S. Army Corps of Engineers' Corpscon, version 5.11.08. Corpscon utilizes the Geoid96 model for the ellipsoid to orthometric height conversions. The resultant XYZI files were subsequently imported into a project, on a per pulse basis, using TerraScan (Terrasolid Ltd.) where each line was checked against adjacent lines. This check revealed an issue with the calibration numbers being used for the system. Further investigation led to the understanding that calibration parameters would have to be determined on a line-by-line basis. Though uncommon, this situation is not unheard of with airborne laser terrain mapper systems. Once the calibration parameters for each line were determined and the data recalculated, the data was checked against the control and validation points across the project area. The results of these checks showed a bias in the dataset for all lines, save for 97 and 99, of -1.2 U.S. Survey Feet. It was determined that an adjustment to correct for this bias would be best for the dataset. A subsequent check of the DEM found it fitting the validation and control points well. See LiDAR DEM Quality Control Report for results. The data from each line was then combined and a classification routine performed to determine the rough surface model. This initial surface model was then reduced using MD Atlantic's proprietary methods to create the final bare-earth dataset. A Triangular Irregular Network (TIN) was generated using the final surface data. Contours were then created from the TIN for use in performing a quality control of the surface. The LiDAR data were taken into a stereo environment and melded with photogrammetric data. Breaklines were subsequently compiled along hydro features to support the contour generation.
  • Respectfully Submitted, MD Atlantic Technologies, Inc. Darrick L. Wagg, P.Geo. 03Jun2004 ARC Grids Processing Procedures Processing of the ARC Grids and Tins began by merging dtm models that overlaid the tile boundary. The merged dtm file was then imported into an ARC/Info point coverage that was utilized as an input source during the tin processing. Along with the ARC/Info point coverage, the ARC Generate file of the breaklines was also utilized as an input source during the Tin process. The final input during the Tin process was to use the tile polygon boundary to clip the Tin file. Once the Tin was created, the generation of the 5ft Grids was processed through the ARC/Info TINLATTICE command. The final product is a Grid with 5ft postings, clipped to the tile boundary. The final step to having deliverable Grids was to ensure that the projection was defined for each Grid. The ARC/Info command PROJECTDEFINE was utilized for this process. ARC Shape Files Processing Procedures The first step in the Shapefile process was to import the Microstation DGN files into ARC/Info coverages. Once the files are in an ARC/Info coverage file format, then a Join was performed on the Arc Attribute Table with the ACODE Info file, which is produced during the IGDSARC translation. The next step is to add any new items that are to be converted over to the ARC shapefile DBF. Once all the applicable items are properly calculated, then all unnecessary items are dropped. The ARC coverages are then exported as a shapefile, which will contain only the necessary fields in the tables. Respectfully Submitted, MD Atlantic Technologies, Inc. Jesse Gregg, GIS Technician
  • 2008-02-20 00:00:00 - The NOAA Office for Coastal Management (OCM) received the files in ASCII xyz format. The files contained Lidar elevation measurements. The data consisted of a bare earth and a first return data set. The two were subsequently classified (bare earth and unclassified) and merged to create one data set. The data was in Mississippi State Plane Projection, Zone 2301 and NGVD29 vertical datum. OCM performed the following processing for data storage and Digital Coast provisioning purposes: 1. The data were converted from Mississippi State Plane coordinates to geographic coordinates. 2. The data were converted from NGVD29 (orthometric) heights to NAVD88 (orthometric) heights. 3. The data were converted from NAVD88 (orthometric) heights to GRS80 Ellipsoid heights using Geoid99. 4. Bare earth data set and first return data set merged. 5. The data were sorted by latitude and the headers were updated.
5.1.1. If data at different stages of the workflow, or products derived from these data, are subject to a separate data management plan, provide reference to other plan:
Always left blank
5.2. Quality control procedures employed
(describe or provide URL of description):
No information found

6. Data Documentation

The EDMC Data Documentation Procedural Directive requires that NOAA data be well documented, specifies the use of ISO 19115 and related standards for documentation of new data, and provides links to resources and tools for metadata creation and validation.

6.1. Does metadata comply with EDMC Data Documentation directive?
No
Notes: All required DMP fields must be populated and valid to comply with the directive.
6.1.1. If metadata are non-existent or non-compliant, please explain:

Missing/invalid information:

  • 1.6. Type(s) of data
  • 1.7. Data collection method(s)
  • 3.1. Responsible Party for Data Management
  • 4.1. Have resources for management of these data been identified?
  • 4.2. Approximate percentage of the budget for these data devoted to data management
  • 5.2. Quality control procedures employed
  • 7.1. Do these data comply with the Data Access directive?
  • 7.1.1. If data are not available or has limitations, has a Waiver been filed?
  • 7.1.2. If there are limitations to data access, describe how data are protected
  • 7.4. Approximate delay between data collection and dissemination
  • 8.1. Actual or planned long-term data archive location
  • 8.3. Approximate delay between data collection and submission to an archive facility
  • 8.4. How will the data be protected from accidental or malicious modification or deletion prior to receipt by the archive?
Notes: Required DMP fields that are not populated or invalid are listed here.
6.2. Name of organization or facility providing metadata hosting:
NMFS Office of Science and Technology
Always listed as "NMFS Office of Science and Technology"
6.2.1. If service is needed for metadata hosting, please indicate:
Always left blank
6.3. URL of metadata folder or data catalog, if known:
Always listed as the URL to the InPort Data Set record
6.4. Process for producing and maintaining metadata
(describe or provide URL of description):
Metadata produced and maintained in accordance with the NOAA Data Documentation Procedural Directive: https://nosc.noaa.gov/EDMC/DAARWG/docs/EDMC_PD-Data_Documentation_v1.pdf
Always listed with the above statement

7. Data Access

NAO 212-15 states that access to environmental data may only be restricted when distribution is explicitly limited by law, regulation, policy (such as those applicable to personally identifiable information or protected critical infrastructure information or proprietary trade information) or by security requirements. The EDMC Data Access Procedural Directive contains specific guidance, recommends the use of open-standard, interoperable, non-proprietary web services, provides information about resources and tools to enable data access, and includes a Waiver to be submitted to justify any approach other than full, unrestricted public access.

7.1. Do these data comply with the Data Access directive?
No information found
7.1.1. If the data are not to be made available to the public at all, or with limitations, has a Waiver (Appendix A of Data Access directive) been filed?
No information found
7.1.2. If there are limitations to public data access, describe how data are protected from unauthorized access or disclosure:

None

7.2. Name of organization of facility providing data access:
NOAA Office for Coastal Management (NOAA/OCM)
Taken From: Support Roles (Distributor) | Organization
Notes: The name of the Organization of the most recent Support Role of type "Distributor" is used. The support role must be in effect. This information is not required if an approved access waiver exists for this data.
7.2.1. If data hosting service is needed, please indicate:
Taken From: Data Management | If data hosting service is needed, please indicate
Notes: This field is required if a Distributor has not been specified.
7.2.2. URL of data access service, if known:
Taken From: Distribution Info | Download URL
Notes: All URLs listed in the Distribution Info section will be included. This field is required if applicable.
7.3. Data access methods or services offered:

This data can be obtained on-line at the following URL: https://coast.noaa.gov/dataviewer;

7.4. Approximate delay between data collection and dissemination:
No information found
7.4.1. If delay is longer than latency of automated processing, indicate under what authority data access is delayed:

8. Data Preservation and Protection

The NOAA Procedure for Scientific Records Appraisal and Archive Approval describes how to identify, appraise and decide what scientific records are to be preserved in a NOAA archive.

8.1. Actual or planned long-term data archive location:
(Specify NCEI-MD, NCEI-CO, NCEI-NC, NCEI-MS, World Data Center (WDC) facility, Other, To Be Determined, Unable to Archive, or No Archiving Intended)
No information found
8.1.1. If World Data Center or Other, specify:
Taken From: Data Management | Actual or planned long-term data archive location
Notes: This field is required if archive location is World Data Center or Other.
8.1.2. If To Be Determined, Unable to Archive or No Archiving Intended, explain:
Taken From: Data Management | If To Be Determined, Unable to Archive or No Archiving Intended, explain
Notes: This field is required if archive location is To Be Determined, Unable to Archive, or No Archiving Intended.
8.2. Data storage facility prior to being sent to an archive facility (if any):
Office for Coastal Management - Charleston, SC
Taken From: Physical Location | Organization, City, State, Location Description
Notes: Physical Location Organization, City and State are required, or a Location Description is required.
8.3. Approximate delay between data collection and submission to an archive facility:
No information found
8.4. How will the data be protected from accidental or malicious modification or deletion prior to receipt by the archive?
Discuss data back-up, disaster recovery/contingency planning, and off-site data storage relevant to the data collection
No information found

9. Additional Line Office or Staff Office Questions

Line and Staff Offices may extend this template by inserting additional questions in this section.

Always left blank