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] importing a adf file - resolution question
I just used r.in.gdal to import a .adf. The files came from the global aridity and pet database hosted by CGIAR CSI http://www.cgiar-csi.org/data/global-aridity-and-pet-database Originally I was getting the warning: WARNING: G_set_window(): Illegal latitude for North so I used the -l option. The file appears to have imported GRASS 6.4.3 (globe_30s):~ r.in.gdal -l in=~/projects/global_aridity/AI_annual/ai_yr/w001001.adf out=ai WARNING: Map bounds have been constrained to geographic coordinates. You will almost certainly want to check map bounds and resolution with r.info and reset them with r.region before going any further. Projection of input dataset and current location appear to match 100% r.in.gdal complete. Raster map ai created. I am trying to check the layer with r.info and I see that the resolution looks odd (N looks correct, should be 30 second, but E looks weird): GRASS 6.4.3 (globe_30s):~ r.info ai ++ | Layer:ai Date: Tue Sep 24 11:06:02 2013| | Mapset: global_aridity_pet Login of Creator: kirkw | | Location: globe_30s| | DataBase: /Volumes/disk1/home1/kirkw/grassdata | | Title: ( ai ) | | Timestamp: none| || || | Type of Map: raster Number of Categories: 733928 | | Data Type:CELL | | Rows: 18000 | | Columns: 43200 | | Total Cells: 77760 | |Projection: Latitude-Longitude | |N:90NS:60S Res: 0:00:30 | |E: 179:59:59.932408WW: 180W Res: 0:00:00.02 | | Range of data:min = 0 max = 733928 | || | Data Description:| |generated by r.in.gdal | || | Comments:| |r.in.gdal -l input=/Volumes/disk1/home1/kirkw/projects/global_aridi\ | |ty/AI_annual/ai_yr/w001001.adf output=ai | || ++ I'm not sure what to do with this? Any suggestions would be most appreciated! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] importing a adf file - resolution question
I'm not sure what to do with this? Any suggestions would be most appreciated! have a look what gdalinfo tells about your input data and compare the gdalinfo-output with g.proj -p of your geographic/projected(?) location. maybe the datasets of http://www.cgiar-csi.org/data/global-aridity-and-pet-database may be not aligned. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/importing-a-adf-file-resolution-question-tp5079666p5079674.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] importing a adf file - resolution question
maybe the datasets of http://www.cgiar-csi.org/data/global-aridity-and-pet-database may be not aligned. from http://www.cgiar-csi.org/data/global-aridity-and-pet-database: The Global-PET and Global-Aridity are both modeled using the data available from WorldClim Global Climate Data (http://WorldClim.org). AFAIR worldclim data has some precision issues/isn't aligned correctly, give it a try to search in the grass-user/grass-dev-ML for worldclim, there may be some suggestions to solve this - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/importing-a-adf-file-resolution-question-tp5079666p5079675.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass-user Digest, Vol 89, Issue 27
Thanks for the reply Helmut. On Sep 24, 2013, at 2:00 PM, grass-user-requ...@lists.osgeo.org wrote: Message: 1 Date: Tue, 24 Sep 2013 10:43:40 -0700 (PDT) From: Helmut Kudrnovsky hel...@web.de To: grass-user@lists.osgeo.org Subject: Re: [GRASS-user] importing a adf file - resolution question Message-ID: 1380044620196-5079674.p...@n6.nabble.com Content-Type: text/plain; charset=us-ascii I'm not sure what to do with this? Any suggestions would be most appreciated! have a look what gdalinfo tells about your input data and compare the gdalinfo-output with g.proj -p of your geographic/projected(?) location. maybe the datasets of http://www.cgiar-csi.org/data/global-aridity-and-pet-database may be not aligned. Seems that simply redefining the region with r.region fixed things. GRASS 6.4.3 (globe_30s):~ r.region map=ai n=90N s=60S w=180W e=180E r.region complete. GRASS 6.4.3 (globe_30s):~ r.info ai ++ | Layer:ai Date: Tue Sep 24 11:06:02 2013| | Mapset: global_aridity_pet Login of Creator: kirkw | | Location: globe_30s| | DataBase: /Volumes/disk1/home1/kirkw/grassdata | | Title: ( ai ) | | Timestamp: none| || || | Type of Map: raster Number of Categories: 733928 | | Data Type:CELL | | Rows: 18000 | | Columns: 43200 | | Total Cells: 77760 | |Projection: Latitude-Longitude | |N:90NS:60S Res: 0:00:30 | |E: 180EW: 180W Res: 0:00:30 | | Range of data:min = 0 max = 733928 | || | Data Description:| |generated by r.in.gdal | || | Comments:| |r.in.gdal -l input=/Volumes/disk1/home1/kirkw/projects/global_aridi\ | |ty/AI_annual/ai_yr/w001001.adf output=ai | || ++ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
