[pdal] [EXTERNAL] Re: Migrating from libLAS

Thu Sep 3 14:33:36 PDT 2015

Howard,

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.

I haven't tested this scenario though.
----
Michael Smith
US Army Corps
Remote Sensing GIS/Center
michael.smith at usace.army.mil

From: <pdal-bounces at lists.osgeo.org<mailto:pdal-bounces at lists.osgeo.org>> on behalf of "Newcomb, Doug" <doug_newcomb at fws.gov<mailto:doug_newcomb at fws.gov>>
Date: Thursday, September 3, 2015 at 5:14 PM
To: Howard Butler <howard at hobu.co<mailto:howard at hobu.co>>
Cc: pdal <pdal at lists.osgeo.org<mailto:pdal at lists.osgeo.org>>
Subject: [EXTERNAL] Re: [pdal] Migrating from libLAS
Resent-From: Michael Smith <michael.smith at usace.army.mil<mailto:michael.smith at usace.army.mil>>

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<BlockedBlockedhttp://r.inBlocked> 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<mailto: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<mailto: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<mailto:wenzeslaus at gmail.com>> wrote:
>
> On Wed, Sep 2, 2015 at 5:16 PM, Andrew Bell <andrew.bell.ia at gmail.com<mailto: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<mailto: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<mailto:pdal at lists.osgeo.org>
> BlockedBlockedhttp://lists.osgeo.org/mailman/listinfo/pdalBlocked

--
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb at fws.gov<mailto: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/7ac1604b/attachment-0001.html>