Optimizing workflow for FUSION's PolyClipData?

Question

I have multiple large LiDAR datasets (.laz) from different areas, where I need to extract buildings. I have prepared a shapefile containing a buffer around the buildings I care about, and are using the FUSION tool PolyClipData to clip the point clouds.

I am relatively new to working with ALS data and have a couple of questions to hopefully save me some time as I start processing other datasets. My first data set (after having thinned it) is 780 million points, of which about 15 million points are within the buffer zones. It takes my computer more than five hours to use the PolyClipData tool. Is that normal?

I afterwards will create DEM and DTMs using the clipped data set. In the end, all I care about is the height of the buildings and extracting roof shapes.

I have considered a couple of things that might make the tool faster, but unfortunately don't have the time to test them, and I am hoping to get help knowing if and why any of these (or further) solutions might be helpful.

• a) Is it more efficient to have square polygons than rounded polygons to cut the point clouds with?

• b) Is it better to dissolve the polygons into a multipolygon or is it better to have multiple polygons?

• c) Is it faster to creta DEMs and DTM for the entire data set and then cut those using the polygons? I figure that the interpolation will take much longer with more points. But on the other hand, cutting the output raster from the DEM and the DTM should be fast.

• d) I am using .laz files and using the laszip.dll tool to let FUSION work directly on those files. Would I in total save time if I thin my dataset (ThinData) directly into .lda (FUSION native format) or .las?

Answer 1

Use Fusion's LTKProcessor to speed up performance of PolyClipData. It is described in Appendix C from Fusion's manual (emphasis mine):

Using LTKProcessor to Process Data for Large Acquisitions

LTKProcessor is designed to facilitate the application of FUSION-LTK tools to large data acquisitions. It uses multiple data files to create seamless data products covering the entire acquisition area. In operation, LTKProcessor allows you to process data tiles individually, clip new data tiles that optionally include a buffer around the tile, or overlay an analysis grid over the entire acquisition extent. LTKProcessor does not actually process data. Instead, it creates a batch file that directs the processing. ...

As a general rule, processing is much more efficient when the data for an acquisition can be divided into as few tiles as possible. ... LTKProcessor provides several options to help “re-tile” data to make processing more efficient. ,,,

Don't forget to include a buffer zone while clipping. It will avoid the 'edge artifacts' when generating the DEMs, which you will use to normalize the point cloud and then, retrieve their heights.

About your specific questions:

d). Yes, working with .las (instead of .laz) in Fusion would also help saving time, but not saving space (it is a trade off). See what Fusion's manual says about this:

Compressed LAS files (LAZ format) are typically 75-85% smaller than the corresponding LAS format file. However, using LAZ files will be slower than similar operations using LAS files.

---

b). Be aware if you dissolve your polygons you won't be able to take advantage from the shape switch in PolyClipData, which will write the building identifiers in the output filenames.

---

About a) and c), I would guess a is irrelevant in this context, and c I would only generate the full DEM if I'd use it for something else later. I'd prefer to extract heights from buildings directly from the point cloud (i.e, subtracting the DEM from every point, and then computing some statistics from the normalized cloud), rather than subtracting the DEM from the DSM (I think in the former process one will have more control to check errors and decide the most suitable method to compute heights that will represent the entire building).