Hot answers tagged

5

In lidR package there is a function as.raster which is faster than rasterFromXYZ r <- as.raster(l) If l is several columns wide (more than one metric), the output is a RasterStack instead of a RasterLayer


5

Since the output is a dataframe with X,Y coordinates and a value (V1) column, you can use rasterFromXYZ from the raster package. Then write to GeoTIFF format using writeRaster, also from the raster package. library(lidR) library(raster) LASfile <- "/Users/aaron/Desktop/temp/lidR_gridmetrics/1958-08-53.las" lidar <- readLAS(LASfile) l <- ...


5

This is not natively possible yet in lidR! But R is a programming language so you can write your own algorithm to achieve this task. If you can do that please share with the community it could be useful ;-). I think LAStools has such tool.


5

If you are trying to create a 2.5D digital terrain model (a height field) from a point cloud then there might be two possible problems. Multiple points in the cloud at the same location don't add any information to the data, so are dropped. Multiple points with the same XY location but different Z location (height) are inconsistent with the idea of a planar ...


4

Short answer: No. And more specifically lidR is designed for ALS primarily, if ever I add a function for noise removal it will be for ALS first.


4

Found the answer in the grid_terrain help section "supported processing options": output_files: Return the output in R or write each cluster’s output in a file. Supported templates are ... , ORIGINALFILENAME. This is the solution: opt_output_files(cat) <- paste0(output,"/{ORIGINALFILENAME}")


4

The number of points above the 0.75 quantile is by definition always going be approximately 0.25. The variation you are getting is because if there's only a small number of points then the quantile computation is approximate or there's tied values. Compare: > metrics(runif(1000)) [1] 0.25 > metrics(runif(12)) [1] 0.25 > metrics(runif(13)) [1] 0....


4

lidR should not throw an error for that, at read time. It is invalid but not corrupted so it is readable. However writeLAS do throw an error. You have two solutions. The first one should be preferred in my opinion. Fix your original files with las2las from lastools. las2las should be preferred for every tasks that imply las file processing. Use: las2las -...


4

In the best world the memory allocated to load a las file should be almost equal to the size of the file. But this is not possible especially in R. This is explained in this vignette. It is important to note that R only enables manipulation of 32-bit integers and 64-bit decimal numbers. But the las specification states, for example, that the intensity is ...


3

There is no streaming equivalent of ReturnNumber <= NumberOfReturns I can see some options: I'm pretty sure that the warnings comes from points that have a NumberOfReturns = 0. Thus I would try filter = "-drop_number_of_returns 0". Go to the github repo of the rlas package and open an issue with a feature request. This is not hard to add such filter. ...


3

In your case the filter you are using is a simple one: Classification != 2. And you don't need the ground points at all. You are better to use a streaming filter and a streamed processing. ctg <- catalog("/...2015TestGroup") opt_chunk_size(ctg) <- 0 opt_chunk_buffer(ctg) <- 0 opt_output_files(ctg) <- ".../Outputs/2015nonground/{XLEFT}_{YBOTTOM}...


3

lasfilter will only directly take objects of class LAS (and not LAScatalog) as per the package documentation. One way to go is with catalog_apply: This function gives users access to the LAScatalog processing engine. It allows the application of a user-defined routine over an entire catalog. So, embed lasfilter within a user-defined function and pass it ...


3

The lidR package relies on the rlas package to read and write las file. The rlas package has a recent support of LAS 1.4 files (v1.3.0 release date: 2019-02-03). Moreover the point record formats >6 are a bit different than former point formats. Your code is correct and you actually found a bug in function write.las from rlas that occurs with point format 6 (...


3

You were almost there. You missed to compute the pulseID with laspulse() and you missed that the scan angle is stored in ScanAngleRank Since lidR 2.0.0 pulseID is no longer computed at read time. And since rlas 1.3.0 that introduced support of LAS 1.4 format the attribute ScanAngle is now ScanAngleRank. The name ScanAngle is reserved for angle stored in LAS ...


3

This example is directly from the documentation @JRR provided. You can use writeOGR() from the rgdal package to write the convex hull polygons representing tree canopies to shapefile. library(lidR) library(rgdal) las = readLAS("/path/to/your/points.las") plot(las) # Classify ground points las = lasground(las, csf()) plot(las, color = "Classification") # ...


3

Edit: The package is evolving. As stated in JRR's answer which is one of lidR's authors, newer versions (> 1.5) will support clipping with SpatialPolygonDataFrame. It is also planned to support clipping with multipart polygons. The package ‘lidR’ (version 1.4.2*) pdf says on lasclip: Usage: lasclip(x, geometry, ofile = "") Arguments geometry: a ...


3

You are trying to read the file "ABCD.las" from the package rLiDAR. The package rLiDAR does not have such file. You probably meant something like: readLAS("D:/Thing/Path/ABCD.las") Also you loaded both lidR and rLiDAR that both have a readLAS function that give two different outputs. You are likely to run into trouble using the two packages simultaneously. ...


3

grid_metrics is designed in a way that your expression is evaluated within the frame of the data.table that contains the point cloud. Your function is found within the loaded R packages. Thus your code cannot work for two reasons: f is defined within the frame of get_layer_counts breaks does not exists within the frame of the point cloud This version works:...


3

Your las file has been recorded in a given CRS. If this CRS is correctly recorded into the file, readLAS is expected to find it from the EPSG code. Here you set manually the CRS. However this is only added as a metadata and not used internally (yet). If your point cloud is not aligned with your shapefile it means that at least one of your CRS is not the ...


3

This question has been discussed here. For an unknown reason the payload of the file is offseted to 375 bytes instead of 235 for a LAS 1.3. las0@header@PHB$`Header Size` #> 375 In theory it could be written properly but in practice rlas generates a corrupted file. You must manually fix the header. las0@header@PHB$`Header Size` <- 235


3

It's perfectly valid (although not usual) for the LAS header to contain additional bytes. It seems Trimble always writes 375, no matter if it's LAS 1.2 (227 bytes), LAS 1.3 (235 bytes), or LAS 1.4 (375 bytes). One advantage of this is that the LAS file could be upgraded to LAS 1.4 in place (assuming the point type is kept). However, those additional 140 ...


3

There are several questions here: Why do you have NAs in the DTM? NAs in the DTM are usually not a big deal. lidR interpolates within the convex hull of the point cloud to ensure to have a DTM in accordance with the point cloud especially with circular plots for example. A raster being rectangular you can have NAs in pixels with no points Why do you have -3....


2

Perfect answer by @andre-silva but let met add few informations. In lidR 1.5.0 you will be able to clip using a SpatialPolygonDataFrame. In that case you will get a list of LAS objects (one per polygon). las = readLAS("file.las") spdf <- readOGR(dsn = "...", layer = "...") clipped_las = lasclip(ctg, spdf) Also lasclip will be compatible with a ...


2

You can use the function stdmetrics inside your custom function like in the following example (using stdmetrics_z) myMetrics = function(z, i) { lidrmetrics = stdmetrics_z(z) mymetrics = list( zwimean = sum(z*i)/sum(i), # Mean elevation weighted by intensities zimean = mean(z*i), # Mean products of z by intensity zsqmean = sqrt(mean(z^...


2

Below I give you a more comprehensive answer. But here I suggest a better option in my opinion. In your code, you try to normalize the dataset each time you want to perform the computation. This have a very high cost in term of computation. I recommend to have an already normalized dataset. Normalize your point cloud with LAStools (recommended if you have a ...


2

Your files are invalid with respect of the formal las specification. The header of a file should contains information including the bounding box of the file, the number of point recorded as well as many other informations. Your file header states that the files contain 0 point but it actually contains 3408961 points. You have a warning for that. It means ...


2

According to the LAS specification a las file contains a set of core attributes including X Y Z obviously but also the 'intensity' or the 'classification' and other data for each point. Among the core attributes one of them is the 'return number' that stores the position of the point in the return sequence (see also What are LiDAR returns?). A point with a ...


2

Update: Essentially, I am looking to remove the overlapping points so as to produce a homogeneous point cloud with no scanline overlaps. Besides thinning (Thinning large LiDAR point cloud?), if the .las file is classified (or flagged) as 'overlapping' points one can filter those out on-the-fly while importing data in R. For versions LAS 1.0 to 1.3 (...


2

Your question is related to LAScatalog processing engine tuning. A topic not documented in the official documentation. The only one existing documentation at the time being (june 2019) is a wiki page that provide an example to change the drivers. In short the drivers used to write objects to files are stored in the LAScatalog object. You can access to them ...


2

Seems like I found the solution. I forgot that as from version 2.0 of lidR, point clouds are not passed by reference. Here's the solution: las_tree = lasaddextrabytes(las_tree, name="treeID", desc="ID of a tree")


Only top voted, non community-wiki answers of a minimum length are eligible