[pdal] [EXTERNAL] Re: Migrating from libLAS

Thu Sep 3 14:43:16 PDT 2015

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 :-)

Doug

On Thu, Sep 3, 2015 at 5:33 PM, Smith, Michael ERDC-RDE-CRREL-NH <
Michael.Smith at erdc.dren.mil> wrote:

> 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> on behalf of "Newcomb, Doug" <
> doug_newcomb at fws.gov>
> Date: Thursday, September 3, 2015 at 5:14 PM
> To: Howard Butler <howard at hobu.co>
> Cc: pdal <pdal at lists.osgeo.org>
> Subject: [EXTERNAL] Re: [pdal] Migrating from libLAS
> Resent-From: Michael Smith <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 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
>> > BlockedBlockedhttp://lists.osgeo.org/mailman/listinfo/pdalBlocked
>>
>>
>
>
> --
> 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.
>
>

-- 
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/40d256a1/attachment.html>