possible bug in las2las 20250304

[Andrew Ritchie]

I have verified that I can filter a copc laz file with las2las version 20240319 and grid it with lasgrid64 version 20240319 or version 20250304 but if I filter it with las2las version 20250304 I can't grid it with lasgrid64 version 20240319 or 20250304. Interestingly, I can still grid it with lasgrid.exe version 20250304...

I suspect it has to do with treatment of the COPC VLRs but I'm not sure.

To reproduce the issue:

Download:

https://noaa-nos-coastal-lidar-pds.s3.amazonaws.com/laz/geoid18/10196/blk24555/20241029_FEMA_FL_17RLL3237.copc.laz

run:

las2las -i 20241029_FEMA_FL_17RLL3237.copc.laz -drop_extended_class 29 -target_epsg 6346 -elevation_meter -longlat -target_elevation_meter -olaz -o test3.laz

lasgrid64 -i test3.laz -step 1 -elevation_average -otif -o test6.tif -vv

Here's what I get:

C:\Users\aritchie>lasgrid64 -version
LAStools (by in...@rapidlasso.de) version 240319 (non-profit)

C:\Users\aritchie>las2las -i "C:\Users\aritchie\Downloads\20241029_FEMA_FL_17RLL3237.copc.laz" -drop_extended_class 29 -target_epsg 6346 -elevation_meter -longlat -target_elevation_meter -olaz -o test3.laz
WARNING: horizontal datum of source unspecified. assuming same as target.

C:\Users\aritchie>lasgrid64 -i test3.laz -step 1 -elevation_average -otif -o test6.tif -vv
Log level [VERY_VERBOSE]
WARNING: COPC EPT hierarchy EVLR number of point does not match with the header.
WARNING: invalid COPC EPT hierarchy (not specification-conform).
ncols was unspecified. set to 1001.
nrows was unspecified. set to 1001.
gridding points onto 1001 by 1001 grid (spacing = 1.00 units)
gridded 13128683 points onto 1001 by 1002 grid (spacing = 1.00 units)
took 1.846 sec. now outputting the grid ...
took 0.039 sec. done with 'test6.tif'.

<upgrade lastools>

C:\Users\aritchie>lasgrid64 -version
LAStools lasgrid (by in...@rapidlasso.de) version 250304 (non-profit)

C:\Users\aritchie>lasgrid64 -i test3.laz -step 1 -elevation_average -otif -o test6.tif -vv
Log level [VERY_VERBOSE]
LAStools lasgrid (by in...@rapidlasso.de) version 250304 (non-profit)
WARNING: COPC EPT hierarchy EVLR number of point does not match with the header.
WARNING: invalid COPC EPT hierarchy (not specification-conform).
open file 'test3.laz'
ncols was unspecified. set to 1001.
nrows was unspecified. set to 1001.
gridding points onto 1001 by 1001 grid (spacing = 1.00 units)
gridded 13128683 points onto 1001 by 1002 grid (spacing = 1.00 units)
took 1.84 sec. now outputting the grid ...
took 0.04 sec. done with 'test6.tif'.

C:\Users\aritchie>las2las -i "C:\Users\aritchie\Downloads\20241029_FEMA_FL_17RLL3237.copc.laz" -drop_extended_class 29 -target_epsg 6346 -elevation_meter -longlat -target_elevation_meter -olaz -o test3.laz
WARNING: horizontal datum of source unspecified. assuming same as target.

************BELOW CRASHES**********
C:\Users\aritchie>lasgrid64 -i test3.laz -step 1 -elevation_average -otif -o test6.tif -vv
Log level [VERY_VERBOSE]
LAStools lasgrid (by in...@rapidlasso.de) version 250304 (non-profit)

C:\Users\aritchie>

but I can still run 32-bit lasgrid:

C:\Users\aritchie>lasgrid -i test3.laz -step 1 -elevation_average -otif -o test6.tif -vv
ncols was unspecified. set to 1001.
nrows was unspecified. set to 1001.
gridding points onto 1001 by 1001 grid (spacing = 1.00 units)
gridded 13128683 points onto 1001 by 1002 grid (spacing = 1.00 units)
took 2.08 sec. now outputting the grid ...
took 0.045 sec. done with 'test6.tif'.

[LAStools - efficient tools for LiDAR processing]

Hi Andrew, 

thanks for this precise description of the problem.
To use the old 32 bit tools can be a solution - if you stay in this world. It most gets difficult if you mix the worlds.
The 32 bit version does not know anything about copc and can not do PROJ transformations.
Therefore las2las does not help with copc files until you remove the VLRs/EVLRs by argument. The 32 bit version copies the copc VLRs and EVLRs, but the file will become invalid for a copc able reader because the copc information does not fit anymore to your data.
This is the reason why lasgrid64 fails afterwards.
The problem is at the combination of reading copc files and doing a crs change from ellipsoid to projected with an EPSG not in the local database.
Best would be to use LAStools with PROJ, so  
    las2las64 -i *.laz -proj_epsg 6346 -odir out -olaz -drop_extended_class 29 -v
(taken epsg from source and convert to 6346) or
    las2las64 -i *.laz -proj_epsg 6318 6346 -odir out -olaz -drop_extended_class 29 -v
(set source and target)
would be best and is most simple.
Unfortunately we found an issue with lat/long data here - we will supply a fix soon so this command works well.
Your approach to set the arguments manually was very good:
      las2las64 -i *.copc.laz -drop_extended_class 29 -target_epsg 6346 -elevation_meter -longlat -target_elevation_meter -olaz -odir out
would do a perfect job, but, las2las64 does not transform the scaling during this operation.
Your target will have the same scale than your degree input so the integer range of your data exceeded and the data became invalid.
The fix is easy: Just add the requested scaling/resolution and it will work:
  las2las64 -i *.copc.laz -drop_extended_class 29 -target_epsg 6346 -elevation_meter -longlat -target_elevation_meter -olaz -odir out -target_precision 0.01

After this, the point cloud can be gridded using lasgrid64 as you did:

    lasgrid64 -i test3.laz -step 1 -elevation_average -otif -o test6.tif -vv

We will do several things with the next version to avoid such problems in future.
- we improve documentation about "-target_precision"
- we change the scale/precision on [long/lat|lat/long]-PCS conversion by default
- we fix some minor PROJ issues

Till then the "-target_precision" argument is a good workaround for this issue.

Cheers,

Jochen @rapidlasso