Re: [GRASS-user] r.in.lidar segfaulting
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? 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? Hamish This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.lidar segfaulting
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.lidar segfaulting
On 09/23/2013 05:07 PM, Markus Metz wrote: Micha Silver wrote: Markus Metz wrote: 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? GRASS 7.0.svn (ITM):~ lasinfo -h lasinfo (libLAS 1.7.0 with GeoTIFF 1.3.0 GDAL 1.9.0 LASzip 2.2.0) 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/pt05.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/pt05.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. 0x in ?? () (gdb) generate-core-file Saved corefile core.1905 (gdb) quit A debugging session is active. Inferior 1 [process 1905] will be killed. Quit anyway? (y or n) y GRASS 7.0.svn (ITM):~ The core dump is here: http://surfaces.co.il/dl/core.1905.gz Thanks, Micha ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.lidar segfaulting
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.) Thanks for the addl background, I'll try r.in.xyz also. regards, Hamish This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.in.lidar segfaulting
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/pt05.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/pt28.las 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? Thanks, Micha ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.lidar segfaulting
Hi Markus: On 09/23/2013 02:57 PM, Markus Metz wrote: Micha Silver wrote: 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/pt05.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/pt28.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? GRASS 7.0.svn (ITM):~ lasinfo -h lasinfo (libLAS 1.7.0 with GeoTIFF 1.3.0 GDAL 1.9.0 LASzip 2.2.0) ?? Thanks, Micha 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 This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.lidar segfaulting
Micha Silver wrote: Markus Metz wrote: 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? GRASS 7.0.svn (ITM):~ lasinfo -h lasinfo (libLAS 1.7.0 with GeoTIFF 1.3.0 GDAL 1.9.0 LASzip 2.2.0) Looks good to me. Now it seems it's time to use gdb. You can try gdb, see also the GRASS wiki [0]. Markus M [0] http://grasswiki.osgeo.org/wiki/Debug ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
