Skip to main content
U.S. flag

An official website of the United States government

Lidar Base Specification: Deliverables

By NGP Standards and Specifications

Lidar Base Specification 2024 rev. A

Delivery is required for all ancillary products that support the processing of the lidar dataset including, but not limited to, imagery and all metadata associated with those data. 

Return to LBS Table of Contents

Metadata

Survey Point Delivery

Swath Separation Images

Classified Point Data

Bare-Earth Surface (Raster Digital Elevation Model)

Breaklines

Metadata
  • Product metadata files shall comply with the Federal Geographic Data Committee (FGDC) "Content Standard for Digital Geospatial Metadata" (CSDGM) (FGDC, 1998).
  • Metadata deliverables shall include the following:
    • A survey report detailing the collection of all ground survey data including the following: 
      • Control points used to calibrate and process the lidar and derivative data.
      • Checkpoints used to validate the lidar point data or any derivative product.
    • Lidar Mapping Report (LMR). The LMR shall include a graphic showing flightline vectors by lift, delivery block tiles, and DPA. It will convey, at a glance, the different collection flights covering the delivery block tiles. 
    • The LMR shall also include the following sections:
      • Data Acquisition and Processing including 
        • A brief write-up of the project to include the USGS 3DEP Lidar QL and any additional products and services required as part of the task order.
        • A brief write-up to include any circumstances encountered during acquisition or processing that resulted in data anomalies, such as
          • adverse environmental conditions (for example, heavy smoke, standing snow, flooded land, full leaf-on conditions);
          • information regarding tidal constraints including tide-gauges used, tidal datum, and tidal windows;
          • issues with data collection (for example, lidar sensor problem, ABGNSS interference); 
          • reference to any ancillary files, such as low confidence polygons that are used to delineate data anomalies. 
      • ABGNSS-inertial Processing including:
        • A write-up of the process including processing software used.
        • Comprehensive processing reports with graphics from POSPac, Inertial Explorer, or similar software (these can be provided as appendices and are satisfactory replacements for any of the following items if requested content is contained in those reports).
        • List or graphics of any reference stations used for differential correction.
        • Confirmation of processing reference frame.
        • Graphics of processing interface to show trajectory data and labeled reference stations for each lift. If precise point position used, a graphic of trajectory only. 
        • Graphics of processed plots for each mission/flight/lift to include, at a minimum:
          • forward/reverse separation of trajectory,
          • estimated accuracy of trajectory,
          • and any additional plots that contractor used in the analyses of trajectory quality and believed to be of value. 
      • Point cloud creation including:
        • Summary of original point cloud (LAS) creation software and processes used, to include:
          • version—this can be represented with a screenshot embedded in the document;
          • coordinate reference system (reference frame, projection, units, vertical datum, geoid height model) selected for point output—this can be represented with a screenshot embedded in the document; 
          • and any supporting graphics the contractor believes are of value.
      • Geometric quality including:
        • Write-up of point density/spacing assessment and results for the dataset including which points were tested and the methodology for assessing density/spacing. 
        • Write-up of geometric adjustment to include:
          • a summary of sensor model calibration, boresight process, and subsequent swath adjustment process, and
          • a summary of smooth surface precision and interswath accuracy analyses.
        • Graphics and statistics to support smooth surface precision analyses.
        • Graphics and statistics to support interswath accuracy assessment to include:
          • Swath separation image graphics and write-up of processes and settings used to create these images. Settings to be documented include image GSD, color ramp values, points used, surface algorithm (TIN, point-in-cell, other). This can be documented with a screenshot embedded in the document. 
          • Reporting of other methodologies for assessing interswath and any supporting statistics. 
        • Any additional graphics and statistics the contractor believes may be of value in conveying relative accuracy of the point cloud data.
        • Write-up of process used to confirm withheld bit flag proof-of-performance. For maximum surface height rasters, this will include a write-up of the process and technical overview of these rasters. 
      • Production including:
        • Point-cloud flagging and classification routines to include:
          • software used,
          • process for assigning withheld flag,
          • process for assigning additional classification codes (for example, vegetation by height, segmentation, building classification).
        • Breakline placement methodology and elevation conflation method including:
          • Description of hydrologic features treated with breaklines (for example, area of water body, stream width).
          • Breakline compilation methodology including:
            • software used and whether compilation was manual, semi-automated, or fully automated,
            • elevation conflation method,
            • QA/QC procedures employed to confirm breaklines meet 3DEP requirements,
            • list of any ancillary imagery or data used for breakline compilation including imagery sources and acquisition dates. 
        • Raster production including interpolation method used for bare earth DEM creation and the version of GDAL used to define the raster CRS. 
    • A georeferenced, polygonal representation of the detailed extents of each lidar swath collected, as a GIS layer.  
      • The extents shall represent coverage of the collected flight line swath.  
      • Minimum bounding rectangles are not acceptable.  
      • The boundary will generally follow the overall shape of the swath and shall not be fragmented except in areas where voids are permitted (for example, where caused by waterbodies).  
      • Swath polygon feature shall not include extents of data collected during aircraft transit to or from project area or in turns between flight lines.  
      • Each swath polygon shall be attributed with the following:
        • The lift’s unique ID (string format).  
        • The unique Point Source ID of the swath (string format).  
        • The type of swath (string format): 
          • "Project"
          • "Cross-tie” 
          • “Fill-in" 
          • “Calibration” or
          • “Other” 
        • Start time in adjusted GPS seconds to the nearest integer.
        • End time in adjusted GPS seconds to the nearest integer.
        • Esri polygon shapefile or geodatabase or GeoPackage is required. GeoPackage is preferred.
  • Product metadata (FGDC compliant, XML format metadata).
    • One XML file is required for each of the following deliverable product groups:
      • Classified point data, including the withheld flag proof of performance and Swath Separation Images.  
      • Bare-earth DEMs. 
      • Breaklines. 
      • Any other datasets delivered (digital surface models [DSM], intensity images, height above ground surfaces, and others). 
    • Metadata files for individual data files within a deliverable product group are acceptable but are not required.
    • FGDC-compliant metadata shall pass the USGS Metadata Parser (MP) without errors.
  • A block of lidar-related metadata tags specified by the USGS shall be included in the CSDGM (FGDC, 1998) metadata files for all lidar data deliverables. All tags are required.
  • Tags requiring a numeric value shall not contain text (that is, units) because the required reporting units are defined in the appendix 4. The descriptive template of this lidar metadata block is provided in appendix 4 and a completed example is provided in appendix 3.
Survey Point Delivery
  • Survey Points associated with the project shall be delivered in GeoPackage file format, consistent with the most recent published version of the GeoPackage Encoding Standard (presently OGC GeoPackage Encoding Standard (2021)). See figure 4 for an example. 
    • The GeoPackage will contain all checkpoints utilized to validate the vertical accuracy of the project. Any checkpoints that were not utilized in the verification of the final vertical accuracy assessment are prohibited. 
    • The GeoPackage may also contain all the control points associated with the project.  
    • The GeoPackage shall be in the same CRS as the lidar data. 
    • The CRS information of the GeoPackage shall adhere to all Well-Known Text requirements in the Data Processing and Handling section of this specification, with only the following exceptions: 
    • GDAL version 2.4.1 or later or as otherwise agreed to in advance and specified in the Task Order, shall be used to populate the gpkg_spatial_ref_sys_table of the GeoPackage as defined in OGC GeoPackage Encoding Standard (2021). 
    • The point features within the GeoPackage shall be Z-enabled. 
    • The name of the GeoPackage shall contain only the USGS defined name of a project appended with “_Survey_Points” (for example, FL_Everglades_2020_D20_Survey_Points). 
    • The GeoPackage shall possess the following minimum attribution: 
      • unique_identifier (Text format) – Unique identifier that distinguishes the specific point from all other points within the file. The identifier shall be  consistent with associated survey reports and images. 
      • point_type (Text format limited to 10 characters in length) – populated with one of the following values: 
        • NVA 
        • VVA 
        • Control 
        • BVA (Bathymetry vertical accuracy checkpoint) 
      • comment (Text format) – May be null or empty. This field is for additional information the producer wishes to include regarding a specified point (for example, “bathymetry checkpoint at the edge of a waterbody.”) 
      • collection_date – (Date format) The specific date the point was surveyed expressed as yyyy-mm-dd.  
      • source_geoid – (Text format) The source geoid.  
      • source_horizontal_epsg – (Integer format) The source horizontal epsg.  
      • source_horizontal_unit – (Text format) The source horizontal unit of measurement.  
        • meter 
        • metre (provided as an option to keep the unit of measure consistent with possible versions of the WKT associated with the GeoPackage) 
        • U.S. Survey Feet 
        • International Feet 
      • source_vertical_epsg – (Integer format) The source vertical epsg. 
      • source_vertical_unit – (Text format) The source vertical unit of measurement.  
      • source_easting – (Real format) The source easting coordinate, not to exceed three decimal places in precision. 
      • source_northing – (Real format) The source northing coordinate, not to exceed three decimal places in precision. 
      • source_elevation – (Real format) The source elevation, not to exceed three decimal places in precision. 
      • project_id – numerical value of project assigned by USGS (previously referred to as the work package identification for a project). 
      • accuracy - (Real format) The accuracy of the survey point.
Swath Separation Images

Description: Swath separation images (figure 4) use color-coding to illustrate differences in elevation (z-) values where swaths overlap. The color-coded images are semi-transparent and overlay the lidar intensity image. They are ancillary metadata used as visual aids to more easily identify regions within point cloud datasets that may have suspect interswath alignment or other geometric issues. These images may be produced by a variety of methods; however, their usefulness will be ensured by following the specification requirements and documenting the processes used to create the images in the lidar acquisition and processing report.  

  • Image creation:
    • All returns, single returns, or last returns shall be used to create the images.
    • All point classes and flags shall be enabled when creating the images and points flagged as withheld or classified as noise shall be excluded.  
    • Elevation values and differences shall not be subjected to a threshold or otherwise clipped so all differences are represented. 
    • The images will be derived from TINs to reduce the number of false difference values on slopes; however, other algorithms are acceptable. 
    • The images shall consist of a 50 percent transparent RGB layer overlaying the lidar intensity image.  
    • The images shall use at least three color levels wherever two or more swaths overlap within a pixel. 
    • Where two or more swaths overlap within a pixel (based on point source ID),  
      • pixel color shall be based on vertical difference of swaths using the following breaks (based on multiples of the Swath Overlap Difference for the QL, table 2). 
        • For QL1 or QL2 data the breaks are:
          • 0-8 cm: GREEN; 
          • 8-16 cm: YELLOW; 
          • > 16 cm or > last additional color ramp bin value: RED (for example, addition of ORANGE pixels for the range of 16-24 cm would require red pixels to represent > 24 cm).
        • For QL0 data the breaks are:
          • 0-4 cm: GREEN; 
          • 4-8 cm: YELLOW; 
          • > 8 cm or > last additional color ramp bin value: RED (for example, addition of ORANGE pixels for the range of 8-12 cm would require red pixels to represent > 12 cm).
      • color choice of GREEN, YELLOW, and RED is suggested but not required.
      • no pixel shall remain uncolored (transparent) in the overlap areas.
    • Where swaths do not overlap, pixel values shall be intensity alone.
  • Image file formats and version control: 
    • Swath difference image format shall be delivered as GeoTIFF or JPEG (with world file) by tile. 
    • The point cloud geometry and intensity data delivered shall be identical to the point cloud geometry and intensity data used to create the difference images. Changes in the point cloud geometry or intensity requires recreation of the difference images.  
  • Spatial extent and coordinate reference system: 
    • Spatial resolution (pixel dimension) of the images shall be twice (2x) the bare-earth DEM deliverable cell size in the project’s linear unit (meters or feet).  
    • The difference images must be representative of the associated data delivery.
    • The images shall be in the same CRS as the point cloud data to ensure alignment with the point cloud.
Classified Point Data
  • Classified point data deliverables shall include or conform to the following procedures and specifications:
  • All project swaths, returns, and collected points shall be fully calibrated, adjusted to ground, classified, and segmented into tiles. Project swaths exclude calibration swaths, crossties, and other swaths not used, and not intended to be used, for product generation. 
  • LAS Specification version 1.4, PDRF 6, 7, 8, 9, or 10.
  • Delivery in LAZ format: 
    • All LAS files shall be delivered in compressed LAZ format (Isenburg, 2019; Rapidlasso GmbH, 2022). 
    • LAZ 1.4 format shall be used. 
    • LAZ 1.4 files compressed in "compatibility mode" shall not be used. 
  • Withheld bit flag set as appropriate. 
  • Correct and properly formatted georeference informa­tion as WKT (OGC, 2001) included in all LAS file headers. 
  • GPS times recorded as Adjusted GPS Time at a precision sufficient to allow unique timestamps for each pulse. 
  • Intensity values, linearly scaled to 16 bits. See LAS specification version 1.4–R15 (ASPRS, 2011) for additional information.   
  • Tiled delivery, without overlap, using the project tiling scheme. 
  • Classification, as defined in table 5, at a minimum. 
Bare-Earth Surface (Raster Digital Elevation Model)

Delivery of a hydroflattened bare-earth topographic DEM is a requirement for all USGS–NGP lidar projects. Specific research projects may be exempt from some or all these requirements.

  • Bare-earth surface deliverables shall include or conform to the following procedures and specifications:
    • Bare-earth DEM, generated to the limits of the DPA. 
    • All ground-classified points not flagged as withheld shall be used in the creation of the bare-earth DEM.
    • DEM resolution as shown in the table 6. 
    • 32-bit floating-point GeoTIFF raster format.
    • The NODATA value of '-999999' shall be defined in GDAL_NODATA tag #42113.
    • GDAL version 2.4.1 or later or as otherwise agreed to in advance and specified in the Task Order, shall be used to populate GeoTIFF keys and tags.
    • Additional requirements for GeoTIFF tiling, compression, and internal overviews may be referenced in Task Orders.
    • DEM data shall be in the same CRS as the lidar data. 
    • Georeference information in or accompanying each raster file, as appropriate for the file format. This information shall include both horizontal and vertical systems; the vertical system name shall include the geoid model used to convert from ellipsoid heights to orthometric heights. 
    • Tiled delivery without overlap. 
    • DEM tiles with no edge artifacts or mismatch. A quilted appearance in the overall DEM surface will be cause for rejection of the entire DEM deliverable, whether the variations are caused by differences in processing quality or character among tiles, swaths, lifts, or other artificial divisions. 
    • Void areas coded using a NODATA value of ‘-999999’ and shall be defined in GDAL_NODATA tag #42113.
    • Hydroflattening as outlined in the “HydroFlattening” section. Depressions (sinks), whether natural or man-made, are not to be filled (as in hydroconditioning). The methodology used for hydroflattening is at the discretion of the data producer (refer to appendix 2 for more information on hydro-flattening). 
    • Bridges removed from the surface (refer to the “Glossary” section for the definition of “bridge”). 
    • Road or other travel ways over culverts remain intact in the surface (refer to the “Glossary” section for the definition of a culvert). 
    • A report on the assessed absolute vertical accuracy of the bare-earth surface in accordance with the guidelines set forth in ASPRS (2023). Absolute vertical accuracy requirements using the ASPRS methodology for the bare-earth DEM are listed in table 4. 
    • QA/QC analysis materials used in the assessment of absolute accuracy. 
Breaklines 
  • Delivery of all breaklines collected on or used in support of the project is required for USGS–NGP lidar projects. This includes breaklines used for bridge and saddle treatments and any additional breaklines required by project cooperators.
  • Breaklines representing all hydroflattened features in a project, regardless of the method used for hydroflattening, are required for USGS–NGP lidar projects. Specific research projects may be exempt from these requirements with prior approval of the USGS–NGP.
  • Work unit breaklines shall be delivered in the GeoPackage (GPKG) file format with the following requirements:
    • The GPKG will use the most recent published version of the GeoPackage Encoding Standard (presently OGC GeoPackage Encoding Standard (2021)). A blank template will be provided.    
    • The GPKG will include all breaklines used to generate DEM products.
    • Streams and rivers, as defined in the hydroflattening section of this specification, shall contain a centerline with z-values corresponding to the hydroflattened surface.
    • The GPKG shall be in the same CRS as the lidar point cloud data. 
    • The CRS information of the GPKG shall adhere to all the Well-Known Text requirements in the Data Processing and Handling section of this specification, with only the following exceptions: 
      • The CRS information shall be recorded in the gpkg_spatial_ref_sys_table as defined in OGC GeoPackage Encoding Standard (2021).   
      • The GPKG shall contain a single CRS entry. 
    • The name of the GPKG shall contain only the USGS defined name of the work unit appended with “_Breaklines”; for example, FL_Everglades_2009_1_Breaklines. 
    • The GPKG shall have the following minimum attribution: 
      • unique_identifier (Text format) – Unique identifier that distinguishes the specific feature from all other features within the file. 
    • The GPKG will contain up to six layers. 
      • Waterbodies (polygon) 
      • Rivers (polygon)  
      • Centerline (line)  
      • Ocean (polygon)  
      • Other Breaklines Lines (line) 
      • Other Breaklines Polygons (polygon)
    • If the project or work unit does not require one of the layers, such as Ocean, the contractors will not need to supply that layer. 
    • Other Breaklines Lines: used for bridges, buildings, dams, waterfall, for example. 
    • Other Breaklines Polygons: used for islands (unless depicted as holes within water polygons), bridges, buildings, dams, waterfalls, for example. 
    • All features shall be Z- and M-value enabled.