[pdal] Migrating from libLAS

[Newcomb, Doug]

Well,
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

 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)

I then call r.in lidar  ( resolution set to 60ft cells, vertical values are
in feet) :

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

z_mode would be either height above ground (hag) or datum (height from
datum - default)

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.

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.

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.

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.

Does that seem like something workable and scaleable with a pdal - GRASS
interface?

Doug

On Thu, Sep 3, 2015 at 1:47 PM, Howard Butler <howard at hobu.co> wrote:

> On the list. How would you envision it should work?
>
> > On Sep 3, 2015, at 12:41 PM, Newcomb, Doug <doug_newcomb at fws.gov> wrote:
> >
> > Could there be an option to filter for height above ground in reference
> to an external DEM?
> >
> > Doug
> >
> > On Wed, Sep 2, 2015 at 8:10 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
> >
> > On Wed, Sep 2, 2015 at 5:16 PM, Andrew Bell <andrew.bell.ia at gmail.com>
> wrote:
> > >
> > > Here's an example from the test code where I've removed all the stuff
> > > that actually tests.  First we create a point table that's a subclass
> > > of PointTable.  It only supports x, y, and z.  Then we register a
> > > callback to be invoked each time a point is read (it does nothing
> > > other than fetch the data).  I've also annotated the code.
> >
> > Awesome, thanks! The comments are also very helpful.
> >
> > 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).
> >
> > Vaclav
> >
> >
> >
> > --
> > Doug Newcomb
> > USFWS
> > Raleigh, NC
> > 919-856-4520 ext. 14 doug_newcomb at 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.
> > _______________________________________________
> > pdal mailing list
> > pdal at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/pdal
>
>


-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20150903/e45012b5/attachment.html>