Normalize height on a LAS catalog stops processing without an error message

Question

I'm using the lidR package 4.0.1 in R to normalize height on a las catalog. I'm using a raster DTM as the elevation source. I have successfully completed this task using the same script and same point cloud and dtm sources (just processing a different area). This time, the normalization process stops mid stream and does not continue. My script is...

library(lidR)
library(raster)
library(rgdal)
library(PROJ)

setwd("E:/MyDIR/Test2")

EPSG6497<- CRS(SRS_string = "EPSG:6497")

#build a LasCatlog object...
NAIP_LAS<- readLAScatalog("E:/MyDIR/Test2")

#assign projection
st_crs(NAIP_LAS)<- EPSG6497

#set some processing options...
opt_chunk_size(NAIP_LAS)<- 1000
opt_chunk_buffer(NAIP_LAS)<- 50
opt_select(NAIP_LAS)<- "xyz"
opt_output_files(NAIP_LAS)<- "E:/MyDIR/Test2/NormalizedLAS/{ID}_Height"

#read in the DTM as a RasterLayer Object here...
dtm<- raster("E:/MyDIR/Test2/TestDEM2.vrt")

#normalize height of the LasCatalog...
normalize_height(NAIP_LAS, dtm)

... From the console, it appears to get hung up and doesn't continue. I've run it for three or more attempts in two different test areas and different numbers of tiles process before it pauses...

Processing [========================================>------------------------------------------]  49% (49/100) eta:  4m

I let this small test area process for a whole day, just to see if it would eventually finish (it did not).

I've run out of ideas for testing why this could be occurring. I have plenty of space on my hard drive (~500GB free), and running this on an HP G4 geoprocessing workstation dual CPU with 18 threads and 96GB RAM.

Has anyone experienced similar behavior when normalizing a las catalog, and if so, how did you resolve it?

Answer 1

lidR package developer here and I have not idea. Impossible to answer without reproducing. The best I can say it to try to reproduce with this chunk only to see if the problem comes from this particular chunk (which is unlikely in my opinion). If it works I have no idea. If it does not, please report a bug.

opt_chunk_size(NAIP_LAS)<- 1000
opt_chunk_buffer(NAIP_LAS)<- 50
opt_select(NAIP_LAS)<- "xyz"
chunks = engine_chunks(NAIP_LAS)
chunk = chunks[[49]]
las = readLAS(chunk)
nlas = normalize_height(las, dtm)

Answer 2

I isolated the extent of the problem chunk (which was actually chunk 50) and wrote a new .las file to test if there was an issue with the geometry of any of the points within the extent of chunk 50 (there was not). Normalizing the height of this new individual tile (chunk 50) using the same DTM worked as expected.

So, I tried re-indexing the las files using lasindex, and re-ran the script in my initial post to normalize the las catalog. This solved the problem and the las catalog normalized as expected.

My issue is apparently resolved, but I do not know why the problem occurred initially (whether it was related to the .las file or the .lax file or something else). Thank you for your input!

Answer 3

I made a LAS catalogue from las files derived from Digital Aerial Photogrammetry. These tiles were originally 1.4 km^2, and the DEM was at a 1 metre pixel size. The hits weren't very dense but it froze as you described. Then I removed poor hits with heights less than zero, but same problem. Then I retiled to 1 km^2 tiles and it worked. It shouldn't have been a memory problem, so retiling for that reason doesn't make sense maybe, but a possible work around.