Last month, I posted an article for LiDAR News that focused on Quality Control of different types of LiDAR data. I wanted to delve a bit deeper into the airborne LiDAR quality control discussion. This article will pick up where we left off and provide some more detail into what needs to be checked and how this can be accomplished.
Most LiDAR specifications detail the data collection, processing and delivery formats, which makes it easy to develop a plan of attack for the project. However, the execution of this plan can be hampered by improper scheduling, unexpected delays, weather events and other uncontrollable events. For example, the winter of 2012 had some of the worst precipitation events in recorded history that contradicted itself with a drought riddled summer. This was enough to stall many data collection projects throughout regions of the US, thus putting these projects at risk from a scheduling and data quality perspective.
When events such as these happen, it is imperative to make sure that both the consultant and the client are communicating effectively. When things get behind schedule we all know the first item that is eliminated from the process QA/QC. This ultimately leads to rushed deliverables, time-consuming data reviews and ultimately, re-processing of the data set. Each iteration of the QA/QC process has the tendency to cause confusion between data deliveries, inconsistencies in the data product and ultimately, lack of confidence in the final delivered data set.
The final QA/QC methodology should be discussed between the consultant and the client and both should use the same tools and resources to conduct the quality review check of the data. For example, if a client is taking the final DTM data into ArcHydro to model a stormwater basin, then the consultant needs to be able to do the same analysis before delivering the final data set. By creating a level playing field where expectations are in check between the client and the consultant, the more likely it is a project will achieve success with a minimal amount of re-work required.
The most important items to check include:
Average Point Density across the project
Relative (flight line to flight line) accuracies this should be half of the stated RMSE for the project (e.g. 5cm for a 9.25cm RMSEz spec or 7.5cm for a 15cm RMSEz spec.)
Absolute (overall project) accuracies against ground control. Ground control should be on a hard surface and un-obscured and is typically tested to a 95% absolute accuracy specification). A minimum of 20 points is required, since one point out of 20 will get you to the 95% specification. Larger areas can require significantly more control.
Data classifications (e.g. Ground, Vegetation, Overlap Points, Low Point/Noise, etc.) as per the project specifications (ASPRS or USGS publishes these specifications).
Check terrain edits (look for berms that are removed, building points in ground, low point noise and other anomalous data in the wrong classes).
Projection information in the LAS file header.
Verify Intensity TIFFs as per user-specified requirements.
If breaklines are required, check the following:
o Water bodies meet minimum size criteria,
o Interior points classified to water class, and
o Client-specified buffers around these features
o Single drains (streams) meet minimum length and width requirements and are buffered as per client specifications.
o Double-line drains (Rivers) are monotonic (perpendicular elevations to remove leaning) and are buffered as per client specifications.
o For all breaklines check elevations are at or slightly below terrain for a sampling of tiles for the project (typically 10% of project).
Review the survey report
Flightline trajectories with appropriate metadata, flight logs, and other raw data collection activities (GPS, inertial, etc).
Metadata for all project deliverables (this can be automated with a metadata parser).
In conclusion, it is imperative to conduct QA/QC on all project deliverables. This requires close communication between the client and the consultant to ensure that the QA/QC procedure is documented and implemented in the same manner by both parties. This will ensure project success in spite of changing project timelines and other uncontrollable circumstances encountered through the process.