I have compiled GRASS 7.0 on Debian Wheezy (everything else in the spatial stack are stock packages), and I’m getting a segmentation fault on both r.in.lidar and v.in.lidar.
In the lasinfo output I don’t see anything unusual (other than z values < 0). The *.las are projected into our local tmerc CRS.
I can run las2txt and then import the text file with v.in.ascii, but I’d like to work out what’s wrong with the direct raster import. Any ideas how to further debug this?
I have compiled GRASS 7.0 on Debian Wheezy (everything else in the spatial
stack are stock packages), and I'm getting a segmentation fault on both
r.in.lidar and v.in.lidar.
Both r.in.lidar and v.in.lidar say that none of the 7651 points in
that file is valid. I am using libLAS 1.7.0 with GeoTIFF 1.4.0 GDAL
1.10.0 LASzip 2.1.0. I remember that [r|v].in.lidar require a recent
version of libLAS and other users experienced problems with older
versions of libLAS. Which version are you using?
In the lasinfo output I don't see anything unusual (other than z values <
0). The *.las are projected into our local tmerc CRS.
I can run las2txt and then import the text file with v.in.ascii, but I'd
like to work out what's wrong with the direct raster import. Any ideas how
to further debug this?
I have compiled GRASS 7.0 on Debian Wheezy (everything else in the spatial
stack are stock packages), and I'm getting a segmentation fault on both
r.in.lidar and v.in.lidar.
GRASS 7.0.svn (ITM):~/GIS/DEM/LIDAR_EinYahav/Version2 > g.version -g
version=7.0.svn
date=2013
revision=57816
build_date=2013-09-23
GRASS 7.0.svn (ITM):~/GIS/DEM/LIDAR_EinYahav/Version2 > r.in.lidar
in=/media/cdrom0/pt000005.las out=pts05 meth=mean
Segmentation fault
Here's a sample of the *.las files I'm using (this one is only 260k):
[http://www.surfaces.co.il/dl/pt000028.las](http://www.surfaces.co.il/dl/pt000028.las)
Both r.in.lidar and v.in.lidar say that none of the 7651 points in
that file is valid. I am using libLAS 1.7.0 with GeoTIFF 1.4.0 GDAL
1.10.0 LASzip 2.1.0. I remember that [r|v].in.lidar require a recent
version of libLAS and other users experienced problems with older
versions of libLAS. Which version are you using?
In the lasinfo output I don't see anything unusual (other than z values <
0). The *.las are projected into our local tmerc CRS.
I can run las2txt and then import the text file with v.in.ascii, but I'd
like to work out what's wrong with the direct raster import. Any ideas how
to further debug this?
You can try gdb, see also the GRASS wiki [0].
Markus M
[0] [http://grasswiki.osgeo.org/wiki/Debug](http://grasswiki.osgeo.org/wiki/Debug)
This mail was received via Mail-SeCure System.
Both r.in.lidar and v.in.lidar say that none of the 7651 points in
that file is valid. I am using libLAS 1.7.0 with GeoTIFF 1.4.0 GDAL
1.10.0 LASzip 2.1.0. I remember that [r|v].in.lidar require a recent
version of libLAS and other users experienced problems with older
versions of libLAS. Which version are you using?
I can run las2txt and then import the text file with v.in.ascii, but
I'd like to work out what's wrong with the direct raster import. Any
ideas how to further debug this?
I’m using las2txt + v.in.ascii, then v.surf.rst That works as expected. The spread of the point cloud is very irregular, some cells (1x1 m) with 50+ points, and some with none, so I guess that r.in.xyz would be less desirable?
···
On 09/24/2013 01:30 AM, Hamish wrote:
Micha
I can run las2txt and then import the text file with v.in.ascii, but
I'd like to work out what's wrong with the direct raster import. Any
ideas how to further debug this?
does las2txt + r.in.xyz work?
Hamish
This mail was received via Mail-SeCure System.
I can run las2txt and then import the text file with v.in.ascii, but
I'd like to work out what's wrong with the direct raster import. Any
ideas how to further debug this?
Hamish:
does las2txt + r.in.xyz work?
Micha:
I'm using las2txt + v.in.ascii, then v.surf.rst That works as expected.
The spread of the point cloud is very irregular, some cells (1x1 m)
with 50+ points, and some with none, so I guess that r.in.xyz would
be less desirable?
I'd think that the point density case you describe would be the ideal
scenario for using r.in.lidar or r.in.xyz, so if anything I'd suggest
it was more desirable to conflate all the points within the sq. meter
to a single one as a pre-processing step than trying to fit a spline
to all of them (n.b. I'm not entirely familiar with v.surf.rst's sub-cell
resolution decimation method, but if it isn't doing that beware the
close-proximity overshoots).
(r.in.lidar uses the same binning method as r.in.xyz (using libLAS for
the input stream instead of an ascii file) so you can expect the use
cases to be near identical, it just saves you the las2txt step. They are
mostly the same code.)
Both r.in.lidar and v.in.lidar say that none of the 7651 points in
that file is valid. I am using libLAS 1.7.0 with GeoTIFF 1.4.0 GDAL
1.10.0 LASzip 2.1.0. I remember that [r|v].in.lidar require a recent
version of libLAS and other users experienced problems with older
versions of libLAS. Which version are you using?
Looks good to me. Now it seems it's time to use gdb.
Here's what I get:
GRASS 7.0.svn (ITM):~ > gdb --args r.in.lidar in=/media/cdrom0/pt000005.las out=rast_05 meth=mean
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>\.\.\.
Reading symbols from /usr/local/grass-7.0.svn/bin/r.in.lidar...done.
(gdb) r
Starting program: /usr/local/grass-7.0.svn/bin/r.in.lidar in=/media/cdrom0/pt000005.las out=rast_05 meth=mean
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) generate-core-file
Saved corefile core.1905
(gdb) quit
A debugging session is active.
Thanks for the addl background, I’ll try r.in.xyz also.
···
On 09/24/2013 10:20 AM, Hamish wrote:
Micha wrote:
I can run las2txt and then import the text file with v.in.ascii, but
I'd like to work out what's wrong with the direct raster import. Any
ideas how to further debug this?
Hamish:
does las2txt + r.in.xyz work?
Micha:
I'm using las2txt + v.in.ascii, then v.surf.rst That works as expected.
The spread of the point cloud is very irregular, some cells (1x1 m)
with 50+ points, and some with none, so I guess that r.in.xyz would
be less desirable?
I'd think that the point density case you describe would be the ideal
scenario for using r.in.lidar or r.in.xyz, so if anything I'd suggest
it was more desirable to conflate all the points within the sq. meter
to a single one as a pre-processing step than trying to fit a spline
to all of them (n.b. I'm not entirely familiar with v.surf.rst's sub-cell
resolution decimation method, but if it isn't doing that beware the
close-proximity overshoots).
(r.in.lidar uses the same binning method as r.in.xyz (using libLAS for
the input stream instead of an ascii file) so you can expect the use
cases to be near identical, it just saves you the las2txt step. They are
mostly the same code.)
regards,
Hamish
This mail was received via Mail-SeCure System.
Looks good to me. Now it seems it's time to use gdb.
Here's what I get:
GRASS 7.0.svn (ITM):~ > gdb --args r.in.lidar in=/media/cdrom0/pt000005.las
out=rast_05 meth=mean
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>\.\.\.
Reading symbols from /usr/local/grass-7.0.svn/bin/r.in.lidar...done.
(gdb) r
Starting program: /usr/local/grass-7.0.svn/bin/r.in.lidar
in=/media/cdrom0/pt000005.las out=rast_05 meth=mean
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) generate-core-file
Saved corefile core.1905
(gdb) quit
A debugging session is active.