<div dir="ltr">I'm fairly sure it could be done outside of GRASS, but I like the control I have within the GRASS framework over analysis extents, resolution, and masks, along with the other analyses I can "pipeline" in a python script in GRASS :-)<div><br></div><div>Doug </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 5:33 PM, Smith, Michael ERDC-RDE-CRREL-NH <span dir="ltr"><<a href="mailto:Michael.Smith@erdc.dren.mil" target="_blank">Michael.Smith@erdc.dren.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div>Howard,</div>
<div><br>
</div>
<div>I'm wondering if GRASS would even be needed here. I would think that one could create a pipeline and use the filters.colorization filter to spatially join to the DEM vrt and apply the HAG values from the DEM to a new dimension (in LAS 1.4, or even something
like BPF) and then stats could be run against the originally Z and the new Z. One could use the filters.merge to read N input files (although it would be much simpler if PDAL could read a pdal tindex file directly) and then write it out either to a single
file or one could add a filters.chipper and a writer to write back out N files.</div>
<div><br>
</div>
<div>I haven't tested this scenario though.</div>
<div>
<div>
<div>----</div>
<div>Michael Smith</div>
</div>
<div>US Army Corps</div>
<div>Remote Sensing GIS/Center</div>
<div><a href="mailto:michael.smith@usace.army.mil" target="_blank">michael.smith@usace.army.mil</a></div>
<div><br>
</div>
</div>
</div>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span><<a href="mailto:pdal-bounces@lists.osgeo.org" target="_blank">pdal-bounces@lists.osgeo.org</a>> on behalf of "Newcomb, Doug" <<a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, September 3, 2015 at 5:14 PM<br>
<span style="font-weight:bold">To: </span>Howard Butler <<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>><br>
<span style="font-weight:bold">Cc: </span>pdal <<a href="mailto:pdal@lists.osgeo.org" target="_blank">pdal@lists.osgeo.org</a>><br>
<span style="font-weight:bold">Subject: </span>[EXTERNAL] Re: [pdal] Migrating from libLAS<br>
<span style="font-weight:bold">Resent-From: </span>Michael Smith <<a href="mailto:michael.smith@usace.army.mil" target="_blank">michael.smith@usace.army.mil</a>><br>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div><div><div class="h5">
<div dir="ltr">Well,
<div>In my dream world, suppose I have a delivery of a DEMs ( dem05_1.img, etc. for a 5ft resolution dem) layer and point cloud ( las1.las ,etc.). I would like to perform statistics on the z values of the point cloud in a binning fashion as done in r.in.lidar
. However, I would like the statistics to be done on z values that are height above ground , not absolute heights</div>
<div><br>
</div>
<div> To avoid edge effects, I aggregate all of the las files togeather ( up to 4.2 billion points per file ) and use gdalbuildvrt to create a single vrt of the dem images. ( I don't recall seeing something like lasbuildvrt, but that would be nice)</div>
<div><br>
</div>
<div>I then call <a>r.in</a> lidar ( resolution set to 60ft cells, vertical values are in feet) :</div>
<div><br>
</div>
<div>r.in.lidar input=aggregated.las output=skewness_60_ft_5ft_to_canopy_top z_mode=hag base_dem=aggrgated_dem.vrt zrange=5,250 method=skewness </div>
<div><br>
</div>
<div>z_mode would be either height above ground (hag) or datum (height from datum - default)</div>
<div><br>
</div>
<div>dem would be the filename of the vrt file or any other gdal - compatible image format. No value would be needed for this unless z_mode was equal to hag. </div>
<div><br>
</div>
<div>As I envision the working, for each bin as each point is read in, the z value is compared to the value of the dem ( z - dem value) at the xy location and the difference replaces the original z value in memory. After all of the points are read in for
a bin , perform the statistic for that bin for the modified z values and move on to the next bin.</div>
<div><br>
</div>
<div>If you are performing the statistics on the intensities or any other attribute, I would still like to be able to filter by the above ground z values. I imagine that the mean intensity for 5 ft above ground slices of the canopy might be quite interesting. </div>
<div><br>
</div>
<div>This would allow you to perform all of the analysis without having to create a height above ground copy of the las files for input into r.in.lidar, staying as close to working with the original data as possible. As the size of lidar data sets increases,
it seems logical to reduce the amount of data duplication required. </div>
<div><br>
</div>
<div>Does that seem like something workable and scaleable with a pdal - GRASS interface?</div>
<div><br>
</div>
<div>Doug</div>
</div>
</div></div><div class="gmail_extra"><br>
<div class="gmail_quote"><div><div class="h5">On Thu, Sep 3, 2015 at 1:47 PM, Howard Butler <span dir="ltr">
<<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
On the list. How would you envision it should work?<br>
<div>
<div><br>
> On Sep 3, 2015, at 12:41 PM, Newcomb, Doug <<a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a>> wrote:<br>
><br>
> Could there be an option to filter for height above ground in reference to an external DEM?<br>
><br>
> Doug<br>
><br>
> On Wed, Sep 2, 2015 at 8:10 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>> wrote:<br>
><br>
> On Wed, Sep 2, 2015 at 5:16 PM, Andrew Bell <<a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a>> wrote:<br>
> ><br>
> > Here's an example from the test code where I've removed all the stuff<br>
> > that actually tests. First we create a point table that's a subclass<br>
> > of PointTable. It only supports x, y, and z. Then we register a<br>
> > callback to be invoked each time a point is read (it does nothing<br>
> > other than fetch the data). I've also annotated the code.<br>
><br>
> Awesome, thanks! The comments are also very helpful.<br>
><br>
> Now I have the v.in.lidar implementation as described in the guide I'm working on. I will try how it will look like on GRASS GIS site. Then I will get back to this. Reading only as you described it, wrapped in C API, would be the ideal solution for the current
v.in.lidar concept (import and basic filtering).<br>
><br>
> Vaclav<br>
><br>
><br>
><br>
> --<br>
> Doug Newcomb<br>
> USFWS<br>
> Raleigh, NC<br>
> 919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a><br>
> ---------------------------------------------------------------------------------------------------------<br>
> 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.<br>
</div>
</div>
</div></div><div>
<div><div><div class="h5">> _______________________________________________<br>
> pdal mailing list<br>
> <a href="mailto:pdal@lists.osgeo.org" target="_blank">pdal@lists.osgeo.org</a><br></div></div>
> <a rel="noreferrer">
BlockedBlockedhttp://lists.osgeo.org/mailman/listinfo/pdalBlocked</a><br>
<br>
</div>
</div>
</blockquote>
</div><span class="">
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<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>
</span></div>
</div>
</div>
</blockquote>
</span>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><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>
</div>