[pdal] Metrics calculation

[Howard Butler]

> On Aug 31, 2020, at 1:40 PM, Andrew Bell <andrew.bell.ia at gmail.com> wrote:
> 
> 
> On Mon, Aug 31, 2020 at 9:07 AM Peder Axensten <Peder.Axensten at slu.se <mailto:Peder.Axensten at slu.se>> wrote:
> 
> I’ve started with the tool to produce raster metrics. I copied the files for writers.gdal and renamed [what I think is] relevant parts.
> Q1: Is this a good way to start, do you think? Or should I use something else to start from?
> 
> Does writers.gdal not already do what you want? What capability is missing, exactly? Specific statistics?

One of the issues with writers.gdal is its statistics aren't for the cell, but rather for the neighborhood region. This ticket documents the issue, which we can hopefully enhance in a future release. https://github.com/PDAL/PDAL/issues/3215 <https://github.com/PDAL/PDAL/issues/3215>


> 
> Q3: Do you think this is a good way to do the transition to pdal or would you suggest a better way?
> 
> I don't understand what you're trying to do, exactly, so I can't answer.
> 
> We have one tool to produce raster metrics from laz files and another to calculate plot metrics from a set of laz files and a csv file containing coordinates and radius of plots. They are coded in C++17 and structured as a library where the actual tools are rather short files that handles command line options and then make a call into the library. You specify what metrics you need in the command line options (see the —help output below). The library structure makes it pretty straightforward to add yet more metrics. We use a tool implemented in R for the actual modelling/prediction. These tools are executed from a make script to process tens of thousands of files in a paralleled manner.
> 
> PDAL targets C++11. If you're making code for the public, it must build under C++11 for now.

Which C++17 constructs are you using? Just filesystem stuff? PDAL has some utilities to handle filesystem activity to keep the bar at C++11.

>  
> Q4: Would there be a general interest for such drivers (writers.gdal.metrics and writers.text.metrics)? We’d be happy to eventually make the code open source.


There is definitely interest for FUSION-like forestry metrics from a number of PDAL using sub-communities. I think it has been an outstanding question about how those statistics are delivered. For example, what formats are suitable, convenient, and sufficient for per-point or per-cell moments to be passed on to the next consumer in the processing chain. FUSION, for example, generates a blizzard of ascii files of which most do not need to be used. PDAL's metadata system doesn't seem like a good fit for such a thing.

Howard


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200904/048dcbdc/attachment-0001.html>