Note: when using to_raster instead of to_raster_tin, it usually goes a bit further but eventualy also crash. I noticed that all cpus are used at 100%, which is probably not good as I can't even log on my machine from another terminal..

hi @flemmens

I think the problem in your case will be that you run out of memory and the pdal_wrench process gets killed. By default, pdal_wrench runs as computation in multiple threads - as many as the number of logical CPUs. The raster export via TIN is quite memory intensive, so try limiting the number of threads with e.g. --threads 4 command line option and see if that helps.

Bigtiff should not be a problem - the raster creation is done by GDAL which will use bigtiff automatically if needed.

As for to_raster also crashing, that can be a different problem. A backtrace of the crash would help...

Thank you for your reply @wonder-sk, I was not aware about this --threads option.

I made a new test with a small VLC of 219 laz files (24Gb) and ran the process on a 96Gb RAM computer with 48 cores using only 4 threads.

The process last a lot longer but finaly crashes at 30%, so it still does not work. However, the subtiles created in the temporary directory are OK, I was able to join them using gdal and got a GeoTIFF of about 1/3 of my terrain.

All the .laz used for the test have been checked, I can process them with a classic pdal pipeline without having any issue. If you wish do the test by yourself I can provide a S3 link with the files.