16.0 DELIVERABLES AND DOCUMENTATION
Print Friendly, PDF & Email

16.1    Minimum required

The following are the recommended minimum required categories of project deliverables and supporting documentation. In general, the intent is not to specify procedure, but rather to establish that the desired results have been achieved as prescribed by the transportation agency for each specific project. Clear documentation of the quality and lineage of the project data will maximize the return on investment and encourage its proper use for multiple applications.

1.   Quality management report

A written Quality Management Plan (QMP), which covers both quality assurance and quality control should be submitted and approved prior to the start of a project. For these Guidelines, quality assurance refers to the planning of tasks to manage overall quality on the project and quality control to the actual quality procedures and checks performed at each stage of the project. The QMP should address all phases of the project including overall safety, data acquisition (including vehicle operating speed), data processing and final deliverables.

2.   Interim memorandums\ progress reports

For long duration and large projects, interim progress reports can enable efficient communication and resolve potential problems early. Periodic teleconferences can be effective to improve understanding between the needs of the transportation agency and the capabilities of the data provider.

3.   Notification of unusual circumstances

If any abnormal issues – not covered in the scope of work are encountered during the data acquisition phase the transportation agency should be notified immediately. In addition, these should be noted and a report prepared explaining the details along with any corrective action that was taken.

4.   Survey narrative report

The surveyor in charge should prepare a Survey Narrative Report containing, at a minimum the following information for the subject project:

  • Project name and location identifier
  • Survey date, time, weather conditions, limits and purpose
  • Project datum, epoch and units
  • Horizontal Time-Dependent Positioning (HTDP) parameters, if used.
  • System calibration report
  • Survey control points found, held and set (see Control Survey Report)
  • Personnel, equipment, and surveying methodology employed
  • Problems encountered, if any
  • Other supporting survey information such as GNSS observation logs
  • Dated signature and seal (if licensure is required) of the surveyor\engineer in charge

5.   Control survey report

For those applications that require the use of higher order survey control networks mobile LIDAR data must be traceable back to the published primary control. This data lineage must be clearly defined and documented in the Control Survey Report such that an independent 3rd party could duplicate the results. At a minimum the Report should contain information on:

  • Primary control held or established
  • Project control held or established
  • Local transformation points
  • Validation points
  • Adjustment report for control and validation points
  • Base station observation logs (occupation data, obstruction diagram, atmospheric conditions, etc.)
  • GNSS accuracy report with details on time, duration, and location of loss of signal lock
  • GNSS satellite visibility and PDOP reports
  • IMU accuracy report
  • Trajectory reports including locations of loss of signal lock exceeding a specified threshold (typically 60 seconds) and operating speeds during acquisition.
  • Results of comparisons between validation points and MLS point cloud to assure that contracted project specifications have been met
  • A continuous, color-coded point density map with summary statistics for objects of interest and for the entire project area.

6.   Data processing documentation

Each step in the post processing of the acquired data must be documented in sufficient detail to allow an independent, 3rd party to reproduce the results. This will add to the data lineage established in the field such that the final deliverable can be traced back to the primary control, for those applications that require this level of accuracy.

At a minimum, the following documentation for the data processing should be provided:

  • Trajectory analysis and QC
  • Adjustment Report
  • Registration Report
  • System Calibration Report

7.   Trajectory

The trajectories for each MLS pass should be provided in a common format such as a kmz or shp.  The trajectory should also include a field with the modeled error estimates throughout the trajectory.

8.   Point Cloud

A geo-referenced point cloud should always be delivered as part of the project.  Here, this is defined as a point cloud that was obtained using the optimum navigation trajectory of the vehicle, and that has had each MLS pass shifted via rigid body translation to fit local transformation points for the project.  For some applications, classifications for the points may be a necessary deliverable. Classified data can be used to generate digital terrain and other surface models that can be used for visualization and analysis such as drainage studies and volumetrics. The actual classification process requires extensive knowledge and experience. Desired classification types and categories should be decided early in the project. ASPRS publishes standard classification types for LAS files (see Table 17 in Appendix E), and these should be used whenever possible. This can simplify the use of the data especially for those who are not experienced in working with point clouds.

9.   Modeled Data

The modeling of the registered point cloud in order to produce a specific type of data and file format is dependent on the end user application.  Engineering design and construction applications will typically require that features be extracted from the point cloud and modeled as 3D CAD, GIS, or BIM objects that conform to a specific transportation agency’s graphics standards. This requires the most time and expertise on the part of the modeler.

Deliverables such as digital terrain models (see section 12.5), signage, and structures will need to be modeled with the end use in mind. The data must be modeled so as to be in a format and file size that is suitable for use with COTS software applications currently used by the transportation agenciess that may have file size and data density limitations. This may include CAD, BIM, GIS, and other asset management systems. Full documentation should be provided for the modeling procedures and QC of the modeling results.  In many cases, model reduction techniques can be applied to reduce data density while still preserving accuracy by removing redundant data (e.g., only a few points are needed to define a planar surface).  The statement of work should be very clear with respect to modeling requirements including file size limitations, desired data density, and if optimization procedures need to be completed.

10. Associated Imagery

In addition to the laser scanner(s) many mobile LIDAR systems will also include cameras and/or video recording sensors. This imagery can be geo-referenced to the point cloud providing valuable real world visual reference. The feature extraction process can be streamlined when the modeler has access to both the imagery and the point cloud for the same scene.

The digital video and/or photo mosaic files should be supplied in a common format. For the photos these would typically be TIFF, JPEG or PNG and for videos as AVI or MOV with a common, near-lossless compression codec (if used). The camera calibration report (interior orientation) and image geo-referencing information (exterior orientation) should also be provided for all cameras and images provided.

11. Metadata Files

Each project file must be accompanied by a geospatial metadata file containing project related data as defined by the transportation agency. By accessing the accompanying metadata end users will be able to quickly determine whether the data and its lineage is appropriate for their application and/or intended use.

12. Final Project Report

Upon completion of the work a Final Project Report will be submitted. This should include all of the final deliverables and the associated required documentation.

16.2    Optional

It is not possible to describe all possible deliverables due to the wide variety of applications and workflows. Some additional deliverables that may be of interest include:

  • GNSS data

•RINEX files for the Base Station or any other GNSS control points acquired.

•OPUS (or similar) reports

  • NGS datasheets for control points used in the control network
  • Coverage extents polygon (e.g., a shp or kmz)
  • Documentation on filters used for classification of point cloud data
  • “Raw” Sensor data. During the data acquisition phase, mobile LIDAR data systems will collect and store the data in an internal, sensor -specific format and link the data through time stamps.  Proprietary software (specific to the hardware vendor) is needed to read and transform this data into a point cloud and store in a portable file format such as LAS or ASTM E57.  All of the following should include timestamps.

•Angles, range (ranges for multiple returns), intensity for all returns from each pulse for each scanner or full-waveform data

•GNSS data (RINEX files)

•IMU readings

•Distance meter logs

•Calibration tables

16_Fig13
Figure 13:  Sample deliverable checklist.

Next Section >> Chapter 17: Emerging Technologies