Spelling check

NEWS.md

@@ -30,7 +30,7 @@
 
 4. The bounding box is updated after `lastransform()` [#270](https://github.com/Jean-Romain/lidR/issues/270)
 
-5. The offsets are updated after `lastransform()` to prevent integer overflow when writting the point cloud in `.las` files [#272](https://github.com/Jean-Romain/lidR/issues/272)
+5. The offsets are updated after `lastransform()` to prevent integer overflow when writing the point cloud in `.las` files [#272](https://github.com/Jean-Romain/lidR/issues/272)
 
 6. Removed deprecated C++ functions `std::bind2nd` as requested by CRAN.
 
@@ -42,7 +42,7 @@
 
 #### FIXES
 
-1. Fix a serious issue of unitialized values in an internal C++ function but this issue is consequentless for the package.
+1. Fix a serious issue of uninitialized values in an internal C++ function but this issue is consequentless for the package.
 
 ## lidR v2.1.1 (Release date: 2019-08-06)
 
@@ -63,7 +63,7 @@
 
 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`.
+2. Internal code has been modified 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
 
@@ -80,7 +80,7 @@
 
 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 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 beginning! For users, restoring the exact former behavior implies only one change.
 
 In versions `< 2.1.0` the following was correct:
 
@@ -91,7 +91,7 @@ opt_cores(ctg) <- 4L
 hmean <- grid_metrics(ctg, mean(Z))
 ```
 
-In versions `>= 2.1.0` this must be explicitely declared with the `future` package:
+In versions `>= 2.1.0` this must be explicitly declared with the `future` package:
 
 ```r
 library(lidR)
@@ -104,7 +104,7 @@ 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](https://github.com/Jean-Romain/lidR/issues/204))
+    * LAS 1.4 and point formats > 6 are now better supported. `lascheck()` and `print()` were updated to work correctly with these formats ([#204](https://github.com/Jean-Romain/lidR/issues/204))
     * New function `readLASheader()` to read the header of a file in a `LASheader` object.
 
 2. Coordinate Reference System:
@@ -171,15 +171,15 @@ hmean <- grid_metrics(ctg, mean(Z))
 
 10. New function `catalog_select` for interactive tile selection.
 
-11. `lasground` have lost the argument `last_returns` for a mor generic argument `filter`. Retro-compatibility as been preserved by interpreting adding an ellipsis.
+11. `lasground` have lost the argument `last_returns` for a more generic argument `filter`. Retro-compatibility as been preserved by interpreting adding an ellipsis.
 
 #### 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.
+3. The documentation of supported options in `tree_*()` functions was incorrect and has been fixed.
 
 4. `readLAScatalog()` replaces `catalog()`. `catalog()` is soft-deprecated.
 
@@ -208,7 +208,7 @@ local maxima and the search step is skipped (much faster)*. This is now true.
 ## lidR v2.0.2 (Release date: 2019-03-02)
 
 - Fix: [#222](https://github.com/Jean-Romain/lidR/issues/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](https://github.com/Jean-Romain/lidR/issues/223) `lasmergespatial()` wrongly copied shapefile attributes to each point when the paramter `attribute` was the name of an attribute of the shapefile.
+- Fix: [#223](https://github.com/Jean-Romain/lidR/issues/223) `lasmergespatial()` wrongly copied shapefile attributes to each point when the parameter `attribute` was the name of an attribute of the shapefile.
 - Fix: [#225](https://github.com/Jean-Romain/lidR/issues/225) `laspulse()`, `lasflightline()`, `lasscanline()` were broken since v2.0.0.
 - Fix: [#227](https://github.com/Jean-Romain/lidR/issues/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](https://github.com/Jean-Romain/lidR/issues/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.
@@ -218,10 +218,10 @@ local maxima and the search step is skipped (much faster)*. This is now true.
 
 - 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: an error occured when plotting a LAScatalog with the option `chunk_pattern = TRUE`: object 'ctg' not found.
 - Fix: examples in documentation of `tin()` and `knnidw()` were inverted.
 - Fix: [#213](https://github.com/Jean-Romain/lidR/issues/213) bug when using option `keep_lowest` in `grid_terrain`.
-- Fix: [#212](https://github.com/Jean-Romain/lidR/issues/212) bug when merging big rasters that exeed the memory allowed by the raster package
+- Fix: [#212](https://github.com/Jean-Romain/lidR/issues/212) bug when merging big rasters that exceed 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
 

R/algorithm-shp.r

@@ -44,7 +44,7 @@
 #' }
 #'
 #' @param th1,th2,th3 numeric. Threshold values (see details)
-#' @param k integer. Number of neighbours used to estimate the neigborhood.
+#' @param k integer. Number of neighbours used to estimate the neighborhood.
 #'
 #' @references
 #' Limberger, F. A., & Oliveira, M. M. (2015). Real-time detection of planar regions in unorganized

R/catalog_apply.r

@@ -34,7 +34,6 @@
 #' processing engine tool is explained in the \link[lidR:LAScatalog-class]{LAScatalog class}\cr\cr
 #' This function is the core of the lidR package. It drives every single function that can process a
 #' \code{LAScatalog}. It is flexible and powerful but also complex and reserved to users that are
-#' confortable with the lidR package.\cr\cr.
 #' \strong{Warning:} the LAScatalog processing engine has a mechanism to load buffered data to avoid
 #' edge artifacts, but no mechanism to remove the buffer after applying user-defined functions, since
 #' this task is specific to each process. In other \code{lidR} functions this task is performed
@@ -98,9 +97,9 @@
 #' \itemize{
 #' \item \code{need_buffer = TRUE} the function complains if the buffer is 0
 #' \item \code{need_output_file = TRUE} the function complains if no output file template is provided
-#' \item \code{raster_alignment = ...} the function checks the aligmnent of the chunks. This option is
+#' \item \code{raster_alignment = ...} the function checks the alignment of the chunks. This option is
 #' important if the output is a raster. See below for more details.
-#' \item \code{drop_null = FALSE} Not intended to be used by regular users. The function doed not
+#' \item \code{drop_null = FALSE} Not intended to be used by regular users. The function does not
 #' remove the NULL outputs.
 #' }
 #'

R/doc-parallelism.R

@@ -8,7 +8,7 @@
 #' @section Algorithm-based parallelism:
 #' When processing a point cloud we are applying an algorithm on data. This algorithm may or may not be
 #' natively parallel. In lidR some algorithms are fully computed in parallel, but some are not because they are
-#' not parallelizable, while some are only partially parallized. It means that some portions of the code
+#' not parallelizable, while some are only partially parallelized. It means that some portions of the code
 #' are computed in parallel and some are not. When an algorithm is natively parallel in lidR it is always
 #' a C++ based parallelization with OpenMP. The advantage is that the computation is faster without any
 #' consequence for memory usage because the memory is shared between the processors In short,
@@ -26,7 +26,7 @@
 #' las <- readLAS("file.las")
 #' dtm <- lastrees(las, li2012())
 #' }
-#' To know which algorithms are paralellized users can refer to the documentation or use the
+#' To know which algorithms are parallelized users can refer to the documentation or use the
 #' function \link{is.parallelised}.
 #' \preformatted{
 #' is.parallel(lmf(2))   #> TRUE
@@ -74,12 +74,12 @@
 #' package handles such cases and chooses by default to give precedence to chunk-based parallelism. In this
 #' case chunks will be processed in parallel and the points will be processed serially. The question
 #' of nested parallel loops is irrelevant. The catalog processing engine has precedence rules that are
-#' guaranteed to avoid nested paralellism. This precedence rule aims to (1) alway work (2) preserve
+#' guaranteed to avoid nested parallelism. This precedence rule aims to (1) always work (2) preserve
 #' behaviors of lidR version 2.0.y.
 #'
 #' @section Nested parallelism - part 2:
-#' We explained rules of precedence. But actually the user can tune the engine more accuratley. Let's
-#' define the folllowing function:
+#' We explained rules of precedence. But actually the user can tune the engine more accurately. Let's
+#' define the following function:
 #' \preformatted{
 #' myfun = function(cluster, ...)
 #' {

R/lasnormalize.r

@@ -44,9 +44,9 @@
 #' @param algorithm a spatial interpolation function. \code{lidR} have \link{tin},
 #' \link{kriging}, \link{knnidw} or a \link[raster:raster]{RasterLayer} representing a digital terrain
 #' model (can be computed with \link{grid_terrain})
-#' @param na.rm logical. When using a \code{RasterLayer} as DTM, by defaut the function fails if a point
+#' @param na.rm logical. When using a \code{RasterLayer} as DTM, by default the function fails if a point
 #' fall in an empty pixel because a Z elevation cannot be NA. If \code{na.rm = TRUE} points with an
-#' elvation of NA are filtered. Becareful this creates a copy of the point cloud.
+#' elevation of NA are filtered. Be careful this creates a copy of the point cloud.
 #'
 #' @template LAScatalog
 #'

R/lasrescale.R

@@ -1,8 +1,8 @@
 #' Rescale and reoffset a LAS object
 #'
 #' Modify the scale factor and the offset of a LAS object. This function modify the header and
-#' recompute the coordinates. Coordinates might be moved by few tenth of millimiters or few
-#' millimiters depending of the accuracy imposed by the user.
+#' recompute the coordinates. Coordinates might be moved by few tenth of millimeters or few
+#' millimeters depending of the accuracy imposed by the user.
 #'
 #' @param las An object of class LAS
 #' @param xscale,yscale,zscale scalar. Can be missing if not relevant.

R/utils_geometry.r

@@ -33,7 +33,7 @@
 #' some regions are sampled twice. For a \code{LASheader} it is computed with the bounding box. The
 #' function \code{npoints} does what the user may expect it to do and the function \code{density} is
 #' equivalent to \code{npoints(x)/area(x)}. As a consequence for the same file \code{area} applied on
-#' a LASheader or on a LAS can return slighly different values.
+#' a LASheader or on a LAS can return slightly different values.
 #'
 #' @param x An object of the class \code{LAS*}.
 #' @param ... unused.

R/utils_metrics.r

@@ -58,12 +58,12 @@
 #' dot before the name. This enables the function to be used without writing parameters. The cost
 #' of such a feature is inflexibility. It corresponds to a predefined behavior (see examples)\cr
 #' \describe{
-#' \item{\code{stdmetrics}}{is a combinaison of \code{stdmetrics_ctrl} + \code{stdmetrics_z} +
+#' \item{\code{stdmetrics}}{is a combination of \code{stdmetrics_ctrl} + \code{stdmetrics_z} +
 #' \code{stdmetrics_i} +  \code{stdmetrics_rn}}
 #' \item{\code{stdtreemetrics}}{is a special function that works with \link{tree_metrics}. Actually,
 #' it won't fail with other functions but the output makes more sense if computed at the
 #' individual tree level.}
-#' \item{\code{stdshapemetrics}}{is a set of eigenvalue based feature decribed in Lucas et al, 2019
+#' \item{\code{stdshapemetrics}}{is a set of eigenvalue based feature described in Lucas et al, 2019
 #' (see references).}
 #' }
 #'

R/utils_raster.r

@@ -43,9 +43,10 @@
 #' than the point cloud
 #' @param raster_list list. List of \code{Raster*} objects
 #' @param file_list list. List of path to \code{Raster*} file
-#' @param vrt charcter. Name of the VRT that must be written
+#' @param vrt character. Name of the VRT that must be written
 #'
 #' @keywords internal
+#' @noRd
 rOverlay = function(las, res, start = c(0,0), buffer = 0)
 {
   if (is(res, "RasterLayer"))