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:
2016 - 2017 IGIC/USGS Lidar: Indiana Central 3 County
1.2. Summary description of the data:

In 2015 the Indiana Geographic Information Council (IGIC) submitted a 3DEP BAA proposal to the USGS in partnership with 3 Indiana Counties (Marion, Hamilton and Wayne) to support the acquisition of new Quality Level 2 Lidar data products. This grant was awarded in 2016 and this project was completed in 2019. This metadata record describes the project-wide aerial lidar data acquired for Hamilton, Marion, and Wayne Counties, IN.

Hamilton County:

These lidar data are processed classified LAS 1.4 files, formatted to 1,936 individual 2,500 ft x 2,500 ft tiles; used to create intensity images, 3D breaklines and hydro-flattened DEMs as necessary. Data collected by Quantum Spatial, Inc.

Geographic Extent: One county in Indiana, covering approximately 434 total square miles.

Dataset Description: The Hamilton County, Indiana 2016 LiDAR project called for the planning, acquisition, processing, and derivative products of lidar data to be collected at a nominal pulse spacing (NPS) of 0.7 meters. Project specifications are based on the U.S. Geological Survey National Geospatial Program Base LiDAR Specification, Version 1.2. The data were developed based on a horizontal projection/datum of NAD83 (2011), Indiana State Plane East, US survey feet and vertical datum of NAVD88 (GEOID12B), US survey feet. LiDAR data were delivered as processed Classified LAS 1.4 files formatted to 1,936 individual 2,500 feet x 2,500 feet tiles, as tiled intensity imagery, and as tiled bare earth DEMs; all tiled to the same 2,500 feet x 2,500 feet schema. Continuous breaklines were produced in Esri file geodatabase format.

Ground Conditions: LiDAR was collected in spring of 2016, while no snow was on the ground and rivers were at or below normal levels. In order to post process the LiDAR data to meet task order specifications and meet ASPRS vertical accuracy guidelines, Quantum Spatial, Inc. utilized a total of 39 ground control points that were used to calibrate the LiDAR to known ground locations established throughout the project area. An additional 53 independent accuracy checkpoints, 32 in Bare Earth and Urban landcovers (32 NVA points), 21 in Tall Weeds categories (21 VVA points), were used to assess the vertical accuracy of the data. These checkpoints were not used to calibrate or post process the data.

Marion County:

Aerial coverage of all of Marion County, which totals approximately 403 Square Miles and a 1 mile buffer collar surrounding the County under USGS Contract No. G16AC00108.

CONTRACTOR: City of Indianapolis and Marion County, IN.

SUBCONTRACTOR: Kucera International, Inc. Lidar data were acquired and calibrated by Kucera International, Inc. All follow-on processing was completed by the subcontractor.

Project Projection, Datums and Units. Projection - State Plane Coordinate System (SPC) Indiana east zone. Horizontal datum - North American Datum of 1983-2011(NAD83-2011(HARN)).

Vertical datum - North American Vertical Datum of 1988 (NAVD88) using the latest geoid (Geoid12A) for converting ellipsoidal heights to orthometric heights.

Measurement units - U.S. Survey Foot. Lidar datasets provided are Classified LAS point cloud, bare earth hydro-flattened DEM, first return surface elevation model (SEM) and hydrologic breaklines.

Wayne County:

Project Area of Interest (AOI) area measures approximately 405 square miles. A tile scheme (5,000 x 5,000 foot) was created for processing activities. Due to flight layout planned in block formation, significant amount of data collected outside of project boundary. Any tiles completely outside of the boundary were not delivered. Data collected by GRW Aerial Surveys, Inc.

Ground conditions: Data collected with leaf off and no snow. All data in NAD83(HARN)/NAVD88, GEOID 96, State Plane Indiana East, US Survey Feet.

System Type and System Collection Parameters: Sensor ID, Gemini-246; Flying Height AGL, 1400 (m); Recommended Ground Speed 120 (kts); Scan Angle, +/-16.0 deg; Laser Pulse Rate used, 70000 Hz; Scan Frequency 43.6 Hz; Full Swath Width, 801.83 (m); Sidelap,50 percent; Point Spacing Across Track, 0.707 (m); Point Spacing Down Track , 0.709 (m); Average Point Density, 2.62 (pts/m^2); Lidar LAS Information: Lidar LAS Version, 1.4; Lidar LAS Point Record Format, 6; Lidar LAS Classification Code 1 unclassified; Lidar LAS Classification Code 2 ground; Lidar LAS Classification Code 7 low noise; Lidar LAS Classification Code 9 water; Lidar LAS Classification Code 10 ignored ground (breakline); Lidar LAS Classification Code 17 bridge; Lidar Classification Code 18 high noise. Data edited October 2017 by USGS National Geospatial Technical Operations Center (NGTOC). Data was modified from the original delivered data by the NGTOC to meet USGS specification and/or facilitate efficient data publication Modifications may include but are not limited to: breakline enforcement, hydro-flattening of water bodies, changing point classification to resolve conspicuous errors in the DEM, removal of certain TIN artifacts, raster file format conversion, spatial reference system transformation, and conversion of GPS Week time to Adjusted GPS time.

This metadata record supports the data entry in the NOAA Digital Coast Data Access Viewer (DAV). For this data set, the DAV is leveraging the Entwine Point Tiles (EPT) hosted by USGS on Amazon Web Services.

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:
2016-03-11 to 2016-03-12, 2016-03-18, 2016-03-21 to 2016-03-22, 2017-03-05 to 2017-04-09
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: -86.383, E: -84.78, N: 40.273, S: 39.609

Bounding area of all three counties

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:
The NOAA Office for Coastal Management (OCM) ingested references to the USGS Entwine Point Tile (EPT) files hosted on Amazon Web Services (AWS) into the Digital Coast Data Access Viewer (DAV). The DAV accesses the point cloud as it resides on AWS under the usgs-lidar-public-container.

Process Steps:

  • 2016-01-01 00:00:00 - For Hamilton County(1/1): LAS Point Classification: The point classification was performed as described below. The bare earth surface was manually reviewed to ensure correct classification on the Class 2 (Ground) points. After the bare-earth surface was finalized, it was then used to generate all hydro-breaklines through heads-up digitization. All ground (ASPRS Class 2) LiDAR data inside of the Lake Pond and Double Line Drain hydro-flattened breaklines were then classified to Water (ASPRS Class 9) using TerraScan macro functionality. A buffer of 1 meter was also used around each hydro-flattened feature to classify these ground (ASPRS Class 2) points to Ignored ground (ASPRS Class 10). All Lake Pond Island and Double Line Drain Island features were checked to ensure that the ground (ASPRS Class 2) points were reclassified to the correct classification after the automated classification was completed. All overlap data was processed through automated functionality provided by TerraScan to classify the overlapping flight line data to approved classes by USGS. The overlap data was classified using standard LAS overlap bit. These classes were created through automated processes only and were not verified for classification accuracy. Due to software limitations within TerraScan, these classes were used to trip the withheld bit within various software packages. All data were manually reviewed and any remaining artifacts removed using functionality provided by TerraScan and TerraModeler. Global Mapper was used as a final check of the bare earth dataset. GeoCue was then used to create the deliverable industry-standard LAS files for both the All Point Cloud Data and the Bare Earth. Quantum Spatial, Inc. proprietary software was used to perform final statistical analysis of the classes in the LAS files, on a per tile level to verify final classification metrics and full LAS header information.
  • 2016-01-01 00:00:00 - For Marion County(1/1): 1. At selected locations throughout the site, accurate GPS coordinates and elevations are surveyed and the points are marked with targets. 2. New LiDAR data is captured for the project area using a Leica ALS70 MPiA 500khz LiDAR sensor with integrated GPS/INS, mounted in a twin engine Piper Navajo aircraft. 3. The airborne GPS data is post-processed in Inertial Explorer 8.6 and TPOS 2.3, then combined with the IMU data in Novatel/Waypoint Inertial Explorer software to determine the LiDAR sensor's angle and orientation in the terrain (project) coordinate system and datums during the survey. 4. The post processed GPS/INS solution is applied to the raw lidar data to orient and project the data points into the project area reference system as an unclassified point cloud. 5. The georeferenced lidar data is then classified and edited in Terrasolid Terrascan software. Data is classified to produce: Class 1: unclassified points, Class 2: ground points, Class 7: low points, Class 9: water points, Class 10: ignored ground points, Class 17: bridge deck points, Class 18: high noise points, and overlap bit Class O1: overlap unclassified points, Class O2: overlap ground points. 6. The ground class of the processed lidar data is then compared to the ground control and elevation differences between the lidar surface and surveyed elevation are recorded in tabular form. Vertical accuracy statistics are then developed to produce vertical RMSE and overall accuracy estimates and reports. 7. After vertical accuracy evaluation the classified lidar data is exported as 5000 X 5000 foot tiles in the LAS format with any or all classes required to produce derivative products.
  • 2018-05-08 00:00:00 - For Wayne County(1/2): Base Stations: All LiDAR collected in conjunction with GPS CORS base stations occupying multiple points simultaneously. The guidelines specified in USGS publication: LiDAR Base Specification; Chapter 4 of Section B; U.S. Geological Survey Standards; Book 11, Collection and Delineation of Spatial Data were followed as much as possible in data collection and processing of data for primary project control stations. In addition, all other usable static GNSS data collected during this survey campaign were incorporated in the OPUS Projects solution. GPS CORS base stations were used for LiDAR ABGPS/IMU data processing. The primary project control positions derived from OPUS-Projects were used for the base stations in the LiDAR processing. Static GNSS data for most of the LiDAR calibration and truing (validation) points was processed using TBC (Trimble Business Center) radially from the primary project control stations. In areas where tree canopy prohibited collection of static GNSS data at validation points, a pair of points were set for use as conventional (total station) survey control points. The conventional data collected was processed into coordinates using TBC. Calibration Procedures: A system calibration of LiDAR sensor and Inertial Measurement Unit (IMU) was performed before beginning data acquisition for project. This was done to correct for any misalignment errors between the sensor and the IMU, as well as any ranging errors within the sensor itself. Before collection of LiDAR, weather conditions were checked to reduce re-flights as a result of clouds, fog, or other issues, and GPS satellite constellation was checked to ensure reliable positional data. No data was collected if PDOP values were above 4. The LiDAR data was reviewed to verify that there was no gap in coverage, as well as verifying adequate point density and point spacing was maintained throughout the project area. After LiDAR data arrived from the field, and copied to the network, then the airborne was processed using Inertial Explorer. GNSS/IMU data was processed, differentially corrected, and its integrity verified. During GNSS/IMU processing several graphs were produced. The most important of these graphs were the detailed base station length, PDOP, and separation plots. These graphs were reviewed to determine data quality. Upon receiving survey data from the field the GNSS log sheets were be checked for accuracy, and the raw GNSS data was converted to RINEX and submitted to OPUS. The opus solution quality indicators were used to access the general data quality. If the station has NGS published positions and/or elevations, the OPUS results were compared to published values. Once, quality airborne solution was achieved, then LiDAR points are generated and flightlines calibrated together based on the system calibration in Leica CloudPro. Alignment, range, and intensity issues were also computed and corrected for in the process. CloudPro applied the projection, GPS timestamp, scan angle, roll compensation, and output the LiDAR data in LAS 1.2 format. Final calibration of the data to the surveyed ground control was done using TerraSolid's TerraMatch software. QA/QC of the calibrated dataset included the review of flight line matches through the use of distance's shading imagery generated in the GeoCue software and the inspection of control reports comparing the calibrated vertical position of the LiDAR point cloud to the surveyed ground control in the area. Ground truth validation was used to assess the data quality and consistency over sample areas of the project. To facilitate a confident evaluation, existing survey control was used to validate LiDAR data. Published survey control, where orthometric height (elevation) has been determined by precise differential leveling or GPS observation was deemed to be suitable.
  • 2018-05-08 00:00:00 - For Wayne County (2/2): Lidar Post-Processing: Calibrated and controlled lidar swaths were processed using automatic point classification routines in proprietary software. Routines operate against entire collection (all swaths, all lifts), eliminating character differences between files. Data was then distributed as virtual tiles to experienced lidar analysts for localized automatic classification, manual editing, hydro breakline extraction, and peer-based QC checks. Lakes and Ponds measuring 2 acres or larger, streams 100 feet or wider, were collected as 3D hydrographic breaklines. Points representing bare earth were classified to class 2. Ground points inside of water features were classified to class 9 to represent water and points ground points outside of hydro features but within 2 feet of hydro breaklines were classified to class 10. Points representing bridge decks were classified to class 17. Extreme high points were classified as high noise class 18. Extreme low points were classified as low noise class 7. All remaining points were classified to class 1. Supervisory QC monitoring of work in progress and completed editing ensured consistency of classification character and adherence to project requirements across the entire project. After completion of classification and final QC approval, all deliverable products were produced per SOW. Fully classified LAS data set - All lidar points classified were delivered in tiles based on 5000 x 5000 foot project tile index. Full tiles were given with all points outside of buffered working boundary classified to class 1. All points inside of buffer boundary were classified to one of the following classes: Unclassifed (1), Ground (2), Low Point (7), Water (9), Ignored Ground (10), Bridge Deck (17). High Noise (18). Class 1 was used for points not classified in the other classes. Class 2 was used for points that represent bare-earth. Class 7 was used for points that represent extreme low elevation. Class 9 was used to represent water. Class 10 was used to represent 2 foot buffer area around hydro breaklines to aid in DEM surface creation. Class 17 was used to represent points for bridge decks. Class 18 was used to classify points with extreme high elevations. No points were deleted from the LAS files. Final data set was formatted into Las Version 1.4 with TerraScan version 018.
  • Original point clouds in LAS/LAZ format were restructured as Entwine Point Tiles and stored on Amazon Web Services. The data were re-projected horizontally to WGS84 web mercator (EPSG 3857) and the vertical units were converted to meters, Hamilton County (NAVD88 Geoid12B); Marion County (NAVD88 GEOID 12A); Wayne County (NAVD88 GEOID96).
  • 2023-02-23 00:00:00 - The NOAA Office for Coastal Management (OCM) created references to the Entwine Point Tile (EPT) files that were ingested into the NOAA Digital Coast Data Access Viewer (DAV). No changes were made to the data. The DAV will access the point cloud as it resides on Amazon Web Services (AWS) under the usgs-lidar-public container. These are the AWS URLs being accessed: https://s3-us-west-2.amazonaws.com/usgs-lidar-public/USGS_LPC_IN_Central_Hamilton_2017_LAS_2019/ept.json https://s3-us-west-2.amazonaws.com/usgs-lidar-public/USGS_LPC_IN_Central_MarionCo_2016_LAS_2018/ept.json https://s3-us-west-2.amazonaws.com/usgs-lidar-public/USGS_LPC_IN_Central_Wayne_2016_LAS_2019/ept.json
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.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