Contents
This tutorial will be presented in two parts -- the first being an introduction to the command-line utilities that can be used to perform processing operations with PDAL, and the second being an introductory C++ tutorial of how to use the PDAL API <cppapi> to accomplish similar tasks.
PDAL is both a C++ library and a collection of command-line utilities for data processing operations. While it is similar to LAStools in a few aspects, and borrows some of its lineage in others, the PDAL library is an attempt to construct a library that is primarily intended as a data translation library first, and a exploitation and filtering library second. PDAL exists to provide an abstract API for software developers wishing to navigate the multitude of point cloud formats that are out there. Its value and niche is explicitly modeled after the hugely successful GDAL library, which provides an abstract API for data formats in the GIS raster data space.
Our first example to demonstrate PDAL's utility will be to simply query an ASPRS LAS file to determine the data that are in it in the very first point.
Note
The interesting.las file in these examples can be found on github.
JavaScript JSON output of point 0.
$ pdal info interesting.las -p 0{
"X": "637012.23999999999",
"Y": "849028.31000000006",
"Z": "431.66000000000003",
"Intensity": "143",
"ReturnNumber": "1",
"NumberOfReturns": "1",
"ScanDirectionFlag": "1",
"EdgeOfFlightLine": "0",
"Classification": "1",
"ScanAngleRank": "-9",
"UserData": "132",
"PointSourceId": "7326",
"Time": "245380.78254962614",
"Red": "68",
"Green": "77",
"Blue": "88"
}The pdal info command can also compute statistics about a PDAL-readable datasource. Simply issuing the command will cause PDAL to read through the data and report those statistics:
{
"filters.stats":
{
"statistic": [
{
"average":
{
"description":"average",
"type":"double",
"value":"637296.73518309835"
},
"count":
{
"description":"count",
"type":"nonNegativeInteger",
"value":"1065"
},
"maximum":
{
"description":"maximum",
"type":"double",
"value":"638982.55000000005"
},
"minimum":
{
"description":"minimum",
"type":"double",
"value":"635619.84999999998"
},
"name":
{
"description":"name",
"type":"string",
"value":"X"
},
"position":
{
"type":"nonNegativeInteger",
"value":"0"
}
},
{
"average":
{
"description":"average",
"type":"double",
"value":"851249.53848826292"
},
"count":
{
"description":"count",
"type":"nonNegativeInteger",
"value":"1065"
},
"maximum":
{
"description":"maximum",
"type":"double",
"value":"853535.43000000005"
},
"minimum":
{
"description":"minimum",
"type":"double",
"value":"848899.70000000007"
},
"name":
{
"description":"name",
"type":"string",
"value":"Y"
},
"position":
{
"type":"nonNegativeInteger",
"value":"1"
}
},
...Conversion of one file format to another can be a hairy topic. You should expect leakage of details of data in the source format as it is converted to the destination format. metadata, file organization, and data themselves may not be able to be represented as you move from one format to another. Conversion is by definition lossy, if not in terms of the actual data themselves, but possibly in terms of the auxiliary data the format also carries.
It is also important to recognize that both fixed and flexible point cloud formats exist, and conversion of flexible formats to fixed formats will often leak. The dimensions might even match in terms of type or name, but not in terms of width or interpretation.
$ pdal translate interesting.las output.txt"X","Y","Z","Intensity","ReturnNumber","NumberOfReturns","ScanDirectionFlag","EdgeOfFlightLine","Classification","ScanAngleRank","UserData","PointSourceId","Time","Red","Green","Blue"
637012.24,849028.31,431.66,143,1,1,1,0,1,-9,132,7326,245381,68,77,88
636896.33,849087.70,446.39,18,1,2,1,0,1,-11,128,7326,245381,54,66,68
636784.74,849106.66,426.71,118,1,1,0,0,1,-10,122,7326,245382,112,97,114
636699.38,848991.01,425.39,100,1,1,0,0,1,-6,124,7326,245383,178,138,162
636601.87,849018.60,425.10,124,1,1,1,0,1,-4,126,7326,245383,134,104,134
636451.97,849250.59,435.17,48,1,1,0,0,1,-9,122,7326,245384,99,85,95
...The text format, of course, is the ultimate flexible-definition format -- at least for the point data themselves. For the other header information, like the spatial reference system, or the ASPRS LAS UUID, the conversion leaks. In short, you may need to preserve some more information as part of your conversion to make it useful down the road.
It can be expensive to compute statistics about an entire file, and many data types contain header or other summary information that can be read without iterating through the entire data set:
$ pdal info interesting.las --summaryThe full power of PDAL comes in the form of pipeline_command invocations. While translate_command provides some utility as far as simple conversion of one format to another, it does not provide much power to a user to be able to filter or alter data as they are converted. Pipelines are the way to take advantage of PDAL's ability to manipulate data as they are converted. This section will provide a basic example and demonstration of pipeline, but the pipeline document contains more detailed exposition of the topic.
Note
The pipeline_command document contains detailed examples and background information.
The pipeline_command PDAL utility is one that takes in a .xml file containing pipeline <pipeline_command> description that defines a PDAL processing pipeline. Options can be given at each :cpppdal::Stage of the pipeline to affect different aspects of the processing pipeline, and stages may be chained together into multiple combinations to have varying effects.
The following XML document defines a pipeline that takes the file.las ASPRS LAS file and converts it to a new file called output.las.
<?xml version="1.0" encoding="utf-8"?>
<Pipeline version="1.0">
<Writer type="writers.las">
<Option name="filename">
output.las
</Option>
<Reader type="readers.las">
<Option name="filename">
./path/to/my/file.las
</Option>
</Reader>
</Writer>
</Pipeline>