[pdal] Metrics calculation
Howard Butler
howard at hobu.co
Mon Sep 7 08:56:53 PDT 2020
> 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 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.
More information about the pdal
mailing list