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:
2011 MN DNR Lidar: Twin Cities Metro, MN
1.2. Summary description of the data:

Fugro Horizons Inc. acquired highly accurate Light Detection and Ranging (LiDAR) elevation data for the Twin Cities metropolitan region in east-central Minnesota in Spring and Fall 2011, with some reflights in Spring 2012. The data cover Anoka, Benton, Carver, Dakota, Goodhue, Hennepin, Isanti, Kanabec, Meeker, Mille Lacs, Morrison, Ramsey, Scott, Sherburne and Washington counties.

Most of the data was collected at 1.5 points/square meter. Smaller areas were collected with 2 points/square meter and with 8 points/square meter:

1. 1.5 points/square meter covers Morrison, Mille Lacs, Benton, Isanti, Sherburne, Anoka, Meeker, Hennepin, Washington, Carver, Scott, and Goodhue counties.

2. 2 points/square meter covers the Dakota Block (southern 2/3 of Dakota County)

3. 8 points/square meter covers portions of Minneapolis/St. Paul and the City of Maple Grove

See map of block boundaries: ftp://lidar.dnr.state.mn.us/documentation/status/metro_data_delivery_dates.pdf

Data are in the UTM Zone 15 coordinate system, NAD83 NAVD88 Geoid09 meters. The tiling scheme is 16th USGS 1:24,000 quadrangle tiles.

The vendor delivered the data to the Minnesota Department of Natural Resources (DNR) in several formats:

1. One-meter digital elevation model

2. Edge-of-water breaklines

3. Classified LAS formatted point cloud data

DNR staff quality-checked the data and created two additional products: two-foot contours and building outlines.

Note: The original metadata record was created at the Minnesota Geospatial Information Office using information supplied by the vendor and by DNR.

This metadata record reflects the Metro Twin Cities data blocks (A_C, B, D, E, F, G, H) that are available from the NOAA Digital Coast Data Access Viewer (DAV).

The NOAA Office for Coastal Management (OCM) downloaded 2324 laz point data files from these MN DNR sites:

https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_a_c/ (418 files)

https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_b/ (233 files)

https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_d/ (599 files)

https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_e/ (204 files)

https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_f/ (477 files)

https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_g/ (129 files)

https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_h/ (264 files)

The data were processed to the NOAA Digital Coast Data Access Viewer (DAV), to make the data available for custom downloads, and to AWS S3 for bulk downloads.

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:
2011-05-11 to 2011-11-15, 2011-05-10, 2011-05-11 to 2011-05-15, 2011-04-29 to 2011-05-08, 2011-04-25, 2011-11-13 to 2011-11-17, 2012-03-25, 2011-11-11 to 2011-11-12, 2012-03-24, 2011-11-12 to 2011-11-13, 2012-03-28
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: -94.750382, E: -92.218705, N: 46.375048, S: 44.187094
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.)
Model (digital)
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?
Yes
4.2. Approximate percentage of the budget for these data devoted to data management (specify percentage or "unknown"):
Unknown

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):

Lineage Statement:
Data were collected and processed by Fugro Horizons, Inc. and made available on the MN DNR ftp site. The data were downloaded from the MN DNR ftp site by the NOAA Office for Coastal Management (OCM) where the data were processed to make it available for custom download from the NOAA Digital Coast Data Access Viewer (DAV) and for bulk download from AWS S3.

Process Steps:

  • VENDOR PROCESSING STEPS: (See map of block boundaries: ftp://lidar.dnr.state.mn.us/documentation/status/metro_data_delivery_dates.pdf ) 1. Specifications for Blocks A-H (1.5 points/square meter): The settings for the Leica sensor ALS50-II MPiA included acquisition at 6,600' AMT, 130 knots, pulse rate 99,500Hz, scan rate 27.28Hz, 40 degree field of view, 4,805ft swath width, maximum along track spacing (occurs at FOV edge) of 2.45m in overlap areas, maximum cross track spacing (occurs at Nadir) 1.24m, 3sigma post spacing of 1.4m and 3sigma point density of 0.65 points per square meter. This sensor was also equipped with IPAS inertial measuring unit (IMU) and a dual frequency airborne GPS receiver. These settings were used to meet or exceed the following accuracy specification in flat areas with minimal vegetation. 24.5cm ACCz, 95% (12.5cm RMSEz) 29.4cm ACCz, 95% (15.0cm RMSEz) 29.4cm ACCz 95% (15.0cm RMSEz). 2. Specifications for the Dakota Block (2 points/square meter): The settings for the FLI-MAP sensor included acquisition at 2,700' AMT, 145 knots, 30% sidelap, 150kHz, 60% degree field of View, 3,116ft swath to attain an approximate 8 points per square meter. This sensor was also equipped with an inertial measuring unit (IMU) and a dual frequency airborne GPS receiver. These settings were used to meet or exceed the following accuracy specification in flat areas with minimal vegetation. 17.64cm ACCz 95% (9.0cm RMSEz) 24.5cm ACCz 95% (12.5cm RMSEz) 24.5cm ACCz 95% (12.5cm RMSEz). 3. Specifications for the Metro Block and the Maple Grove Block (8 points/square meter): The settings for the FLI-MAP sensor included acquisition at 2,100' AMT, 130 knots, 60% sidelap, 200kHz, 60% degree field of View, 2,424ft swath to attain an approximate 8 points per square meter. This sensor was also equipped with an inertial measuring unit (IMU) and a dual frequency airborne GPS receiver. These settings were used to meet or exceed the following accuracy specification in flat areas with minimal vegetation 17.64cm ACCz 95% (9.0cm RMSEz) 24.5cm ACCz 95% (12.5cm RMSEz) 24.5cm ACCz 95% (12.5cm RMSEz). The data set for each flight line was checked for project area coverage, data gaps between overlapping flight lines, and tension/compression areas (areas where data points are more or less dense that the average project specified post spacing). Using an iterative process that involves analyzing raster difference calculations the omega, phi, kappa angle corrections for the LiDAR instrument were determined. Corrections were applied to the LiDAR data set. Extensive comparisons were made of vertical and horizontal positional differences between points common to two or more LiDAR flight lines. An intensity raster for each flight line was generated and verified that intensity was recorded for each LiDAR point. LiDAR ground points were compared to independently surveyed and positioned ground control points in the project area. Based on the results of these comparisons, the LiDAR data was vertically biased to the ground. PRE-PROCESSING STAGE LiDAR, GPS and IMU data are processed together using LiDAR processing software. The LiDAR data set for each flight line is checked for project area coverage and LiDAR post spacing is checked to ensure it meets project specifications. The LiDAR collected at the calibration area is used to correct the rotational, atmospheric, and vertical elevation differences that are inherent to LiDAR data. Intensity raster is generated to verify that intensity was recorded for each LiDAR point. LiDAR data is transformed to the specified project coordinate system. By utilizing the ground survey data collected at the calibration site and project area, the LiDAR data is vertically biased to the ground. Comparisons between the biased LiDAR data and ground survey data within the project area are evaluated and a final RMSE value is generated to ensure the data meets project specifications.
  • VENDOR DELIVERABLES Deliverables for the LiDAR are in UTM15N NAD83/HARN NAVD88 Geiod09 meters. Each geodatabase is named for its respective USGS quarter-quarter quad name; there is a tiling scheme feature class in the elevation_data file geodatabase. Every geodatabase contains a feature dataset called "terrain_data". The terrain_data feature dataset contains up to two feature classes: Bare_Earth_Points and Hydro_Breaklines (when applicable). The Bare-Earth_Points feature class is comprised of MultipointZ shapefiles extracted from the Ground and KeyPoint LAS files. Both the Bare_Earth_Points and Hydro-Breaklines have been clipped to the USGS quarter-quarter quad extent. Each geodatabase also contains a DEM. The DEM was created from a terrain using bare-earth multipoint PointZ and hydro-breaklines. The Terrain was then converted to a Raster DEM using a 1-meter cell-size, then clipped to an adjusted, quarter-quarter quad minimum-bounding rectangle and buffered an additional 50 meters. The naming convention for all DEMs is "DEM01". LAS files are clipped to the provided USGS quarter-quarter quad. For the higher density blocks (Dakota Block; Metro Block; Maple Grove Block), the vendor tiled the las files further, breaking each standard tile into 16 additional tiles. They are simply appended an A,B,C, or D starting in the upper left and proceeding in a clockwise direction. A sample image ( http://www.mngeo.state.mn.us/chouse/elevation/16tile_naming_convention.jpg ) taken from the tile index map that is on the FTP site, shows a single tile with the sub-block lettering scheme. A sample tile name would be: 4243-02-30_a_a.laz Water edges were created using proprietary processes to create an accurate 3D representation of water features. Further hands-on evaluations are performed to ensure compliance with USGS V13 regarding Hydro-Flattening. Once the waterbodies are finalized, LAS bare-earth points within the extents of the water polygons are classified to Class 9 (Water). Bare-earth points within 1-meter of the water polygons are re-classified to Class 10 (Ignored Class). ADDITIONAL PRODUCTS GENERATED BY MINNESOTA DNR STAFF: These products are in the geodatabase for each of the tiles: 1. Two-foot contours were created by resampling the 1-meter DEM to 3 meters, then smoothing the 3-meter grid using a neighborhood average routine, and then creating contours from this surface using standard ArcGIS processing tools. 2. Building outlines were created by extracting from the LAS files those points with Classification 6 (buildings), then grouping those points within 3 meters of each other into a single cluster and then creating an outline around those points. This was done using standard ArcMap tools. 3. Hillshades were created from the one- and three-meter DEMs using standard ArcMap tools. Azimuth value = 215, Altitude = 45, Z-Factor = 1
  • 2022-12-14 00:00:00 - The NOAA Office for Coastal Management (OCM) downloaded 2324 laz point data files from these MN DNR sites: https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_a_c/ (418 files) https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_b/ (233 files) https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_d/ (599 files) https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_e/ (204 files) https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_f/ (477 files) https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_g/ (129 files) https://resources.gisdata.mn.gov/pub/data/elevation/lidar/projects/metro/block_h/ (264 files) The data were in UTM Zone 15N NAD83 (HARN), meters coordinates and NAVD88 (Geoid09) elevations in meters. The data were classified as: 1 - Unclassified, 2 - Ground, 3 - Low Vegetation, 4 - Medium Vegetation, 5 - High Vegetation, 6 - Buildings, 7 - Low Noise, 8 - Model Key Point, 9 - Water, 10 - Ignored Ground, 11 - Scan Edge, 12 - Overlap, 14 - Bridge Decks. OCM processed all classifications of points to the Digital Coast Data Access Viewer (DAV). Classes available on the DAV are: 1,2,3,4,5,6,7,8,9,10,11,12,14. OCM performed the following processing on the data for Digital Coast storage and provisioning purposes: 1. Internal OCM scripts were run to check the number of points by classification and by flight ID and the gps, elevation, and intensity ranges. 2. Internal OCM scripts were run on the laz files to: a. Convert from orthometric (NAVD88) elevations to NAD83 (2011) ellipsoid elevations using the Geoid09 model b. Convert the laz files from UTM Zone 15N NAD83 (HARN) meters coordinates to geographic coordinates c. Assign the geokeys, sort the data by gps time and zip the data to database.
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.7. Data collection method(s)
  • 3.1. Responsible Party for Data Management
  • 5.2. Quality control procedures employed
  • 7.1.1. If data are not available or has limitations, has a Waiver been filed?
  • 7.4. Approximate delay between data collection and dissemination
  • 8.3. Approximate delay between data collection and submission to an archive facility
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?
Yes
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:

Data is available online for bulk and custom downloads.

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)
NCEI_CO
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

Data is backed up to tape and to cloud storage.

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