r.in.lidar: error to open valid LAZ file

[neteler]

We currently fail to import a larger LiDAR file (LAZ)

pdal info dom1l_fp_tr_gebiet.laz > meta.txt
head -n 300 meta.txt 
{
  "filename": "dom1l_fp_tr_gebiet.laz",
  "pdal_version": "1.7.0 (git-version: Release)",
  "stats":
  {
    "bbox":
    {
      "EPSG:4326":
      {
        "bbox":
        {
          "maxx": 7.311614961,
          "maxy": 50.83646173,
          "maxz": 344.69,
          "minx": 7.196437705,
          "miny": 50.78981976,
          "minz": 56.12
        },
        "boundary": {
        "coordinates" : 
        [
                [
                        [
                                7.1981681200000001,
                                50.78981976
                        ],

...
   "statistic":
    [
      {
        "average": 377073.6011,
        "count": 297683873,
        "kurtosis": -4.436009717e+18,
        "maximum": 381000,
        "minimum": 373000,
        "name": "X",
        "position": 0,
        "skewness": 5.047057151e+17,
        "stddev": 1853.891145,
        "variance": 3436912.377
      },

This file was created with "pdal merge" from several LAZ tiles.

Now, the import fails without any specific explanation:

GRASS 7.4.1svn (lidar):/scratch/kaldauen_klassifikation >

r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
FEHLER: Unable to open file <dom1l_fp_tr_gebiet.laz>
        as a LiDAR point cloud

g.gisenv set="DEBUG=3"
r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
D1/3: G_set_program_name(): r.in.lidar
D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika
D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/cell/bla
D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
D2/3:     file open: read (mode = r)
D2/3: G__read_Cell_head
D2/3: G__read_Cell_head_array
D3/3: region item: proj:       99
D3/3: region item: zone:       0
D3/3: region item: north:      5631000
D3/3: region item: south:      5628000
D3/3: region item: east:       379002
D3/3: region item: west:       375000
D3/3: region item: cols:       1334
D3/3: region item: rows:       1000
D3/3: region item: e-w resol:  3
D3/3: region item: n-s resol:  3
D3/3: region item: top:        1.000000000000000
D3/3: region item: bottom:     0.000000000000000
D3/3: region item: cols3:      1334
D3/3: region item: rows3:      1000
D3/3: region item: depths:     1
D3/3: region item: e-w resol3: 3
D3/3: region item: n-s resol3: 3
D3/3: region item: t-b resol:  1
FEHLER: Unable to open file <dom1l_fp_tr_gebiet.laz>
        as a LiDAR point cloud
D1/3: G_set_program_name(): g.gisenv
D3/3: G_option_to_separator(): key = separator -> sep = '/'

To be sure, a check if liblas was compiled with LAZ support:

ldd `which r.in.lidar`
    linux-vdso.so.1 (0x00007fff91df4000)
    libgrass_raster.7.4.1svn.so => /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-gnu/lib/libgrass_raster.7.4.1svn.so  0x00007f225909b000)
    libgrass_gis.7.4.1svn.so => /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-gnu/lib/libgrass_gis.7.4.1svn.so (0x00007f2258e42000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f2258af7000)
    libgrass_gproj.7.4.1svn.so => /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.7.4.1svn.so (0x00007f22588ec000)
    liblas.so.3 => /lib64/liblas.so.3 (0x00007f225862b000)
    liblas_c.so.3 => /lib64/liblas_c.so.3 (0x00007f22583f4000)
    libboost_program_options.so.1.64.0 => /lib64/libboost_program_options.so.1.64.0 (0x00007f2258179000)
...
    libboost_regex.so.1.64.0 => /lib64/libboost_regex.so.1.64.0 (0x00007f225454c000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f22541c5000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2253fae000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f2253da6000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2253b88000)
    libarmadillo.so.7 => /lib64/libarmadillo.so.7 (0x00007f225397f000)
    libpoppler.so.68 => /lib64/libpoppler.so.68 (0x00007f22534da000)
    libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f22532cf000)
    libfreexl.so.1 => /lib64/libfreexl.so.1 (0x00007f22530c6000)
    libgeos_c.so.1 => /lib64/libgeos_c.so.1 (0x00007f2252e95000)
    libwebp.so.7 => /lib64/libwebp.so.7 (0x00007f2252c27000)
...
    /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-gnu/lib/libgrass_rtree.7.4.1svn.so (0x00007f2248669000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f2248458000)
    libicudata.so.57 => /lib64/libicudata.so.57 (0x00007f22469db000)
...


# limit check to "las" string:
ldd `which r.in.lidar` | grep las
    liblas.so.3 => /lib64/liblas.so.3 (0x00007faa54b94000)
    liblas_c.so.3 => /lib64/liblas_c.so.3 (0x00007faa5495d000)
    liblaszip.so.8 => /lib64/liblaszip.so.8 (0x00007faa528ce000)
    libopenblaso.so.0 => /lib64/libopenblaso.so.0 (0x00007faa401eb000)
    libblas.so.3 => /lib64/libblas.so.3 (0x00007faa3a078000)
    libopenblasp.so.0 => /lib64/libopenblasp.so.0 (0x00007faa37b34000)
    libsatlas.so.3 => /usr/lib64/atlas/libsatlas.so.3 (0x00007faa36b25000)

So, liblaszip is present, i.e. LAZ support should be ok.

System:

lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	Fedora
Description:	Fedora release 27 (Twenty Seven)
Release:	27
Codename:	TwentySeven

Any ideas how to debug this properly? (I can test on trunk as well)

Does the LAZ file size matter?

[neteler]

For now, using https://grass.osgeo.org/grass74/manuals/addons/r.in.pdal.html script as work-around.

[martinl]

What is the state of this ticket?

[neteler]

I guess that PDAL = r.in.pdal is the future since liblas is not really developed any more.

[neteler]

Replying to neteler:

I guess that PDAL = r.in.pdal is the future since liblas is not really developed any more.

Closing accordingly as wontfix (and referring to https://grass.osgeo.org/grass7/manuals/addons/r.in.pdal.html)