#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>