Hi,
I have ported the -p Print LAS file info and exit from v.in.lidar to r.in.lidar
I have also made a major rewrite of the manual which was too much
cloned from r.in.xyz:
http://grass.osgeo.org/grass70/manuals/r.in.lidar.html
Further improvements are welcome (in SVN or as SVN diff).
cheers
markusN
PS: if the LAS file is not accessible, r.in.lidar happily segfaults.
My attempts to fix that were yet unsuccessful.
Markus Neteler wrote:
PS: if the LAS file is not accessible, r.in.lidar happily segfaults.
My attempts to fix that were yet unsuccessful.
Fixed in r57951,2 for [r|v].in.lidar
Markus M
On Mon, Oct 7, 2013 at 8:28 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
Markus Neteler wrote:
PS: if the LAS file is not accessible, r.in.lidar happily segfaults.
My attempts to fix that were yet unsuccessful.Fixed in r57951,2 for [r|v].in.lidar
Thanks!
One more wish comes to mind (indeed, I started cross-porting but 
v.in.lidar comes with a filter (which should perhaps be generalized to
the nth return; or, the last *is* the nth return but then "mid" could
be more than one in this case?):
filter Only import points of selected return type
If not specified, all points are imported
options: first,last,mid
which would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.
markusN
Markus Neteler wrote:
One more wish comes to mind (indeed, I started cross-porting but
v.in.lidar comes with a filter (which should perhaps be generalized to
the nth return; or, the last *is* the nth return but then "mid" could
be more than one in this case?):
Yes, for n returns, the first return is number 1, the last return is
the nth return and mid returns are all returns in between, i.e. none
for 2 returns. Choosing the nth return does not make sense to me.
filter Only import points of selected return type
If not specified, all points are imported
options: first,last,midwhich would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.
Why would you want to do filtering? The r.in.lidar methods min, max,
mean, median, percentile are not sufficient?
Markus M
On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
Markus Neteler wrote:
One more wish comes to mind (indeed, I started cross-porting but
v.in.lidar comes with a filter (which should perhaps be generalized to
the nth return; or, the last *is* the nth return but then "mid" could
be more than one in this case?):Yes, for n returns, the first return is number 1, the last return is
the nth return and mid returns are all returns in between, i.e. none
for 2 returns. Choosing the nth return does not make sense to me.
ok
filter Only import points of selected return type
If not specified, all points are imported
options: first,last,midwhich would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.Why would you want to do filtering? The r.in.lidar methods min, max,
mean, median, percentile are not sufficient?
I omitted to mention the sometimes existing classification of returns
and had in mind to be able to restrict the import to e.g. ground
points only, or the like. Then apply the methods min, max, etc only to
the selected subset of LiDAR points.
markusN
Any thoughts on applying further filtering and using the intensity of the return for statistical analysis? For example, if one wanted to calculate the mean/range/in/max/std_dev intensity of the last returns or first returns.
Doug
On Tue, Oct 8, 2013 at 2:37 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:Markus Neteler wrote:
One more wish comes to mind (indeed, I started cross-porting but
v.in.lidar comes with a filter (which should perhaps be generalized to
the nth return; or, the last is the nth return but then “mid” could
be more than one in this case?):Yes, for n returns, the first return is number 1, the last return is
the nth return and mid returns are all returns in between, i.e. none
for 2 returns. Choosing the nth return does not make sense to me.ok
filter Only import points of selected return type
If not specified, all points are imported
options: first,last,midwhich would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.Why would you want to do filtering? The r.in.lidar methods min, max,
mean, median, percentile are not sufficient?I omitted to mention the sometimes existing classification of returns
and had in mind to be able to restrict the import to e.g. ground
points only, or the like. Then apply the methods min, max, etc only to
the selected subset of LiDAR points.markusN
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
–
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.
(back to an older topic)
On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz wrote:
Markus Neteler wrote:
[ wish for r.in.lidar: ]
...
filter Only import points of selected return type
If not specified, all points are imported
options: first,last,midwhich would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.Why would you want to do filtering? The r.in.lidar methods min, max,
mean, median, percentile are not sufficient?
For some LAS files not.
I omitted to mention the sometimes existing classification of returns
and had in mind to be able to restrict the import to e.g. ground
points only, or the like. Then apply the methods min, max, etc only to
the selected subset of LiDAR points.
I have implemented that now in
http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar
(hope I got it right over from v.in.lidar)
Concerning Doug's intensity wish which also became mine yesterday:
Attached a patch to import intensity values rather than z values (flag -i).
Using -i all statistics are applied to intensity.
The code is a bit simple ("ugly") since the variable names further on
in the code remain related to "z" rather than e.g. become a generic
"value". Not sure if all related variables should be renamed, hence I
didn't commit that to SVN.
Please try from svn + attached patch.
markusN
r.in.lidar71.diff (1.33 KB)
Great! I will test when I have a spare moment!
In the long term… Any chance of filtering the input points through an elevation raster to subtract to get height above ground before statistics?
las file—> subtract value of elevation grid generated from ground points → run statistics on modified z values of las points.
One problem I can see is that you generally have higher resolution elevation rasters than the resolution of forest canopy structure you wish to create. 6m elevation grid vs 18m canopy structure grids) This might be better as a separate function (r.lashag?) in which you have inputs of an external las file and an elevation raster layer and an output of an las file with the z value as height above ground.
I’ve done this externally with python scripts ( badly and slowly) . On the upside, the resulting las datasets are quite promising for landscape - level canopy structure analysis.
Doug
On Fri, May 16, 2014 at 6:02 PM, Markus Neteler <neteler@osgeo.org> wrote:
(back to an older topic)
On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz wrote:
Markus Neteler wrote:
[ wish for r.in.lidar: ]
…filter Only import points of selected return type
If not specified, all points are imported
options: first,last,midwhich would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.Why would you want to do filtering? The r.in.lidar methods min, max,
mean, median, percentile are not sufficient?For some LAS files not.
I omitted to mention the sometimes existing classification of returns
and had in mind to be able to restrict the import to e.g. ground
points only, or the like. Then apply the methods min, max, etc only to
the selected subset of LiDAR points.I have implemented that now in
http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar(hope I got it right over from v.in.lidar)
Concerning Doug’s intensity wish which also became mine yesterday:
Attached a patch to import intensity values rather than z values (flag -i).
Using -i all statistics are applied to intensity.The code is a bit simple (“ugly”) since the variable names further on
in the code remain related to “z” rather than e.g. become a generic
“value”. Not sure if all related variables should be renamed, hence I
didn’t commit that to SVN.
Please try from svn + attached patch.markusN
–
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.
I pulled the latest 71 trunk ( 60278) , applied the patch, and the intensity option appears to work.
Doug
On Fri, May 16, 2014 at 6:02 PM, Markus Neteler <neteler@osgeo.org> wrote:
(back to an older topic)
On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz wrote:
Markus Neteler wrote:
[ wish for r.in.lidar: ]
…filter Only import points of selected return type
If not specified, all points are imported
options: first,last,midwhich would be great for r.in.lidar as well to avoid that I need to
split the file with las2las beforehand.Why would you want to do filtering? The r.in.lidar methods min, max,
mean, median, percentile are not sufficient?For some LAS files not.
I omitted to mention the sometimes existing classification of returns
and had in mind to be able to restrict the import to e.g. ground
points only, or the like. Then apply the methods min, max, etc only to
the selected subset of LiDAR points.I have implemented that now in
http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar(hope I got it right over from v.in.lidar)
Concerning Doug’s intensity wish which also became mine yesterday:
Attached a patch to import intensity values rather than z values (flag -i).
Using -i all statistics are applied to intensity.The code is a bit simple (“ugly”) since the variable names further on
in the code remain related to “z” rather than e.g. become a generic
“value”. Not sure if all related variables should be renamed, hence I
didn’t commit that to SVN.
Please try from svn + attached patch.markusN
–
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.
[ wish for r.in.lidar: ]
...
>>> filter Only import points of selected return type
>>> If not specified, all points are imported
>>> options: first,last,mid
>>>
>>> which would be great for r.in.lidar as well to avoid that I need
>>> to split the file with las2las beforehand.
Markus Neteler wrote:
I have implemented that now in
http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar(hope I got it right over from v.in.lidar)
Hi,
you might look at the vrange= "Filter range for alternate value column data (min,max)" was implemented for r.in.xyz, I humbly think the approach there is pretty clean and useful.
Besides filtering co-variant outliers, the use case there was to filter by z-range when building 3D slices as part of a raster3D import, when the import data value for the raster is not the "z" column; see the r3.in.xyz.py module for an example of how it is used. (unrelated, but I'd also note that the parallelization method for z-level slice import in r3.in.xyz works out to be surprisingly efficient)
regards
--
Hamish <hamish.webmail@gmail.com>
On 5/17/14, Newcomb, Doug <doug_newcomb@fws.gov> wrote:
I pulled the latest 71 trunk ( 60278) , applied the patch, and the
intensity option appears to work.
Just for the record: added in trunk in r61480.
Markus
On Mon, May 19, 2014 at 6:30 AM, Hamish <hamish.webmail@gmail.com> wrote:
[ wish for r.in.lidar: ]
...
>>> filter Only import points of selected return type
>>> If not specified, all points are imported
>>> options: first,last,mid
>>>
>>> which would be great for r.in.lidar as well to avoid that I need
>>> to split the file with las2las beforehand.Markus Neteler wrote:
I have implemented that now in
http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar(hope I got it right over from v.in.lidar)
Hi,
you might look at the vrange= "Filter range for alternate value column data (min,max)" was implemented for r.in.xyz, I humbly think the approach there is pretty clean and useful.
Well, the manual does not really explain yet how to use that:
http://grass.osgeo.org/grass70/manuals/r.in.xyz.html
Please consider to add more.
thanks
Markus
Besides filtering co-variant outliers, the use case there was to filter by z-range when building 3D slices as part of a raster3D import, when the import data value for the raster is not the "z" column; see the r3.in.xyz.py module for an example of how it is used. (unrelated, but I'd also note that the parallelization method for z-level slice import in r3.in.xyz works out to be surprisingly efficient)
regards
--
Hamish <hamish.webmail@gmail.com>