The answer by Howard Butler pretty much sums it up. Some more background. When I created the first LAStools and the LASlib library that the tools are build upon I was a postdoc at UC Berkeley and merely needed to prepare LAS files as input for my research on Streaming Delaunay (or Streaming TIN) processing. Because the code seemed useful on its own I zipped ...
libLAS was developed to provide read/write support for LAS and it was modeled on LAStools which at the time was not released under an open source license. In the subsequent years, many parts of LAStools were released under an open source license which negated the need for a parallel effort in libLAS. The library portion of this is called LASlib. Yes, I agree ...
You downloaded the source code, not a prebuilt binary.
If you read the PDAL download page you linked to you will see:
Windows builds are available via Conda Forge (64-bit only).
Install Conda (or Miniconda), run a Conda shell, install PDAL with
conda install -c conda-forge pdal
and you should be good to go. See the Conda instructions ...
PDAL doesn't provide anything like FUSION's "GridMetrics" at this time. We've been interested in useful statistics or metrics that PDAL could compute for algorithm builders, but we haven't gotten around to implementing anything yet. It would be straightforward to implement a custom PDAL stage to compute these. It will be more productive to ask on the mailing ...
The PDAL PCD Writer can write .pcd files. For it to work, you must have linked the PCL libraries at compile time. The PDAL OSGeo4W build does not have PCL support. If you are unable to build PDAL with PCL support yourself, one possibility is to use PDAL's Docker containers to achieve your task -- those have PCL linked.
Then, simply run pdal translate:
First, for the answers proposed here, you probably do not want to use the ferry filter to push HeightAboveGround to Z, at least not prior to segmentation, as the act of normalizing heights involves subtracting an interpolated estimate of the ground elevation from each return. Something planar in the original X, Y, Z space may no longer be planar in the ...
After all, it made sense.
A flat plane can have 2 normals. In this case, the slight wobble of the rotating sensor made some points a little above and some points below the average plane. Hence the kind of artifacts you see.
Since we know a roof always has an upward pointing normal, we can check that whenever the normalz is negative, we flip the ...
Seems like you should get to know Python's built-in subprocess module. Among other things, it enables you to make command line calls from inside a script and capture the results.
from shapely.geometry import Polygon
result = subprocess.run(['pdal', 'info', '/path/to/file.ply'],
stderr = subprocess.PIPE,...
I ended up with this solution with PDAL and GDAL:
First I used liblas to create LAS containing only ground points. Then I used PDAL similar to the "Basic Example" but with output_type: max to create a DTM from the terrain LAS and a DSM from the original LAS.
Then just gdal_calc.py with these to elevation models to get a DHM.
gdal_calc.py -A DSM.tif -B ...
In addition to what has been mentioned above, SPDLib is another powerful set of open-source tools for processing LiDAR data (LAS files). It is cross-platform and supports Mac.
The spdinterp program has the capability to generate Canopy Height Models as well as DTMs and DSMs.
1) You can use the the little known Whitebox GAT (Mac version, Download Whitebox Geospatial Analysis Tools), developed for the Java platform (Java Runtime Environment (JRE) version 8.0 or higher installed) and Open Source (GNU General Public License version 3)
Look at Working with LiDAR data in Whitebox GAT
2) You can also use
GRASS GIS (GRASS GIS for ...
The filters.voxelgrid filter requires PCL support, which it doesn't appear you have linked. On OSX, Homebrew PCL (1.7.2) should be sufficient. See my configuration script for hints on how to have CMake use it.
Another easy way to get going with PDAL is to use Docker. It contains a fully-featured PDAL build. The PDAL Docker latest image based on last stable ...
validate does not need to be called on the pipeline to run it and if you comment out pipeline.validate() then the pipeline executes within Python.
This is a bug https://github.com/PDAL/PDAL/issues/2891 where calling validate as it clears the metadata for the stage. This causes an issue with the TileDB driver in that metadata is read/written and required. ...
The las format defines that points have X/Y/Z coordinates and it defines how to include information about georeferencing https://www.asprs.org/wp-content/uploads/2010/12/LAS_1_4_r13.pdf. However, it is not clearly defined what X and Y mean. Traditionally many GIS software consider that X is always longitude or easting and Y is latitude or northing. But ...
You should use min and max property of header.
from laspy.file import File
f = File("path/to/file.laz", mode='r')
h = f.header
# h.min: [min_x, min_y, min_z] - h.max: [max_x, max_y, max_z]
extent = [*h.min, *h.max] # extent: [min_x, min_y, min_z, max_x, max_y, max_z]
There are two additional options to identify trees from canopy height models. Both of these options will identify (mostly) trees, which you can then use as a mask to isolate buildings.
lastrees in the R lidR package. There is a good tutorial on tree
segmentation from the author of the package.
FUSION's TreeSeg algorithm (p.138 documentation)
BPF is rather new as a public format. PDAL supports both reading and writing BPF data. You can use the OSGeo4W64 build of PDAL to translate the data into LAS 1.4 using the following command:
pdal translate simple-extra.bpf out.las \
PDAL will write commonly-named dimensions, such as XYZ into ...
This file is strange.
First, an EPSG code of 0 isn't valid.
Second, SMRF is designed for aerial LiDAR data, not this (bridge superstructure?).
Third, there's a bug in the SMRF knn code that is triggered by this particular point configuration. Please follow https://github.com/PDAL/PDAL/issues/2794 for details.
Perhaps there is something to tune in the PDAL parameters. If tindex does not give good enough result when used like in this tutorial https://pdal.io/workshop/exercises/analysis/boundary/boundary.html then perhaps you could do better by running density https://pdal.io/apps/density.html directly with different --sample_size and --threshold parameters. For ...
My guess would be that the data is unprojected latitude longitude (usually WGS84, EPSG:4326), stored in radians. The precision of the SBET translation is therefore a bit low to give useful coordinates.
0.933 times 180° divided by PI --> 53.457°
-0.159 times 180° divided by PI --> -9.110°
The follow up discussion from this question can be found in github.com/PDAL, issue 1524.
As commented by @abellgithub (mar/17), SBET files do not carry a Coordinate Reference System (CRS) information.
The alternative suggested was to ask the data providers which CRS was used, and then, reproject the SBET file to EPSG:2157.
pdal translate -f filters....
(pdal pipeline readers.las Warning) C:/denoise\lake.las: Found invalid value of '0' for point's return number.
'0' is not a valid return number in LAS, and PDAL is just warning you here about it. It should pass it on through without touching it though.
You could consider using SPDLib, which has a command called spdmetrics. It can be used to simultaneously calculate multiple vegetation metrics and output them in either raster or vector formats (individual polygons).
There is a tutorial available here that explains how the metrics can be calculated and this XML file provides a full list of the metric ...
As commented here, if you get error:
PDAL: Couldn't create writer stage of type writers.pcd
Basically it says, there is no PCL plugin. Hence, you should show library or rebuild PDAL with PCL plugin option to check for build.
There must exist writers.pcd Write data in the Point Cloud Library (PCL) format.
If the plugin ...
This kind of pipeline isn't supported at the moment, but we do have a ticket discussing how to do so.
There's another way that might be relevant to you. You can use the combination of filters.assign and filters.groupby to grab you polygons from an OGR-readable data source. Presumably you're having to do that to get your WKT anyway, so maybe this will make ...
pdal translate requires the filter type voxelgrid.
The correct syntax is as follows:
$ pdal translate -i /Users/aaron/temp/1958-09-54.laz -o /Users/aaron/temp/1958-09-54-thinned.laz voxelgrid --filters.voxelgrid.leaf_x=4.5 --filters.voxelgrid.leaf_y=4.5 --filters.voxelgrid.leaf_z=4.5
Same command with each parameter separated for legibility:
$ pdal ...
As HowardButler stated you need to use the JSON option for any PDAL version over 1.5. I am using PDAL version 1.7.2 and PostGreSQL version 9.6.
1) Create a text file using NotePad as described below. This particular JSON script reads from a standard .LAS file and writes to a PostGreSQL database table. The PostGreSQL database has the pointcloud and postgis ...
This is cross-posted at the PDAL GitHub issue tracker.
If you take a look at this table in the downloads section of the PDAL documentation, you will see that CPD is unfortunately not supported in the Conda package. You will need to build PDAL from source. Dependencies can still be obtained via Conda (although CPD adds a couple of additional dependencies, ...