Version 56 (modified by mark1, 12 years ago) (diff) |
---|
LIDAR QC Procedure
As it stands this is the Lidar data QC procedure. This could be improved and added to as time allows.
Check overlap of neighbouring lines
Horizontal
The first thing to do here is to load up all lines into a viewer (or if runs out of memory load them up in pairs) and see how well they overlap in the horizontal plane. Use Lag with "Brightness by Intensity". If you have trouble making out the details in the lidar viewer then you can make tiffs of the flightlines with lidar_intensity.sh.
Check along features that cross between flight lines, for example, roads/field boundaries/hedgerows do they continue unbroken or are they offset between flight lines. Also, compare against the vectors (if available) for any gross offsets.
Vertical
The elevation between neighbouring flight lines must be checked. There is currently a roll-issue with the lidar data, which in particular needs to be looked for (This page may be helpful). Elevation discrepancies can be found in various ways:
- examining profiles over the overlapping regions: allows measurements of the height difference to be made (in Terrascan/Microstation)
- Re-order points in Terrascan: reorder 'by elevation (Z)' and colour by flightline. This will ideally show a mix of colours in the overlap region. If only one solid colour is shown then this flightline is consistently higher than the the other.
Make a note of the average elevation offsets between flight lines for use in the delivery read me file.
If the elevations are offset consistently between flight lines then this probably means an error with the calibration values (boresight or range correction). This should be corrected using the settings in alspp. If the offsets are random per flight line then the average offset per flight line should be noted but not corrected for (unless ground control points are available).
Check against OS vector maps
If not done in the above step then the flight lines must be checked against vectors (if available).
To check in Envi: Create ascii versions of the las files with las2txt.sh <las_dir> --parse txyzicrna (may not work with LAS 1.1) and then make an intensity mosaic with lidar_intensity.sh Instructions Here?
To check in Terrascan: You need to convert the .shp vectors into .dgn. Instructions here
Classify noisy points
Using Macros
The final stage of the QC is to check the data and reclassify erroneous points to class 7 (low points). This can be done in Microstation/TerraSolid by creating a macro, or using a (in-progress) program classify_las.
Microstation method
Start Microstation and goto Utilities -> MDL Applications -> Terrascan
In Terrascan goto Tools -> Macro
Press Add to add routines to the Macro.
- Change all classes to default class (Action: Classify Points, Routine: by class)
- Classify groups of low points (Action: Classify Points, Routine: low points)
- Classify single low points (Action: Classify Points, Routine: low points)
- Classify isolated points (Action: Classify Points, Routine: isolated points)
To run on large projects use "selected files" instead of reading all LAS files into memory. Ensure that the output format under 'Save As:' is .LAS 1.0.
Check the result (using profiles of various thicknesses) to see what points have been classified using the macro. There may be points which were missed or wrongly classified by the classification algorithms. If there are many points that are wrong you may need to edit the macro (increasing the 'low point' threshold from 0.5m to 2m sometimes yields better results for instance).
To remove haze layers, use elevation to threshold (Routine: by absolute elevation). Select an elevation range whose minimum is well above any ground targets and maximum above the haze layer.
Classifying by Hand
This should be done sparingly due to time constraints but can be acomplished using lag.
With processing and QC complete, you should now begin preparing the project for delivery.