<div dir="ltr">Great!  I will test when I have a spare moment!   <div><br></div><div>In the long term.. Any chance of filtering the input points through an elevation raster to subtract to get height above ground before statistics?</div>

<div><br></div><div>las file---> subtract value of elevation grid generated from ground points --> run statistics on modified z values of las points.</div><div><br></div><div>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. </div>

<div><br></div><div><br></div><div><br></div><div>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.</div>

<div><br></div><div>Doug     </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 16, 2014 at 6:02 PM, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(back to an older topic)<br>
<br>
On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:<br>
> On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz  wrote:<br>
>> Markus Neteler wrote:<br>
<br>
[ wish for r.in.lidar: ]<br>
...<br>
<div class="">>>>     filter   Only import points of selected return type<br>
>>>               If not specified, all points are imported<br>
>>>              options: first,last,mid<br>
>>><br>
>>> which would be great for r.in.lidar as well to avoid that I need to<br>
>>> split the file with las2las beforehand.<br>
>><br>
>> Why would you want to do filtering? The r.in.lidar methods min, max,<br>
>> mean, median, percentile are not sufficient?<br>
<br>
</div>For some LAS files not.<br>
<div class=""><br>
> I omitted to mention the sometimes existing classification of returns<br>
> and had in mind to be able to restrict the import to e.g. ground<br>
> points only, or the like. Then apply the methods min, max, etc only to<br>
> the selected subset of LiDAR points.<br>
<br>
</div>I have implemented that now in<br>
<a href="http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar" target="_blank">http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar</a><br>
<br>
(hope I got it right over from v.in.lidar)<br>
<br>
Concerning Doug's intensity wish which also became mine yesterday:<br>
Attached a patch to import intensity values rather than z values (flag -i).<br>
Using -i all statistics are applied to intensity.<br>
<br>
The code is a bit simple ("ugly") since the variable names further on<br>
in the code remain related to "z" rather than e.g. become a generic<br>
"value". Not sure if all related variables should be renamed, hence I<br>
didn't commit that to SVN.<br>
Please try from svn + attached patch.<br>
<br>
markusN<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Doug Newcomb</div><div>USFWS</div><div>Raleigh, NC</div><div>919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a></div>

<div>---------------------------------------------------------------------------------------------------------</div><div>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.</div>


</div>