>>Markus, >> Were you planning on adding filtering options by return number on v.in.lidar? It occurs to me that you could speed things up by only processing the subset of the data that you want to >>use. I could see it being a useful thing to create a vector layer composed only of 1st returns ( top of canopy/buildings) Selecting only last returns is useful, as well as selecting points that >>are neither first nor last returns . >Yes, I was thinking of such filter options, they would be very easy and straightforward to implement, something like v.in.lidar returns=[all,first,last,middle]. Currently there is only spatial >filtering available. Excellent!
>I was also thinking about an option to select columns to be imported as attributes, equivalent to the las2txt --parse option, but could not yet come up with a user-friendly solution: flags >don't work because too many and conflicting with existing flags, a parse option very much like the one of las2txt is too cryptic. I think I will settle for something like v.in.lidar >attributes=coords,classes,color,egde,angle,return,nreturns,... where the attributes option takes none, one or multiple answers Sounds good. That would have the advantage of "standardizing" the lidar attibute names for future lidar point processing modules in GRASS >Markus M Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov --------------------------------------------------------------------------------------------------------- The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz <markus.metz.gisw...@googlemail.com> 06/03/2011 10:36 AM To doug_newc...@fws.gov cc GRASS developers list <grass-dev@lists.osgeo.org> Subject Re: [GRASS-dev] ] LiDAR LAS import - filter on import? On Fri, Jun 3, 2011 at 3:30 PM, <doug_newc...@fws.gov> wrote: Markus, Were you planning on adding filtering options by return number on v.in.lidar? It occurs to me that you could speed things up by only processing the subset of the data that you want to use. I could see it being a useful thing to create a vector layer composed only of 1st returns ( top of canopy/buildings) Selecting only last returns is useful, as well as selecting points that are neither first nor last returns . Yes, I was thinking of such filter options, they would be very easy and straightforward to implement, something like v.in.lidar returns=[all,first,last,middle]. Currently there is only spatial filtering available. I was also thinking about an option to select columns to be imported as attributes, equivalent to the las2txt --parse option, but could not yet come up with a user-friendly solution: flags don't work because too many and conflicting with existing flags, a parse option very much like the one of las2txt is too cryptic. I think I will settle for something like v.in.lidar attributes=coords,classes,color,egde,angle,return,nreturns,... where the attributes option takes none, one or multiple answers Markus M I've been primarily working with aggregate las files that I have dumped to text ( via liblas las2txt ) and then parse via python for first, middle, and last returns. I have not taken the time to learn C yet, but perhaps the logic of these simple python programs would be useful . The following is the python script I use to separate the last returns. --------------------------------------------------------------------------------------------------------------------------------- import struct,os,string,re,binascii,glob infile = raw_input("Enter the aggregate lidar filename: ") outfil = raw_input("Enter the ASCII output filename for the Lidar Data: ") intxt=open(infile,'r') outtxt=open(outfil,'w') while 1: lasline=intxt.readline() lasinfo=lasline.split(',') if (len(lasinfo))< 5:break numreturns=int(lasinfo[4]) returnnum=int(lasinfo[5]) # In the data input file for this instance, the number of returns # is the fifth column, and the return number is the sixth column ( x=1,y=2,z=3,intensity=4). # If the value of these colums is equal, it should be the last return. if ( numreturns==returnnum): outtxt.write(lasline) intxt.close() outtxt.close() -------------------------------------------------------------------------------------------------------------------------------- For parsing the first returns, substitute if (returnnum==1): Here is the python script I use to separate out the "middle" returns. ------------------------------------------------------------------------------------------------------------------------------- import struct,os,string,re,binascii,glob infile = raw_input("Enter the aggregate lidar filename: ") outfil = raw_input("Enter the ASCII output filename for the Lidar Data: ") intxt=open(infile,'r') outtxt=open(outfil,'w') while 1: lasline=intxt.readline() lasinfo=lasline.split(',') if (len(lasinfo))< 5:break numreturns=int(lasinfo[4]) returnnum=int(lasinfo[5]) # In the data input file for this instance, the number of returns # is the fifth column, and the return number is the sixth column ( x=1,y=2,z=3,intensity=4). # If the value of these colums is equal, it should be the last return, so skip that entry # If the return number is 1 , skip that value. All other values are middle canopy values,which is what we want. if ( numreturns==returnnum): continue if (returnnum==1):continue outtxt.write(lasline) intxt.close() outtxt.close() ------------------------------------------------------------------------------------------------------------------------------ I really appreciate your adding lidar data classifications from the standard into the program. I haven't actually seen any lidar data with classifications yet, but I have hope for the future :-). As a bit of background , I'm taking the last returns and then running r.in.xyz to create a raster with the intensities as the z values to get relative soil moistures, and looking at points that are neither first nor last returns as a possible measure of vegetation density. It works great for large datasets( > 4 billion points) , but I'm feeling the need for more point analysis. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov --------------------------------------------------------------------------------------------------------- The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz <markus.metz.gisw...@googlemail.com> Sent by: grass-dev-boun...@lists.osgeo.org 06/03/2011 02:20 AM To Hamish <hamis...@yahoo.com> cc GRASS developers list <grass-dev@lists.osgeo.org> Subject [GRASS-dev] Re: [GRASS-user] LiDAR LAS import Hamish wrote: > Markus Metz wrote: [snip] > >> v.in.lidar is a notch faster than las2txt | v.in.ascii. And >> easier to use... > > I'm not too surprised the speed difference is not so huge, as > unix pipes are very efficient. but the easier to use thing is > very important.. both las2txt and v.in.ascii are a bundle of > command line switches to get right. > > >> Speed comparisons: >> >> # sample las file with 1,287,775 points >> >> # with table and topology > ... >> real 6m34.430s > ... >> real 6m13.823s > ... >> # without table, with topology > ... >> real 1m53.578s > ... >> real 1m44.876s > > > I take it that without topology it runs in just seconds? Update: no attribute table, no topology time las2txt -i points.las --stdout --parse xyz --delimiter "|" | v.in.ascii in=- out=points_ascii -ztb x=1 y=2 z=3 real 0m20.932s user 0m18.424s sys 0m6.869s time v.in.lidar in=points.las out=points_las -obt real 0m9.117s user 0m2.946s sys 0m5.985s Markus M _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev