<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 31, 2020, at 1:40 PM, Andrew Bell <<a href="mailto:andrew.bell.ia@gmail.com" class="">andrew.bell.ia@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 9:07 AM Peder Axensten <<a href="mailto:Peder.Axensten@slu.se" target="_blank" class="">Peder.Axensten@slu.se</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
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.<br class="">
Q1: Is this a good way to start, do you think? Or should I use something else to start from?<br class=""></blockquote><div class=""><br class=""></div><div class="">Does writers.gdal not already do what you want? What capability is missing, exactly? Specific statistics?</div></div></div></div></blockquote><div><br class=""></div><div>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. <a href="https://github.com/PDAL/PDAL/issues/3215" class="">https://github.com/PDAL/PDAL/issues/3215</a></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Q3: Do you think this is a good way to do the transition to pdal or would you suggest a better way?<br class=""></blockquote><div class=""><br class=""></div><div class="">I don't understand what you're trying to do, exactly, so I can't answer.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br class=""></blockquote><div class=""><br class=""></div><div class="">PDAL targets C++11. If you're making code for the public, it must build under C++11 for now.</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br class=""></blockquote></div></div></div></blockquote><div><br class=""></div><br class=""></div><div>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.</div><div><br class=""></div><div>Howard</div><div><br class=""></div><br class=""></div></body></html>