LIDAR Magazine

LIDAR Best Practices: Part III Initial Office Processing

In the previous installment, we examined the field operations associated with planning and acquiring a LIDAR (and possibly imagery) mission. We place great emphasis on step by step quality checks and the importance of developing and rigorously following written procedures. W. Edwards Demming, the father of modern statistical quality improvement, said (paraphrasing) What cannot be measured cannot be managed nor improved. In the highly competitive environments in which we play today, both management and continuous improvement are essential for business survival.

Initial office processing of data received from the field is usually motivated by one of the following production modes:

1. You are an acquisition through final delivery shop

2. You are an acquisition-only shop who delivers geocoded LIDAR/Imagery data to your customer (who is typically a prime contractor)

3. You are a processing shop who is accepting data from an acquisition provider

If you are in the first two categories, you will be performing full geometric correction of the acquired LIDAR data. If you are in the third category, you will be performing rigorous QC of the geometric quality of the data that has been delivered to you. I will refer, in this article, to the overall phase of geometric correction and QC as the Geometric Segment of production.

There are three general contributors to the solution error in geocoding LIDAR data:

R

Random Error

(1)

C

Platform Calibration Errors

(2)

T

Trajectory Errors

(3)

The random error concerns issues such as laser range error and is generally quite small in high quality LIDAR systems. Platform calibration errors (so-called bore sight errors), for a well engineered system, are systematically stable and are relatively easy to remove either a priori via a careful calibration process or post priori via processing corrections using ground control. This leaves Trajectory Error, the most difficult error with which to deal when geocoding data. It is always best practice to separate calibration error correction from trajectory error correction (since the first is systematic whereas the latter is not).

It is important to process LIDAR data first in groups associated with a cycle of the aircraft positioning sensing system. This it generally a single flight mission (or sortie). The best practice in operations is to start the Position and Orientation System (POS here I use the term in the generic sense) a few minutes prior to initial aircraft movement and shutting down some minutes after becoming stationary following landing. This produces a single, continuous raw trajectory.

In all commercial LIDAR systems being delivered today, the POS is independent of the LIDAR system (in fact, it often acts as the master clock for the LIDAR). Thus the first step in the Geometric Segment (GS) is to process the POS data and verify the quality of the solution. If you are receiving preprocessed trajectories, then insist on receiving the RMS error file along with the trajectory (in fact, receiving all POS processing files and reviewing using the POS manufacturers analysis software is truly the best approach but may not always be possible). These data can be combined in an analysis tools such as TerraScan to provide a visual of the gross quality of the solution (see Figure 1). If you have areas of poor trajectory and do not have ground control in these areas, you will not be able to ensure the geometric accuracy of the processed LIDAR data. If the POS data cannot be reprocessed to an adequate solution in these areas, you will generally want to work with your acquisition division (or contractor) to reacquire the data. This is a painful (and costly conclusion) but we have seen far too many LIDAR processing units spend weeks wrestling with heuristic correction approaches, only to eventually have to make the same reflight decision. Remember, mistakes will happen. The important thing is to recognize them early on and take immediate corrective action.

Figure 1: Color coding of Trajectory accuracy (blue = good, red = bad)

The LIDAR data are geocoded via proprietary software provided by the sensor manufacturer. Basically, the process combines raw range/time data, system geometry, platform calibration and trajectory solution to assign an X, Y, Z to each return pulse.

Following Geocoding, an overall assessment of the fit quality must be performed. This generally uses the same tools that were employed in field checking data (see the previous installment of this article series). When you are satisfied with the general overall solution, it is time to inspect/correct the data in detail. In most cases, the corrections proceed as follows:

1. Obtain the best possible trajectory solution (see above)

2. 2. Ensure that you have a valid calibration solution and add this calibration solution to the proprietary processing software

3. 3. Analyze the data using a rigorous geometric analysis tool such as TerraMatch for relative corrections

4. 4. Again, using a rigorous solution, adjust the data to project control

While the use of techniques such as analyzing flight line overlap (see Figure 2) profiles are very useful for QC checking, it is generally not a good idea to use these sorts of tools in a looping process with the geocoding software (e.g. measure, guess a roll correction, reprocess the data, analyze again). This rapidly becomes a whack a mole situation since the POS error in the project is non-uniform and hence cannot be corrected via global (and usually not even swath local) parameter changes.

Figure 2: Profile view of source flight lines

Once you are fully satisfied with the relative and absolute accuracy of the project, it is time to move into the first phases of data classification. This is the subject of the next installment.

Exit mobile version