v2.2.0

lidR v2.2.0 (Release date: 2020-01-06)

NEW FEATURES

1. LAScatalog processing engine:

   • catalog_apply() gains an option automerge = TRUE. catalog_apply() used to return a list that had to be merged by the user. This new option allows for automatic merging. This is a fail-safe feature. In the worst case, if the user-defined function returns a non-supported list of objects that cannot be merged it falls back to the former behavior i.e. it returns a list. Thus there is no risk associated with adding the option automerge = TRUE but by defaut it is set to FALSE for retrocompatibility. This might be switched to TRUE in future releases.

   • opt_output_file() now interprets * as {ORIGINALFILENAME} for shorter syntax. The following is now accepted:

   opt_output_file(ctg) <- "/home/user/data/norm/*_norm"  # {*} is valid as well
   # instead of
   opt_output_file(ctg) <- "/home/user/data/norm/{ORIGINALFILENAME}_norm"

   • The engine now supports "alternative directories". This is a very specific and undocumented feature useful in a single case of remote computing. More details on the wiki page.

   ctg = readLAScatalog("~/folder/LASfiles/")
   ctg@input_options$alt_dir = c("/home/Alice/data/", "/home/Bob/remote/project1/data/")

   • LAScatalog modification constraints are now relaxed. It is now possible to add or modify an attribute if this attribute has a name that is not reserved.

   ctg$newattr <- 1 # is now allowed
   ctg$GUID <- TRUE # is still forbidden
   #> Erreur : LAScatalog data read from standard files cannot be modified 

   • The engine supports partial processing. It is possible to flag some files that will, or will not, be processed. These files are not removed from the LAScatalog. They are used to load a buffer, if required, for the files that are actually processed. To activate this option a new boolean attribute named processed can be added in the catalog.

   ctg$processed <- TRUE
   ctg$processed[3:5] <- FALSE

2. 3D rendering:

   • The argument colorPalette of the function plot() for LAS objects is now set to "auto" by default. This allows for this argument to not be specified even when plotting an attribute other than Z, and having an appropriate color palette by default. More interestingly, it will automatically apply a nice color scheme to the point cloud with the attribute 'Classification' following the ASPRS specifications. See #275.

   plot(las)
   plot(las, color = "Intensity")
   plot(las, color = "ReturnNumber")
   plot(las, color = "Classification")

   • In plot.lasmetrics3d() the parameter trim is now set to Inf by default.

3. New function point_metrics() - very similar to grid_metrics() but at the point level. The 'metrics' family is now complete. cloud_metrics() computes user-defined metrics at the point cloud level. grid_metrics() and hexbin_metrics() compute user-defined metrics at the pixel level. voxel_metrics computes user-defined metrics at the voxel level. point_metrics() computes user-defined metrics at the point level.

4. lasnormalize():

   • Gains an argument use_class to control the points used as ground.
   • By default 'ground point' now includes points classified as water by default. This might be useful in regions with a lot of water because in this case lasnormalize() can take forever to run (see #295)).

5. New function sensor_tracking() to retrieve the position of the sensor in the sky.

6. New function lasrangecorrection() to normalize intensity using the sensor position (range correction)

7. catalog_select now also allows files to process to be flagged interactively:

   ctg <- catalog_select(ctg, method = "flag_processed")
   ctg <- catalog_select(ctg, method = "flag_unprocessed")

8. grid_terrain()

   • Have a new argument use_class to control which points are considered as ground points
   • With a LAScatalog it now uses the filter -keep_class by default respecting the classes given in use_class.

CHANGES

1. LAS() now rounds the values to 2 digits if no header is provided to fit with the default header automatically generated. This ensures that a perfectly valid LAS object is built out of external data. This change is made by reference, meaning that the original dataset is also rounded.

   pts <- data.frame(X = runif(10), Y = runif(10), Z = runif(10))
   las <- LAS(pts) # 'las' contains rounded values but 'pts' as well to avoid data copying

2. lasmetrics() is deprecated. All las* functions return LAS objects except lasmetrics(). For consistency across the package lasmetrics() becomes cloud_metrics().

3. grid_metrics3d() and grid_hexametrics() are deprecated. They are renamed voxel_metrics() and hexbin_metrics() for naming consistency.

4. The example dataset Topography.laz is now larger and include attributes gpstime, PointSourceID and some classified lakes.

ENHANCEMENTS

1. Internally the package used a QuadTree as spatial index in versions <= 2.1.3. Spatial index has been rewritten and changed for a grid partition which is twice as fast as the former QuadTree. This change provides a significant boost (i.e. up to two times faster) to many algorithms of the package that rely on a spatial index. This includes lmf(), shp_*(), wing2015(), pmf(), lassmooth(), tin(), pitfree(). Benchmark on a Intel Core i7-5600U CPU @ 2.60GHz × 2.

   # 1 x 1 km, 13 pts/m², 13.1 million points
   set_lidr_threads(n)
   tree_detection(las, lmf(3))
   #> v2.1: 1 core: 80s - 4 cores: 38s
   #> v2.2: 1 core: 38s - 4 cores: 20s
   
   # 500 x 500 m, 12 pt/m², 3.2 million points
   lassnags(las, wing2015(neigh_radii = nr, BBPRthrsh_mat = bbpr_th))
   #> v2.1: 1 core: 66s - 4 cores: 33s
   #> v2.2: 1 core: 43s - 4 cores: 21s
   
   # 250 x 250 m, 12 pt/m², 717.6 thousand points
   lasdetectshape(las3, shp_plane())
   #> v2.1 - 1 cores: 12s - 4 cores: 7s
   #> v2.2 - 1 cores:  6s - 4 cores: 3s

2. Internally the Delaunay triangulation has been rewritten with boost instead of relying on the geometry package. The Delaunay triangulation and the rasterization of the Delaunay triangulation are now written in C++ providing an important speed-up (up to three times faster) to tin(), dsmtin() and pitfree(). However, for this to work, the point cloud must be converted to integers. This implies that the scale factors and offset in the header must be properly populated, which might not be the case if users have modified these values manually or if using a point cloud coming from a format other than las/laz. Benchmark on an Intel Core i7-5600U CPU @ 2.60GHz × 2.

   # 1.7 million ground points
   set_lidr_threads(n)
   grid_terrain(las, 0.5, tin())
   #> v2.1: 1 core: 48s - 4 cores: 37s
   #> v2.2: 1 core: 22s - 4 cores: 20s
   
   # 560 thousand first returns (1.6 pts/m²)
   grid_canopy(las, res = 0.5, dsmtin())
   #> v2.1: 1 core: 8s - 4 cores: 7s
   #> v2.2: 1 core: 3s - 4 cores: 3s
   
   # 560 thousand first returns (1.6 pts/m²)
   grid_canopy(las, res = 0.5, pitfree(c(0,2,5,10,15), c(0, 1.5)))
   #> v2.1: 1 core: 30s - 4 cores: 28s
   #> v2.2: 1 core: 11s - 4 cores: 9s

3. There are more than 100 new unit tests in testthat. The coverage increased from 68 to 87%.

4. The vignette named Speed-up the computations on a LAScatalog gains a section about the possible additional speed-up using the argument select from readLAS().

5. The vignette named LAScatalog formal class gains a section about partial processing.

6. Harmonization and review of the sections 'Supported processing options' in the man pages.

FIXES

1. Several minor fixes in lascheck() for very improbable cases of LAS objects likely to have been modified manually.

2. Fix colorization of boolean data when plotting an object of class lasmetrics3d (returned by voxel_metrics()) #289

3. The LAScatalog engine now calls raster::writeRaster() with NAflag = -999999 because it seems that the default -Inf generates a lot of trouble on windows when building a virtual raster mosaic with gdalUtils::gdalbuildvrt().

4. plot.LAS() better handles the case when coloring with an attribute that has only two values: NA and one other value.

5. lasclip() was not actually able to retrieve the attributes of the Spatial*DataFrame or sf equivalent when using opt_output_file(ctg) <- "/dir/{PLOTID}".

6. lasmergespatial() supports 'on disk' rasters #285 #306

7. opt_stop_early() was not actually working as expected. The processing was aborted without logs. It now prevent the catalog processing engine to stop
   even when an error occurs.

8. In tree_detection() if no tree is found (e.g. in a lake) the function crashed. It now returns an empty SpatialPointDataFrame.

9. The argument keep_lowest in grid_terrain returned dummy output full of NAs because NAs have the precedence on actual numbers.

v2.1.4

lidR v2.1.4 (Release date: 2019-10-15)

NEW FEATURES

1. grid_terrain() gains an argument full_raster = FALSE.

2. lasnormalize() gains an argument ... to tune raster::extract() and use, for example, method = "bilinear".

FIXES

1. In lasground() if last_returns = TRUE and the LAS is not properly populated i.e. no last return, the classification was not actually computed. The expected behavior was to use all the points. This is now the case.

2. lasclip() is now able to clip into a LAS objects using SpatialPoints or sf POINT. It previously worked only into LAScatalog objects.

3. lasaddextrabyte_manual() was not actually working because the type was not converted to a numeric value according to the LAS specifications.

4. Fix double precision floating point error in grid_* function in some specific cases. This fix affect also highest() and other raster-based algorithms #273.

5. lasreoffset() now checks for integer overflow and throws an error in case of invalid user request #274.

6. Tolerance for internal point_in_triangle() have been increased to fix double precision error in rasterization of a triangulation. This fixes some rare NAs in pitfree(), dsmtin() and tin().

7. The NAs are now correctly interpreted when writing a GDAL virtual raster #283.

8. Fix lasmergespatial() with 'on disk' rasters #285.

9. Fix pitfree() with a single triangle case #288.

ENHANCEMENTS

1. pitfree() handles more errors and fails more nicely in some specific cases #286.

v2.1.3

lidR v2.1.3 (Release date: 2019-09-10)

NEW FEATURES

1. New functions lasrescale() and lasreoffset() to modify the scale factors and the offsets. The functions update the header and recompute the coordinates to get the proper rounded values in accordance with the new header.

2. readLAS() throw (again) warnings for invalid files such as files with invalid scale factors, invalid bounding box, invalid attributes ReturnNumber and so on.

ENHANCEMENT

1. readLAScatalog() is 60% faster

2. The progress bar of the LAScatalog processing engine has been removed in non interactive sessions and replaced by regular but more informative prints. This allows to track the state of the computation with a stream redirection to a file when running a script remotely for example.

   R -f script.R &> log.txt &
   

FIXES

1. Fix an infinite loop in the knn search when k > number of points. This bug may affect lasdetectectshape(), wing2012() and other functions that rely on a knn search.

2. Using remote futures now works for any function that supports a LAScatalog input. Previously remote evaluation of futures failed because of the presence of return() statement in the code future#333

   plan(remote, workers = "132.203.41.25")

3. lasclipCircle() behaves identically for LAS and LAScatalog object. It now returns the points that are strictly inside the circle. Previously for LAS objects it also returned the point belonging on the disc.

4. The bounding box is updated after lastransform() #270

5. The offsets are updated after lastransform() to prevent integer overflow when writing the point cloud in .las files #272

6. Removed deprecated C++ functions std::bind2nd as requested by CRAN.

NOTE

1. All C++ source code has been reworked in a tidy framework to clean-up 4 years of mess. It is almost invisible for regular users but the size of the package has been reduced of several MB and many new tools will now be possible to build.

V2.1.1

lidR v2.1.1 (Release date: 2019-08-06)

NEW FEATURES

1. #266 lasmetrics has now a dispatch to LAS and LAScluster cluster objects. It means that lasmetrics can be used with catalog_apply in some specific cases where it has a meaning (see also #266):

opt_chunk_buffer(ctg) <- 0
opt_chunk_size(ctg) <- 0
opt_filter(ctg) <- "-keep_first"
opt_output_files(new_ctg) <- ""
output <- catalog_apply(new_ctg, lasmetrics, func = .stdmetrics)
output <- data.table::rbindlist(output)

ENHANCEMENT

1. lastrees now uses S3 dispatcher system. When trying to use it with a LAScatalog object, user will have a standard R message to state that LAScatalog is not supported instead of an uninformative message that state that 'no slot of name "header" for this object of class "LAScatalog"'

2. Internal code has been modifiy to drastically reduce probability of name intersection in catalog_apply(). For example, the use of a function that have a parameter p in catalog_apply() failed because of partial matching between the true argument p and the internal argument processing_option.

3. lasfilterdecimate with algorithm highest is now more than 20 times faster. lasfiltersurfacepoints, being a proxy of this algorithm, had the same speed-up

4. plot for LAS objects gained the pan capability.

FIXES

1. #267. A dummy character was introduced by mistake in a variable name breaking the automatic exportation of user object in grid_metrics when used with a parallelized plan (tree_metrics was also affected).

v2.1.0

lidR v2.1.0

VISIBLE CHANGES

Several algorithms are now natively parallelized at the C++ level with OpenMP. This has for consequences for speed-up of some computations by default but implies visible changes for users. For more details see help("lidR-parallelism"). The following only explains how to modify code to restore the exact former behavior.

In versions < 2.1.0 the catalog processing engine has R-based parallelism capabilities using the future package. The addition of C++-based parallelism introduced additional complexity. To prevent against nested parallelism and give the user the ability to use either R-based or C++-based parallelism (or a mix of the two), the function opt_cores() is no longer supported. If used it generates a message and does nothing. The strategy used to process the tiles in parallel must now be explicitly declared by users. This is anyway how it should have been designed from the begining! For users, restoring the exact former behavior implies only one change.

In versions < 2.1.0 the following was correct:

library(lidR)
ctg <- catalog("folder/")
opt_cores(ctg) <- 4L
hmean <- grid_metrics(ctg, mean(Z))

In versions >= 2.1.0 this must be explicitely declared with the future package:

library(lidR)
library(future)
plan(multisession)
ctg <- catalog("folder/")
hmean <- grid_metrics(ctg, mean(Z))

NEW FEATURES

1. readLAS():

   • LAS 1.4 and point formats > 6 are now better suported. lascheck() and print() were updated to work correctly with these formats (#204)
   • New function readLASheader() to read the header of a file in a LASheader object.

2. Coordinate Reference System:

   • New function wkt() to store a WKT CRS in a LAS 1.4 file. This function is the twin of epsg() to store CRS. It updates the proj4string and the header of the LAS object. This function is not expected to be used by users. Users must prefer the new function projection() instead.
   • New function projection<- that updates both the slot proj4string and the header with an EPSG code or a WKT string from a proj4string or a sp:CRS object. This function supersedes epsg()and wkt() that are actually only useful internally and in specific cases. The vignette LAS-class has been updated accordingly.

   projection(las) <- projection(raster)

3. LAScatalog processing engine:

   • Progression estimation displayed on a map now handles warnings by coloring the chunks in orange.
   • Progression estimation displayed on a map now colors in blue the chunks that are processing.
   • The engine now returns the partial result in case of a fail.
   • The engine now has a log system to help users reload the chunk that throws an error and try to understand what going wrong with this cluster specifically. If something went wrong a message like the following is displayed:

   An error occurred when processing the chunk 190. Try to load this chunk with:
   chunk <- readRDS("/tmp/RtmpAlHUux/chunk190.rds")
   las <- readLAS(chunk)
   

4. grid_metrics():

   • New function stdshapemetrics() and lazy coding .stdshapemetrics to compute eigenvalue-related features (#217).
   • New argument filter in grid_metrics(). This argument enables users to compute metrics on a subset of selected points such as "first returns", for example, without creating a copy of the point cloud. Such an argument is expected to be added later in several other functions.

   hmean <- grid_metrics(las, ~mean(Z), 20, filter = ~ReturnNumber == 1)

5. New functions lasdetectshape() for water and human-made structure detection with three algorithms shp_plane(), shp_hplane(), shp_line().

6. plot():

   • For LAS objects plot() gained an argument axis = TRUE to display axis.
   • For LAS objects plot() gained an argument legend = TRUE to display color gradient legend (#224).

7. tree_hull():

   • Gained an argument func to compute metrics for each tree, like tree_metrics()

   convhulls <- tree_hulls(las, func = ~list(imean = mean(Intensity)))

8. Miscellaneous tools:

   • The function area() has been extended to LASheader objects.
   • New functions npoints() and density() available for LAS, LASheader and LAScatalog objects that return what users may expect.

   las    <- readLAS("file.las", filter = "-keep_first")
   header <- readLASheader(file)
   ctg    <- catalog("folder/")
   
   npoints(las)    #> [1] 55756
   npoints(header) #> [1] 81590
   npoints(ctg)    #> [1] 1257691
   
   density(las)    #> [1] 1.0483
   density(header) #> [1] 1.5355
   density(ctg)    #> [1] 1.5123

9. Several functions are natively parallelized at the C++ level with OpenMP. See help("lidR-parallelism") for more details.

10. New function catalog_select for interactive tile selection.

NOTE

1. grid_metrics(), grid_metrics3d(), tree_metrics(), tree_hull(), grid_hexametrics() and lasmetrics() expect a formula as input. Users should not write grid_metrics(las, mean(Z)) but grid_metrics(las, ~mean(Z)). The first syntax is still valid, for now.

2. The argument named field in tree_metrics() is now named attribute for consistency with all other functions.

3. The documentation of supported options in tree_*() functions was inccorect and has been fixed.

4. readLAScatalog() replaces catalog(). catalog() is soft-deprecated.

FIX

1. #264 grid_terrain now filter degenerated ground points.

v2.0.3

lidR v2.0.3 (Release date: 2019-05-08)

• Fix: in li2012() the doc states that If R = 0 all the points are automatically considered as
  local maxima and the search step is skipped (much faster). This is now true.
• Fix: in lasmergespatial used with a SpatialPolygonDataFrame when the bounding boxes do not match the full search was performed uselessly. Now the function exits early without searching anything.
• Fix: #242 on Windows when using multicore options to process a LAScatalog the parameter of the algorithms were not exported to each session.
• Enhance: internally the function tsearch that searches in a triangulation is 25% faster giving a small speed-up to pitfree() and tin() algorithms.
• Enhance: in lasmergespatial used with a SpatialPolygonDataFrame the function checks the bounding box of the polygon to speed-up the computation with complex polygons.
• Doc: add a ?lidR page to the manual.

v2.0.2

lidR v2.0.2 (Release date: 2019-03-02)

• Fix: #222 grid_*() functions return consistently a RasterLayer if there is a single layer. virtual raster mosaic were returned as RasterStack no matter the number of layers.
• Fix: #223 lasmergespatial() wrongly copied shapefile attributes to each point when the paramter attribute was the name of an attribute of the shapefile.
• Fix: #225 laspulse(), lasflightline(), lasscanline() were broken since v2.0.0.
• Fix: #227 When processing a LAScatalog the chunks are better computed. In former version it was possible to have chunks that lie on tile only because of the buffer. These chunks are not build anymore.
• Fix: #227 When processing a LAScatalog some chunks may belong in a file/tile but when actually reading the points in the file the chunks could be empty with points only in the buffer region. In these case an empty point cloud is returned and the computation is be skipped.
• Fix: #228 lasmergespatial() and lasclip() loose precision when extracting polygons due to missing digits in the WKT string used to rebuild the polygons at C++ level.

v2.0.1

lidR v2.0.1 (Release date: 2010-02-02)

• Change: the function catalog has been slightly modified in prevision of the release of the package rlas 1.3.0 to preserve future compatibility. This is invisible for the users.
• New: lasnormalize gained a parameter na.rm = TRUE
• Fix: an error occurend when plotting a LAScatalog with the option chunk_pattern = TRUE: objet 'ctg' introuvable.
• Fix: examples in documentation of tin() and knnidw() were inverted.
• Fix: #213 bug when using option keep_lowest in grid_terrain.
• Fix: #212 bug when merging big rasters that exeed the memory allowed by the raster package
• Fix: bug when merging rasters when some of then only have one cell
• Fix: bug when printing a 0 point LAS object

v2.0.0

lidR v2.0.0 (Release date: 2019-01-02)

Why versions > 2.0 are incompatible with versions 1.x.y?

The lidR package versions 1 were mainly built upon "personal R scripts" I wrote 3 years ago. These scripts were written for my own use at a time when the lidR package was much smaller (both in term of code and users). The lidR package became a relatively large framework built on top of an unstructured base so it became impossible to develop it further. Many features and functions were missing because the way lidR was built did not allow them to be written. The new release (lidR version 2) breaks the former code to build a more robust, more consistent and more scalable framework that is intended and expected to continue for years without the need to break anything more in the future.

Old binaries can still be found here for 6 months:

• Windows R-3.6
• Windows R-3.5
• Windows R-3.4
• Mac OSX R-3.5
• Mac OSX R-3.4

Overview of the main visible changes

lidR as a GIS tool

lidR versions 1 was not a GIS tool. For example, rasterization functions such as grid_metrics() or grid_canopy() returned a data.frame. Tree tops extraction with tree_detection() also returned a data.frame. Tree segmentation with lastrees() accepted RasterLayer or data.frame as input in a very inconsistent way. Moreover, the CRS of the point cloud was useless and never propagated to the outputs because outputs were not spatial objects.

lidR version 2 consistently uses Raster* and Spatial* objects everywhere. Rasterization functions such as grid_metrics() or grid_canopy() return Raster* objects. Tree tops extraction returns SpatialPointDataFrame objects. Tree segmentation methods accept SpatialPointDataFrame objects only in a consistent way across functions. The CRS of the point cloud is always propagated to the outputs. LAS objects are Spatial objects. LAScatalog objects are SpatialPolygonDataFrame objects. In short, lidR version 2 is now a GIS tool that is fully compatible with the R ecosystem.

No longer any update by reference

Several lidR functions used to update objects by reference. In lidR versions 1 the user wrote: lasnormalize(las) instead of las2 <- lasnormalize(las1). This used to make sense in R < 3.1 but now the gain is no longer as relevant because R makes shallow copies instead of deep copies.

To simplfy, let's assume that we have a 1 GB data.frame that stores the point cloud. In R < 3.1 las2 was a copy of las1 i.e. las1 + las2 = 2GB . This is why we made functions that worked by reference that implied no copy at all. This was memory optimized but not common or traditional in R. The question of memory optimization is now less relevant since R >= 3.1. In the previous example las2 is no longer a deep copy of las1, but a shallow copy. Thus lidR now consistently uses the traditional syntax y <- f(x).

Algorithm dispatch

The frame of lidR versions 1 was designed at a time when there were fewer algorithms. The increasing number of algorithms led to inconsistent ways to dispatch algorithms. For example:

• grid_canopy() implemented one algorithm and a second function grid_tincanopy() was created to implement another algorithm. With two functions the switch was possible by using two different names (algorithms dispatched by names).
• grid_tincanopy() actually implemented two algorithms in one function. The switch was possible by changing the input parameters in the function (algorithm dispatched by input).
• lastrees() had several variants that provided access to several algorithms: lastrees_li(), lastrees_dalpontes(), lastrees_watershed(), and so on. With several functions the switch was possible by using several different names (algorithms dispatched by names).
• tree_detection did not have several variants, thus it was impossible to introduce a new algorithm (no dispatch at all).

lidR version 2 comes with a flexible and scalable dispatch method that unifies all the former functions. For example, grid_canopy() is the only function to make a CHM. There is no longer the need for a second function grid_tincanopy(). grid_canopy() unifies the two functions by accepting as input an algorithm for a digital surface model:

chm = grid_canopy(las, res = 1, algo = pitfree())
chm = grid_canopy(las, res = 1, algo = p2r(0.2))

The same idea drives several other functions including lastrees, lassnags, tree_detection, grid_terrain, lasnormalize, and so on. Examples:

ttops = tree_detection(las, algo = lmf(5))
ttops = tree_detection(las, algo = lidRplugins::multichm(1,2))
lastrees(las, algo = li2012(1.5, 2))
lastrees(las, algo = watershed(chm))
lasnormalize(las, algo = tin())
lasnormalize(las, algo = knnidw(k = 10))

This allows lidR to be extended with new algorithms without any restriction either in lidR or even from third-party tools. Also, how lidR functions are used is now more consistent across the package.

LAScatalog processing engine

lidR versions 1 was designed to run algorithms on medium-sized point clouds loaded in memory but not to run algorithms over a set of files covering wide areas. In addition, lidR 1 had a poorly and inconsistently designed engine to process catalogs of las files. For example:

• It was possible to extract a polygon of points from a LAScatalog but not multipart-polygons or polygons with holes. This was only possible with LAS objects i.e loaded in memory (inconsistent behaviors within a function).
• It was possible to run grid_metrics() on a LAScatalog i.e. over a wide area not loaded in memory, but not lasnormalize, lasground or tree_detection (inconsistent behavior across the functions).

lidR version 2 comes with a powerful and scalable catalog processing engine. Almost all the lidR functions can be used seamlessly with either LAS or LAScatalog objects. The following chunks of code are now possible:

ctg = catalog("folfer/to/las/file")
opt_output_file(ctg) <- "folder/to/normalized/las/files/{ORIGINALFILENAME}_normalized"
new_ctg = lasnormalize(ctg, algo = tin())

Complete description of visible changes

LAS class

• Change: the LAS class is now a Spatial object or, more technically, it inherits a Spatial object.
• Change: being a Spatial object, a LAS object no longer has a @crs slot. It has now a slot @proj4string that is accessible with the functions raster::projection or sp::proj4string
• New: being a Spatial object, a LAS object inherits multiple functions from raster and sp, such $ and [[ accessors or raster::extent, sp::bbox, raster::projection, and so on. However, the replacement method $<-, [[<- have restricted capabilities to ensure a LAS object cannot be modified in a way that implies loosening the properties of the LAS specifications.
• New: empty LAS objects with 0 points are now allowed. This has repercussions for several functions including lasfilter, lasclip, and readLAS that do not return NULL for empty data but a LAS object with 0 points. This new behavior has been introduced to fix the old inconsistent behavior of functions that return either LAS or NULL objects. LAS objects are always returned.

LAScatalog class

• Change: the LAScatalog class is now a SpatialPolygonsDataFrame or, more technically, it inherits a SpatialPolygonsDataFrame.
• Change: being a SpatialPolygonsDataFrame object, a LAScatalog no longer has a @crs slot. It has now a slot @proj4string that is accessible with the functions raster::projection or sp::proj4string.
• Change: being a SpatialPolygonsDataFrame a LAScatalog can be plotted with sp::spplot().
• Change: there are no longer any slots @cores, @by_file, @buffer, and so on. They are replaced by more generic and scalable slots @processing_options, @output_options, @clustering_options and @input_options that are list of options classified by their main roles.
• Change: documentation has been entirely rewritten to explain the whole potential of the class.
• Change: functions by_file, progress, tiling_size, buffer were replaced by opt_chunk_size, opt_chunk_buffer, opt_progress, and so on. These allow for a consistent set of functions that do not overlap with functions from raster or sp.
• Change: standard column names were renamed to make syntactically-valid names and for compatibility with sp functions.

readLAS

• Change: readLAS no longer supports option PFC. Users must use the functions laspulse, lasflightlines manually.

lasclip

• New: lasclip now works both with a LAS object and a LAScatalog object in a seamless and consistent way. There are no longer any differences between the capabilities of the LAS version or the LAScatalog one.
• New: lasclip support many geometries including multipart polygons and polygons with holes, both with a LAS object and a LAScatalog object.
• Change: The option inside has been removed for consistency because it cannot be safely supported both on LAS and LAScatalog.
• Change: The option ofile has been removed for consistency and this option in now managed by the LAScatalog processing engine. For example, one can extract ground inventories and write them in laz files automatically named after their center coordinates like this:

ctg = catalog(folder)
output_files(ctg) <- "path/to/a/file_{XCENTER}_{YCENTER}"
laz_compression(ctg) <- TRUE
n...

v1.6.1

lidR v1.6.1 (2018-08-21)

BUG FIXES

• [#161] Fix tree ID matching.
• Fix undefined variable in cluster_apply on mac and linux if multicore processing is used.
• Fix rare case of unit test failure due to the random nature of the test dataset using seeds.
• [#165] Unexported function in catalog_apply on Windows.