Re: [GRASS-dev] ] LiDAR LAS import - filter on import?
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 .
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
...
real6m34.430s
...
real6m13.823s
...
# without table, with topology
...
real1m53.578s
...
real1m44.876s
I take it that without topology it runs in just seconds?
Update: no attribute table, no topology
time las2txt -i
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
Re: [GRASS-dev] ] LiDAR LAS import - filter on import?
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
Re: [GRASS-dev] LiDAR LAS import
Hi Markus, Just compiled again liblas svn trunk, everything is working as expected so far. Thanks heaps for that new functionality, this is really very useful. Pierre 2011/5/25 Markus Metz markus.metz.gisw...@googlemail.com: Hi all, GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files (*.las or *.laz). The LAS file format is commonly used for storing LiDAR point clouds, but is unfortunately not supported by OGR. v.in.lidar uses the libLAS library [0] and is only compiled if the libLAS library is present. I chose to use the library instead of writing a custom LAS reading interface because the current LAS library version 1.6.1 is stable, supports LAS file versions 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, each of which can store LiDAR points in up to 5 different point formats. The user and the interface do not need to know the file version and point format of a given file, all that is conveniently handled by the libLAS library in the background. The library has Large File Support (LFS) and is well tested on different platforms, also with different endian-ness. This functionality is not that easy to replicate. You will need to get the libLAS library and configure GRASS 7 with --with-liblas in order to have the module available. Please test! Markus M [0] http://www.liblas.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] LiDAR LAS import
Hi all, GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files (*.las or *.laz). The LAS file format is commonly used for storing LiDAR point clouds, but is unfortunately not supported by OGR. v.in.lidar uses the libLAS library [0] and is only compiled if the libLAS library is present. I chose to use the library instead of writing a custom LAS reading interface because the current LAS library version 1.6.1 is stable, supports LAS file versions 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, each of which can store LiDAR points in up to 5 different point formats. The user and the interface do not need to know the file version and point format of a given file, all that is conveniently handled by the libLAS library in the background. The library has Large File Support (LFS) and is well tested on different platforms, also with different endian-ness. This functionality is not that easy to replicate. You will need to get the libLAS library and configure GRASS 7 with --with-liblas in order to have the module available. Please test! Markus M [0] http://www.liblas.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] LiDAR LAS import
Yes Thank you Markus! Since you are using liblas 1.6.1 , I assume that this command can read the losslessly compressed .laz format? Will try soon. 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 05/25/2011 05:31 AM To grass-user grass-u...@lists.osgeo.org, GRASS developers list grass-dev@lists.osgeo.org cc Subject [GRASS-dev] LiDAR LAS import Hi all, GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files (*.las or *.laz). The LAS file format is commonly used for storing LiDAR point clouds, but is unfortunately not supported by OGR. v.in.lidar uses the libLAS library [0] and is only compiled if the libLAS library is present. I chose to use the library instead of writing a custom LAS reading interface because the current LAS library version 1.6.1 is stable, supports LAS file versions 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, each of which can store LiDAR points in up to 5 different point formats. The user and the interface do not need to know the file version and point format of a given file, all that is conveniently handled by the libLAS library in the background. The library has Large File Support (LFS) and is well tested on different platforms, also with different endian-ness. This functionality is not that easy to replicate. You will need to get the libLAS library and configure GRASS 7 with --with-liblas in order to have the module available. Please test! Markus M [0] http://www.liblas.org ___ 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
Re: [GRASS-dev] LiDAR LAS import
On Wed, May 25, 2011 at 1:45 PM, doug_newc...@fws.gov wrote: Yes Thank you Markus! Since you are using liblas 1.6.1 , I assume that this command can read the losslessly compressed .laz format? As long as libLAS is compiled with laszip support, yes (tested and working). ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
