Changes between Version 41 and Version 42 of Processing/Lidarqcprocedure

Timestamp:

May 19, 2010, 12:43:57 PM (15 years ago)

Author:

knpa

Comment:

--

Processing/Lidarqcprocedure

@@ -7 +7 @@
 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. The Fugro viewer is probably best for this because it also allows Shapefiles to be read in (though you can also just use Terrascan with "Colour by intensity").
+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 too. There is currently a roll-issue with the lidar data, which in particular needs to be looked for. Elevation discrepencies 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 an ascii with las2txt.sh --parse txyzicra (may not work with LAS 1.1) and then an intensity image with make_lidardem_or_intensity.sh [wiki:Processing/CreateTifs Instructions Here]
+
+To check in Terrascan: You need to convert the .shp vectors into .dgn. Instructions [wiki:Processing/shapesintoterrascan here]
+
 === Reclassify noisy points ===
 
@@ -12 +36 @@
 '''Using Macros'''
 
-The first 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. It should be straightforward to script this into a GIS such as GRASS too.
+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 [wiki:Processing/LidarClassification classify_las].
 
 Start Microstation and goto Utilities -> MDL Applications -> Terrascan[[BR]]
@@ -26 +50 @@
 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.
-
-
-=== 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. The Fugro viewer is probably best for this because it also allows Shapefiles to be read in (though you can also just use Terrascan with "Colour by intensity").
-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 too.  This can be done 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 (although you may have already corrected for roll previously). 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 an ascii with las2txt.sh --parse txyzicra (may not work with LAS 1.1) and then an intensity image with make_lidardem_or_intensity.sh [wiki:Processing/CreateTifs Instructions Here]
-
-To check in Terrascan: You need to convert the .shp vectors into .dgn. Instructions [wiki:Processing/shapesintoterrascan here]