Throughout the years I have seen many projects advertised, awarded, executed and then delivered to the client. The client receives the data, copies it locally and then final payment is made to the vendor and life goes on as usual. Then, someone actually checks the data and notices that there are many discrepancies associated with the scope of work and what was actually delivered. How does this happen and more importantly, how can it be avoided?
Step 1 Start with a Clear Scope of Work
The scope should define exactly what is going to be collected, how it will be collected and how it will be verified and checked after delivery. For example, a simple LiDAR scope must define the target point densities (LiDAR), hydro-flattening parameters, and accuracies (absolute and relative) for the project. The scope should also define how the client will be checking the data for final acceptance of the deliverables.
Step 2 Process a Pilot Area
The pilot area should be representative of the overall project and should be processed and delivered as if it was its own project. This allows for the team to identify any processing issues or special techniques up-front so that the rest of the project can move forward in a linear fashion, thus limiting the re-visiting of the data to fix problems at a later date. Once the pilot area is delivered, it should be checked against the scope of work to ensure that all deliverables are being met in accordance with the clients expectations.
Step 3 Process the Entire Project
Final processing can occur once the pilot area is collected and accepted. This is a critical-path item that is the bulk of the projects budget. Many projects will either be successful or turn into a disaster during this phase. The risk is easily mitigated, though, as long as the first two steps of this process are in place and properly executed by the team. This is highly dependent on communication between the vendor and the client. If these channels are established, the project will most likely run smoothly since everyone is on the same page.
Step 4 Data Validation and QA/QC
This is where the overall success of a project is either validated or issues are identified that must be resolved before final delivery is accepted. The processes for checking these data sets are specific for different type of deliverables we will focus on some niche market deliverables and give examples of how to check their associated data elements.
LiDAR QA/QC
First off make sure you have some kind of software that can open this data. Seems simple, but many clients do not have the most rudimentary piece of the puzzle LiDAR viewing software. There are many commercial-off-the-shelf (COTS) products that can be used and each one has its strengths and weaknesses. The goal is to be able to load the entire project in one place and then use the tools within the software to verify the deliverables. 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 important to check your data immediately upon receipt, so that all quality control and quality assurance activities can be performed and verified while the data is still relevant. Good luck!