id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,cpu,platform 3560,r.in.lidar: error to open valid LAZ file,neteler,grass-dev@…,"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 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 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? ",defect,closed,normal,7.4.2,Raster,svn-releasebranch74,wontfix,r.in.lidar,AnikaBettge,Unspecified,All