#3560: r.in.lidar: error to open valid LAZ file ------------------------+--------------------------------- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.4.1 Component: Raster | Version: svn-releasebranch74 Keywords: r.in.lidar | CPU: Unspecified Platform: All | ------------------------+--------------------------------- 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? -- Ticket URL: <https://trac.osgeo.org/grass/ticket/3560> GRASS GIS <https://grass.osgeo.org>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev