blast2dem produces nodata pixels despite buffer

[Roni Lindholm]

Hi,

We are having problems rendering a raster with blast2dem when using neighboring tiles.

Command:

blast2dem64 -i N5122D2_6.laz -o /code/foo_new.tif -epsg 3067 -step 2 -keep_class 2 -buffered 300 -kill 300 -ncols 500 -nrows 500 -ll 507000 6905000 -neighbors N5122D2_3.laz N5122D2_2.laz N5122D2_1.laz N5122D2_5.laz N5122D2_8.laz N5122D2_9.laz

The command produces a raster with the correct dimensions and origin based on the specified lower-left coordinates. However, the lower-left and lower-right corners contain NoData pixels because the input LAZ tile does not contain points exactly at those corners.

Our understanding is that the -neighbors and -buffered options should address this issue by allowing points from neighboring tiles to be used, so those corner pixels should be populated. Interestingly, running the exact same command with las2dem64 works as expected and the corner pixels are assigned valid values.

Additionally, blast2dem prints the following message:

LASreaderBuffered: adding 48992 buffer points.

which suggests that it is correctly reading and recognizing the neighboring points.

I have also attached an image showing the result. In the image, the point cloud points are visualized as dark brown points, the black line shows the raster extent, and the blue areas represent NoData pixels in the output raster.

The blast2dem / las2dem version is 260505 (government).

Sample LAZ files are available here:
https://github.com/nlsfi/pinta/tree/main/test_data/point_clouds/2025/production_area_1

Is this expected behavior, or are we using some wrong options for blast2dem?

Thanks.

[LAStools - efficient tools for LiDAR processing]

Hi Roni,

we did some tests and can confirm the problem in blast2dem. A quick test has shown that the problem does not occur in las2dem_new. Perhaps this is a solution, at least for the time being.

However, we will also look into the underlying issue and get back to you.

Cheers,

Jochen @rapidlasso

[Roni Lindholm]

Thanks for the quick response and investigation! Indeed, the last2dem/lastdem_new appears to work correctly, so we can use it for the time being. Hopefully, the blast2dem issue can be fixed at some point in a future release.

-Roni

[Jochen Rapidlasso]

Hi Roni, 

the problem is related to the input tiles. We have found that when we generate the tiles ourselves, everything works perfectly:

:: create own tiles
md test
cd test
lastile64 -i ..\N5122B4_?.laz -odir . -tile_size 1200 -merged -olaz
:: test middle file
blast2dem64 -i 504000_6903600.laz -o tmp2.tif -epsg 3067 -step 2 -keep_class 2 -kill 300 -ncols 500 -nrows 500 ^
 -ll 504000 6903600 -false
:: no edge artifacts - all OK

:: test other files
blast2dem64 -i 502800_6904800.laz  -o tmp2.tif -epsg 3067 -step 2 -keep_class 2 -kill 300 -ncols 500 -nrows 500 ^
 -ll 504000 6903600
:: no edge artifacts

not even the "-neighbors" argument is necessary (but possible).
So we went back to the original files and did a check:

lasinfo64 -i "504000_6904800.laz"
lasinfo64 -i "N5122B4_6.laz"

In the latest version of laslook we can visually compare console outputs (pin the first output, then press the "compare" arrows):



Your input files are not created using LAStools. Therefore there is no tiling and no boundary information available (LAStiling content of lasinfo).
Without tiling information it is not possible to do the tiling operations and optimizations within blas2dem.
The solution to your problem is to retile your files using lastile if you want to use the framing options in tools such as blast2dem.

Cheers,

Jochen @rapidlasso

[Roni Lindholm]

Hi,

Thanks for the extensive debugging!

You're right that the tiles are generated with PDAL, that was also my initial thought, that blast2dem can't read neighbors from PDAL-generated tiles. However, seeing lines like "LASreaderBuffered: adding 15508 buffer points" was making me think that blast2dem was reading the neighboring points correctly.

I've created a new tiled dataset, and I can still see the same behavior where raster edges get assigned a NoData value. You can find the new dataset here: https://github.com/nlsfi/pinta/tree/tiled-test-data/test_data/point_clouds/tiled and the blast2dem command used is below (the 5th tile is the middle one from the 9-tile grid):

blast2dem64 -i N4433G1_5.laz -o dem.tif -epsg 3067 -step 2 -keep_class 2 -buffered 300 -kill 300 -ncols 500 -nrows 500 -ll 495000 6907000 -neighbors N4433G1_1.laz N4433G1_2.laz N4433G1_3.laz N4433G1_4.laz N4433G1_6.laz N4433G1_7.laz N4433G1_8.laz N4433G1_9.laz

lasinfo now outputs the following for the new input file:

LAStiling (idx 12, lvl 2, sub 0, bbox 493000 6905000 497000 6909000) (size 1000 x 1000, buffer 0)

The dataset was created by tiling, thinning, and indexing using the following commands:

lastile64 -i N4433G1.laz -olaz -odir <output dir>
lasthin64 -i <input dir>/*.laz -odir <output dir> -olaz -keep_class 2 -adaptive 5 10.0
lasindex64 -i <input dir>/*.laz -append

For reference, las2dem_new64 still works correctly.

P.S. I experienced some connection issues when sending this message, so please ignore it if it comes through as a duplicate.