[pdal] Metrics calculation

[Andrew Bell]

On Mon, Aug 31, 2020 at 9:07 AM Peder Axensten <Peder.Axensten at slu.se>
wrote:

> My group produces rasters of forest variables for all of Sweden (height,
> volume, biomass, etc.). We use ALS data that we have our own tools to
> filter and produce metrics (percentiles, stddev, etc.) from. These tools
> are implemented in C++ and use liblas to read and write laz-files, but as
> there is no active development on liblas anymore we would like to move our
> tools to use PDAL instead. It would probably be easier to use pdal just for
> reading/writing laz files, but we see obvious advantages with going all the
> way and implement the tools as full members of the pdal ecosystem.
>
> Being new to PDAL I would very much appreciate any input on how to make
> this transition.
>
> 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?

It compiles and when I execute “pdal —drivers” there is a
> writers.gdal.metrics item in the list. However, when I execute “pdal
> —options writers.gdal.metrics” I only get "Unable to create stage
> writers.gdal.metrics”. Before I start to change the actual code into
> general metrics calculation I want a way to run it and getting —options to
> work seemed the obvious start. Once that works the idea is to construct a
> simple pipe through my writer so I can start to incrementally change the
> code.
> Q2: With —options, am I missing something that is obvious to you? Why the
> "Unable to create stage writers.gdal.metrics”?
>

A stage name can't contain a "." It must start with a letter or number.
Subsequent characters can be a letter, number or underscore.  If you're
building a plugin, check the FAQ to make sure it follows the filename rules
and location.

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.


> 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.
>

Great.

Note that the next release will contain more general raster support - you
will be able to create a raster internally and write it out with a raster
writer. This separates the calculation of the raster from the output. That
said, there are limitations WRT output bands, and if writers.gdal does what
you want, you can continue to use that.

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200831/00f3d7f4/attachment.html>