[pdal] Metrics calculation

[Peder Axensten]

> On 7 Sep 2020, at 17:56, Howard Butler <howard at hobu.co> wrote:
>
>> On Sep 7, 2020, at 10:33 AM, Peder Axensten <Peder.Axensten at slu.se> wrote:
>>
>> I guess that I would first rewrite the code to take advantage of the pdal ecosystem and then see what happens when I restrict the compiler to C++11 and take it from there. But I dread the moment…
>
> We are very close to going to c++17, and we have tried to do it last release and failed. It was OSX/clang that was the challenge at the time. Maybe it is no longer the case. In my opinion the threshold to open up to C++17 is OSX, Linux, and Windows successful compilation and tests across the compilers available to the Conda CI that PDAL uses. PDAL also uses the same Conda Forge setup for its binary builds.

I am on OSX and use clang, but not Apple’s. I stoped using it a few years ago as it wasn’t ever updated… There are alternatives. I use MacPorts to install a recent clang and libraries (including boost, gdal, and pdal) and keep them updated.


>> I think that for raster_metrics using gdal for raster export is pretty natural? We opted for producing one-band files rather than one multi-band file, as it makes it simpler to see what is what through file name extensions. Separate files for separate things is also important when using make scripts to process many files, as we do.
>
> Seems reasonable. Something like TileDB would also seem to be a good fit, but use what people can consume.
>
>> For text_metrics we felt that using csv-like files fitted the rest of our processing environment best. (Actually we use semicolon delimited files as comma is used as the fractional delimiter of numbers in Swedish typography, sometimes causing unpredictable results with localised software…) As all our field data are circular plots, we look for east, north, and radius in the header line. It would not be difficult to use square or rectangular plots using different tags, but that would be rather hands on? To really generalise, I guess that an area concept would be needed along the lines of the point concept. Then different readers/writers (csv, hdf, json, etc.) and pipes could be implemented in a general way, using dimensions for auxiliary data?
>
> Understood. I am (maybe vainly) hoping for some convenience for other groups such as FUSION and its users who might be looking to leverage PDAL to have the opportunity to get output in formats they can consume.

I can only give my view of our experience. FUSION is not always straightforward to use. Its raster metrics calculation produces output that requires further processing and to calculate metrics for plots you must first prepare individual las files of each plot’s points, if I remember correctly. If there had been metrics calculation in pdal we would not have developed our own tools. Pdal tools that produces metrics in say tif and csv formats would be very straightforward to use in our process chain and having them in the pdal ecosystem would offer greater flexibility.

We use the following stages that are managed by a make script:
1 Normalisation and filtering (las->las, tool in C++).
2 Raster metrics (las->tif, tool in C++).
3 Plot metrics (las+csv->csv, tool in C++).
4 Modelling and variable calculation (tif+csv->tif, tool in R).
5 Merging tif files for each variable (many tif->one tif, in gdal).
6 Evaluation (tool in R).

Using make ensures that all is up to date and also enables parallel processing.

Best regards,

Peder Axensten
Research engineer

Remote Sensing
Department of Forest Resource Management
Swedish University of Agricultural Sciences
SE-901 83 Umeå
Visiting address: Skogsmarksgränd
Phone: +46 90 786 85 00
peder.axensten at slu.se, www.slu.se/srh

The Department of Forest Resource Management is environmentally certified in accordance with ISO 14001.

---
När du skickar e-post till SLU så innebär detta att SLU behandlar dina personuppgifter. För att läsa mer om hur detta går till, klicka här <https://www.slu.se/om-slu/kontakta-slu/personuppgifter/>
E-mailing SLU will result in SLU processing your personal data. For more information on how this is done, click here <https://www.slu.se/en/about-slu/contact-slu/personal-data/>