lidR (version 4.1.2)

track_sensor: Reconstruct the trajectory of the LiDAR sensor using multiple returns

Description

Use multiple returns to estimate the positioning of the sensor by computing the intersection in space of the line passing through the first and last returns. To work, this function requires a dataset where the 'gpstime', 'ReturnNumber', 'NumberOfReturns' and 'PointSourceID' attributes are properly populated, otherwise the output may be incorrect or weird. For LAScatalog processing it is recommended to use large chunks and large buffers (e.g. a swath width). The point cloud must not be normalized.

Usage

track_sensor(
  las,
  algorithm,
  extra_check = TRUE,
  thin_pulse_with_time = 0.001,
  multi_pulse = FALSE
)

Value

An sf object with POINT Z geometries. Information about the time interval and the score of the positioning (according to the method used) are also in the table of attributes.

Arguments

las

An object of class LAS or LAScatalog.

algorithm

function. An algorithm to compute sensor tracking. lidR implements Roussel2020 and Gatziolis2019 (see respective documentation and examples).

extra_check

boolean. Datasets are rarely perfectly populated, leading to unexpected errors. Time-consuming checks of data integrity are performed. These checks can be skipped as they account for an significant proportion of the computation time. See also section 'Tests of data integrity'.

thin_pulse_with_time

numeric. In practice, it is not useful to compute the position using all multiple returns. It is more computationally demanding but not necessarily more accurate. This keeps only one pulse every x seconds. Set to 0 to use all multiple returns. Use 0 if the file has already been read with filter = "-thin_pulses_with_time 0.001".

multi_pulse

logical. TRUE only for systems with multiple pulses. Pulse ID must be recorded in the UserData attribute.

Non-supported LAScatalog options

The option `select` is not supported and not respected because it is internally known what is the best to select
The option `output_files` is not supported and not respected because the output must be post-processed as a whole

Test of data integrity

In theory, sensor tracking is a simple problem to solve as long as each pulse is properly identified from a well-populated dataset. In practice, many problems may arise from datasets that are populated incorrectly. Here is a list of problems that may happen. Those with a * denote problems already encountered and internally checked to remove weird points:

• 'gpstime' does not record the time at which pulses were emitted and thus pulses are not identifiable

• *A pulse (two or more points that share the same gpstime) is made of points from different flightlines (different PointSourceID). This is impossible and denotes an improperly populated PointSourceID attribute.

• 'ReturnNumber' and 'NumberOfReturns' are wrongly populated with either some ReturnNumber > NumberOfReturn or several first returns by pulses

For a given time interval, when weird points are not filtered, the position is not computed for this interval.

Author

Jean-Francois Bourdon & Jean-Romain Roussel

Examples

# A valid file properly populated
LASfile <- system.file("extdata", "Topography.laz", package="lidR")
las = readLAS(LASfile)
#plot(las)

# pmin = 15 because it is an extremely small file
# strongly decimated to reduce its size. There are
# actually few multiple returns
flightlines <- track_sensor(las, Roussel2020(pmin = 15))

plot(las@header)
plot(sf::st_geometry(flightlines), add = TRUE)

#plot(las) |> add_flightlines3d(flightlines, radius = 10)

if (FALSE) {
# With a LAScatalog "-drop_single" and "-thin_pulses_with_time"
# are used by default
ctg = readLAScatalog("folder/")
flightlines <- track_sensor(ctg,  Roussel2020(pmin = 15))
plot(flightlines)
}