1r.in.lidar(1) Grass User's Manual r.in.lidar(1)
2
3
4
6 r.in.lidar - Creates a raster map from LAS LiDAR points using univari‐
7 ate statistics.
8
10 raster, import, LIDAR, statistics, conversion, aggregation, binning
11
13 r.in.lidar
14 r.in.lidar --help
15 r.in.lidar [-penosgijdv] [input=name] [output=name] [file=name]
16 [method=string] [type=string] [base_raster=name] [zrange=min,max]
17 [zscale=float] [intensity_range=min,max] [intensity_scale=float]
18 [percent=integer] [pth=integer] [trim=float] [resolution=float]
19 [return_filter=string] [class_filter=integer[,integer,...]]
20 [--overwrite] [--help] [--verbose] [--quiet] [--ui]
21
22 Flags:
23 -p
24 Print LAS file info and exit
25
26 -e
27 Use the extent of the input for the raster extent
28 Set internally computational region extents based on the point
29 cloud
30
31 -n
32 Set computation region to match the new raster map
33 Set computation region to match the 2D extent and resolution of the
34 newly created new raster map
35
36 -o
37 Override projection check (use current location’s projection)
38 Assume that the dataset has same projection as the current location
39
40 -s
41 Scan data file for extent then exit
42
43 -g
44 In scan mode, print using shell script style
45
46 -i
47 Use intensity values rather than Z values
48 Uses intensity values everywhere as if they would be Z coordinates
49
50 -j
51 Use Z values for filtering, but intensity values for statistics
52
53 -d
54 Use base raster resolution instead of computational region
55 For getting values from base raster, use its actual resolution
56 instead of computational region resolution
57
58 -v
59 Use only valid points
60 Points invalid according to APSRS LAS specification will be fil‐
61 tered out
62
63 --overwrite
64 Allow output files to overwrite existing files
65
66 --help
67 Print usage summary
68
69 --verbose
70 Verbose module output
71
72 --quiet
73 Quiet module output
74
75 --ui
76 Force launching GUI dialog
77
78 Parameters:
79 input=name
80 LAS input file
81 LiDAR input files in LAS format (*.las or *.laz)
82
83 output=name
84 Name for output raster map
85
86 file=name
87 File containing names of LAS input files
88 LiDAR input files in LAS format (*.las or *.laz)
89
90 method=string
91 Statistic to use for raster values
92 Options: n, min, max, range, sum, mean, stddev, variance,
93 coeff_var, median, percentile, skewness, trimmean
94 Default: mean
95 n: Number of points in cell
96 min: Minimum value of point values in cell
97 max: Maximum value of point values in cell
98 range: Range of point values in cell
99 sum: Sum of point values in cell
100 mean: Mean (average) value of point values in cell
101 stddev: Standard deviation of point values in cell
102 variance: Variance of point values in cell
103 coeff_var: Coefficient of variance of point values in cell
104 median: Median value of point values in cell
105 percentile: pth (nth) percentile of point values in cell
106 skewness: Skewness of point values in cell
107 trimmean: Trimmed mean of point values in cell
108
109 type=string
110 Type of raster map to be created
111 Storage type for resultant raster map
112 Options: CELL, FCELL, DCELL
113 Default: FCELL
114 CELL: Integer
115 FCELL: Single precision floating point
116 DCELL: Double precision floating point
117
118 base_raster=name
119 Subtract raster values from the Z coordinates
120 The scale for Z is applied beforehand, the range filter for Z
121 afterwards
122
123 zrange=min,max
124 Filter range for Z data (min,max)
125 Applied after base_raster transformation step
126
127 zscale=float
128 Scale to apply to Z data
129 Default: 1.0
130
131 intensity_range=min,max
132 Filter range for intensity values (min,max)
133
134 intensity_scale=float
135 Scale to apply to intensity values
136 Default: 1.0
137
138 percent=integer
139 Percent of map to keep in memory
140 Options: 1-100
141 Default: 100
142
143 pth=integer
144 pth percentile of the values
145 Options: 1-100
146
147 trim=float
148 Discard given percentage of the smallest and largest values
149 Discard <trim> percent of the smallest and <trim> percent of the
150 largest observations
151 Options: 0-50
152
153 resolution=float
154 Output raster resolution
155
156 return_filter=string
157 Only import points of selected return type
158 If not specified, all points are imported
159 Options: first, last, mid
160
161 class_filter=integer[,integer,...]
162 Only import points of selected class(es)
163 Input is comma separated integers. If not specified, all points are
164 imported.
165
167 The r.in.lidar module loads LAS LiDAR point clouds into a new raster
168 map using binning. The user may choose from a variety of statistical
169 methods which will be used for binning when creating the new raster.
170
171 Since a new raster map is created during the binning, the binning of
172 points depends on the current computational region settings (extent and
173 resolution) by default (see more about binning below). When using the
174 -e flag, the binning will be done in the extent of the point cloud, so
175 the resulting raster will have extent based on the input point cloud.
176 When the resolution=value parameter is used, the binning is done using
177 the provided resolution and the resulting raster will have that resolu‐
178 tion (see more below for more information about extent and resolution
179 management).
180
181 r.in.lidar is designed for processing massive point cloud datasets, for
182 example raw LiDAR or sidescan sonar swath data. It has been tested with
183 large datasets (see below for memory management notes).
184
185 Binning
186 The main difference between r.in.lidar and v.in.lidar is that
187 r.in.lidar creates a raster instead of just importing the points into
188 GRASS GIS. However, r.in.lidar does not merely rasterizes the points
189 from the point cloud. r.in.lidar uses binning to derive values for
190 individual raster cells, so the value of a cell is typically an aggre‐
191 gation of values of individual points falling into one cell. In gen‐
192 eral binning is the conversion of points into a regular grid. The bin‐
193 ning of points with X and Y coordinates starts with the overlay of a
194 grid of bins over the points.
195
196 In the basic case, binning is a method which counts the number of
197 points which fall into one raster cell, i.e. bin. The number of points
198 per cell (bin) indicates the density of points in the point cloud. The
199 cell (bin) is always square or rectangular in case of r.in.lidar
200 because the result is GRASS GIS 2D raster. The result of binning where
201 the number of point per cell is counted is sometimes called 2D (two
202 dimensional) histogram because a histogram is used in univariate sta‐
203 tistics (in one dimension) to count the number samples falling into a
204 given bin.
205
206 Figure: The binning on left was used to count number of points per
207 (sometimes also called 2D histogram). The numbers in cells are examples
208 of counts, the rest is represented by the color. The binning on right
209 was used with mean to create a surface based on the values associated
210 with the points. The numbers show examples of cell values. Note also
211 the cells without any points which were assigned the NULL value. The
212 basic concept of binning is extended when the points have another value
213 associated with them. For LiDAR data this value can be the Z coordinate
214 or intensity. The value for a given cell (bin) is computed using uni‐
215 variate statistics from the values of all points in the cell. For
216 example, computing the mean value of Z coordinates can yield a raster
217 representing the digital elevation model. Another example is the range
218 of Z coordinates which can be used as a rough estimate of vegetation
219 height.
220
221 Statistics
222 Available statistics for populating the output raster map are:
223
224 n
225 This computes the number (count) of points per cell. The result is
226 a indicator of spatially variable density of points in the given
227 area.
228
229 min
230 This finds the minimum of point values in each cell. It can be
231 useful when finding topography in a forested or urban environment
232 and there is a lot of points per one cells (terrain is oversampled
233 considering the desired resolution). It can also create surfaces
234 independent on the noise from premature hits as it will always
235 select the lowest point.
236
237 max
238 This finds the maximum of point values in each cell. In connection
239 with base_raster it can yield maximum vegetation of feature height
240 per cell. For this purpose, it is usually much more appropriate
241 than mean which would yield heights mostly influenced by the verti‐
242 cal distribution of points.
243
244 range
245 This computes the range of point values in each cell. The range of
246 Z coordinates per cell can be used as a rough estimate of vegeta‐
247 tion height when the cells are small enough, slopes low and the
248 area is mostly vegetated. However, for more profound analysis, the
249 base raster together with different statistics is recommended.
250
251 sum
252 This computes the sum of point values per cell. This is useful
253 especially when intensity is used as a value (flags -i and -j).
254
255 mean
256 This is a mean (average) value of point values in cell. When used
257 with Z coordinates (the default) and points from the ground class,
258 the resulting raster is a digital elevation model. When intensity
259 is used as a point value, the resulting raster contains mean inten‐
260 sity per cell. Note that mean gives heights influenced by the ver‐
261 tical distribution of points
262
263 stddev
264 This computes the standard deviation of point values for each cell.
265
266 variance
267 This computes the variance of point values for each cell. Variance
268 and derivatives use the biased estimator (n) [note that this might
269 be subject to change].
270
271 coeff_var
272 This computes the coefficient of variance of point values for each
273 cell. Coefficient of variance is given in percentage and defined as
274 (stddev/mean)*100.
275
276 median
277 This computes the median of point values for each cell
278
279 percentile
280 pth (nth) percentile of points in cell
281
282 skewness
283 This is a skewness of point values in cell
284
285 trimmean
286 This is a trimmed mean of point values in cell. Trimmed mean also
287 know as truncated mean is a mean computed after discarding values
288 at the low end and at the high end. How many values to discard is
289 given by the trim option in percent. In statistics the usual per‐
290 centage of trimmed values ranges from 5 to 25 percent. Note that
291 different statistics have different memory requirements (see below
292 for details).
293
294 Filtering
295 Points falling outside the current computational region will be
296 skipped. This includes points falling exactly on the southern region
297 bound. To capture those adjust the region with:
298 g.region s=s-0.000001
299 See g.region for details about computation region handling in GRASS
300 GIS.
301
302 The zrange parameter may be used for filtering the input data by verti‐
303 cal extent. Example uses include filtering out extreme outliers and
304 outliers on relatively flat terrain. This parameter can be also used
305 for cutting the point cloud into vertical sections preparing it for
306 further processing by separate sections, together as if it would be an
307 imagery group (see i.group), or combined into a 3D raster using
308 r.to.rast3. In for these last examples, it might actually be more
309 advantageous to use r3.in.lidar module. The zrange parameter is espe‐
310 cially powerful when used together with the base_raster parameter. The
311 zrange is applied to Z values after the base_raster reduction.
312
313 Figure: This is the principle of zrange filter. Points with the Z
314 coordinate value below the lower value in the range (here 180) are fil‐
315 tered out (blue points) and same applies for points above higher value
316 in the range (here 250). All other points are preserved (green points).
317
318 A LiDAR pulse can have multiple returns. The first return values can be
319 used to obtain a digital surface model (DSM) where e.g. canopy cover is
320 represented. The last return values can be used to obtain a digital
321 terrain model (DTM) where e.g. the forest floor instead of canopy cover
322 is represented. The return_filter option allows selecting one of first,
323 mid, or last returns. Return number and number of returns in the pulse
324 associated with each point are compared to determine if the point is
325 first, mid, or last return.
326
327 LiDAR points often come as already classified into standardized
328 classes. For example, class number 2 represents ground. For other
329 classes see LAS format specification in references. The class_filter
330 option allows selecting one or more classes using numbers (integers)
331 separated by comma.
332
333 In varied terrain the user may find that min maps make for a good noise
334 filter as most LIDAR noise is from premature hits. The min map may also
335 be useful to find the underlying topography in a forested or urban
336 environment if the cells are oversampled.
337
338 The user can use a combination of r.in.lidar output maps to create cus‐
339 tom raster-based filters, for examplee, use r.mapcalc to create a
340 mean-(2*stddev) map. (In this example the user may want to include a
341 lower bound filter in r.mapcalc to remove highly variable points (small
342 n) or run r.neighbors to smooth the stddev map before further use.)
343
344 Note that proper filtering of the input points in not only critical for
345 the analysis itself but it can also speed up the processing.
346
347 Reduction to a base raster
348 For analysis of features on the terrain surface, especially vegetation
349 it is advantageous to remove the influence of the terrain on heights
350 because the height above the terrain is important (e.g. height of a
351 tree) rather than height of the top of the tree above the see level.
352 In this case, the base raster would be digital elevation model which
353 can be one derived from the point cloud, or obtained in some other way.
354 LiDAR data often come with precomputed DEMs (quality should be checked
355 in this case) and there is often a DEM available for a given area (fit
356 with the point cloud, especially vertical, and resolution should be
357 checked).
358
359 Figure: This is a profile of base raster (in orange) representing dig‐
360 ital elevation model and selected points, e.g. first return, from point
361 cloud (green dots). By default the points would create a digital sur‐
362 face model (thin brown line) but after reducing the Z coordinates using
363 the base raster, the created surface is a derived from the height of
364 points relative to the base raster. The usage of base raster is not
365 limited to digital elevation model. The base raster can be any surface
366 which has some relation to the point values, for example digital sur‐
367 face model representing top of the canopy.
368
369 Setting extent and resolution
370 Since the creation of raster maps depends on the computational region
371 settings (extent and resolution), as default the current region extents
372 and resolution are used for the import. When using the -e flag along
373 with the resolution=value parameter, the region used for the new raster
374 will be based the point cloud extent and the provided resolution. It is
375 therefore recommended to first use the -s flag to get the extents of
376 the LiDAR point cloud to be imported, then adjust the current region
377 extent and resolution accordingly, and only then proceed with the
378 actual import. Another option is to automatically set the region
379 extents based on the LAS dataset itself (-e flag) along with the
380 desired raster resolution. The best option is to know the point cloud
381 extent ahead, e.g. from tiling scheme, and use it. See below for
382 details.
383
384 Since the r.in.lidar generates a raster map through binning from the
385 original LiDAR points, the target computational region extent and reso‐
386 lution have to be determined. A typical workflow would involve the
387 examination of the LAS data’s associated documentation or the scan of
388 the LAS data file with r.in.lidar’s -s (or -g) flag to find the input
389 data’s bounds.
390
391 Another option is to automatically set the region extents based on the
392 LAS dataset extent (-e flag) along with the desired raster resolution
393 using the resolution parameter.
394
395 Using the -s scan flag, the extent of the input data (and thus point
396 density) is printed. To check this is recommended before performing the
397 full import. The -g shell style flag prints the extent suitable as com‐
398 mand line parameters for g.region.
399
400 A simpler option is to automatically set the region extents based on
401 the LAS dataset (-e flag) along with the target raster resolution using
402 the resolution parameter. Also here it is recommended to verify and
403 optimize the resulting region settings with g.region prior to importing
404 the dataset.
405
407 Format and projection support
408 The typical file extensions for the LAS format are .las and .laz (com‐
409 pressed). The compressed LAS (.laz) format can be imported only if
410 libLAS has been compiled with LASzip support. It is also recommended to
411 compile libLAS with GDAL which is used to test if the LAS projection
412 matches that of the GRASS location.
413
414 LAS file import preparations
415 Note that the scanning (-s or -g flags) needs to iterate over the whole
416 point cloud. This will take a long time for large datasets, so if the
417 user knows the approximate extent of the dataset, for example because
418 it dataset for one county or tiling scheme is available as vector poly‐
419 gons, it is much more advantageous to provide the extent information
420 instead of retrieving it from the dataset. The same applies to the -e
421 flag which also needs to perform scanning before the binning begins.
422
423 Also note that the scanning does not apply any filters, so the extent
424 determined by scanning can be theoretically bigger than the extent
425 actively used during the binning. This behavior ensures that the newly
426 created raster has always the same extent regardless the filters used.
427 However, for most cases (considering the point cloud and the resolution
428 used) there is no difference between the extent without filters applied
429 and the extent if the filters would be applied.
430
431 Memory consumption
432 While the input file can be arbitrarily large, r.in.lidar will use a
433 large amount of system memory (RAM) for large raster regions (>
434 10000x10000 pixels). If the module refuses to start complaining that
435 there isn’t enough memory, use the percent parameter to run the module
436 in several passes. In addition using a less precise map format (CELL
437 [integer] or FCELL [floating point]) will use less memory than a DCELL
438 [double precision floating point] output map. For method=n, the CELL
439 format is used automatically.
440
441 The mean and range methods will use average amount of memory (comparing
442 to other methods). Methods such as n, min, max, and sum will use less
443 memory, while stddev, variance, and coeff_var will use more.
444
445 The memory usage for regular statistics mentioned above is based solely
446 on region (raster) size. However, the aggregate functions median, per‐
447 centile, skewness and trimmean will use more memory and may not be
448 appropriate for use with arbitrarily large input files without a small
449 value for the percent option because unlike the other statistics memory
450 use for these also depends on the number of data points.
451
452 The default map type=FCELL is intended as compromise between preserving
453 data precision and limiting system resource consumption.
454
455 Trim option
456 Trim option value is used only when calculating trimmed mean values.
457 Attempt to use it with other statistical methods will result in an
458 error.
459
461 Simple example of binning of point from a LAS file into a newly created
462 raster map in an existing location/mapset (using metric units):
463 # set the computational region automatically, resol. for binning is 5m
464 r.in.lidar -e -o input=points.las resolution=5 output=lidar_dem_mean
465 g.region raster=lidar_dem_mean -p
466 r.univar lidar_dem_mean
467
468 Finding suitable extent and resolution
469 Using the -s scan flag, the extent of the input data (and thus point
470 density) is printed. To check this is recommended before performing the
471 full import. The -g shell style flag prints the extent suitable as com‐
472 mand line parameters for g.region.
473
474 A simpler option is to automatically set the region extents based on
475 the LAS dataset (-e flag) along with the target raster resolution using
476 the resolution parameter. Also here it is recommended to verify and
477 optimize the resulting region settings with g.region prior to importing
478 the dataset.
479
480 For the output raster map, a suitable resolution can be found by divid‐
481 ing the number of input points by the area covered (this requires an
482 iterative approach as outlined here):
483 # print LAS metadata (Number of Points)
484 r.in.lidar -p input=points.las
485 # Number of Point Records: 1287775
486 # scan for LAS points cloud extent
487 r.in.lidar -sg input=points.las output=dummy -o
488 # n=2193507.740000 s=2190053.450000 e=6070237.920000 w=6066629.860000 b=-3.600000 t=906.000000
489 # set computation region to this extent
490 g.region n=2193507.740000 s=2190053.450000 e=6070237.920000 w=6066629.860000 -p
491 # print resulting extent
492 g.region -p
493 # rows: 3454
494 # cols: 3608
495 # points_per_cell = n_points / (rows * cols)
496 # Here: 1287775 / (3454 * 3608) = 0.1033359 LiDAR points/raster cell
497 # As this is too low, we need to select a lower raster resolution
498 g.region res=5 -ap
499 # rows: 692
500 # cols: 723
501 # Now: 1287775 / (692 * 723) = 2.573923 LiDAR points/raster cell
502 # import as mean
503 r.in.lidar input=points.las output=lidar_dem_mean method=mean -o
504 # import as max
505 r.in.lidar input=points.las output=lidar_dem_max method=max -o
506 # import as p’th percentile of the values
507 r.in.lidar input=points.las output=lidar_dem_percentile_95 \
508 method=percentile pth=95 -o
509 Mean value DEM in perspective view, imported from LAS file
510
511 Further hints: how to calculate number of LiDAR points/square meter:
512 g.region -e
513 # Metric location:
514 # points_per_sq_m = n_points / (ns_extent * ew_extent)
515 # Lat/Lon location:
516 # points_per_sq_m = n_points / (ns_extent * ew_extent*cos(lat) * (1852*60)^2)
517
518 Serpent Mound dataset
519 This example is analogous to the example used in the GRASS wiki page
520 for importing LAS as raster DEM.
521
522 The sample LAS data are in the file "Serpent Mound Model LAS Data.las",
523 available at appliedimagery.com:
524 # print LAS file info
525 r.in.lidar -p input="Serpent Mound Model LAS Data.las"
526 # using v.in.lidar to create a new location
527 # create location with projection information of the LAS data
528 v.in.lidar -i input="Serpent Mound Model LAS Data.las" location=Serpent_Mound
529 # quit and restart GRASS in the newly created location "Serpent_Mound"
530 # scan the extents of the LAS data
531 r.in.lidar -sg input="Serpent Mound Model LAS Data.las"
532 # set the region to the extents of the LAS data, align to resolution
533 g.region n=4323641.57 s=4320942.61 w=289020.90 e=290106.02 res=1 -ap
534 # import as raster DEM
535 r.in.lidar input="Serpent Mound Model LAS Data.las" \
536 output=Serpent_Mound_Model_LAS_Data method=mean
537
538 Figure: Elevation for the whole area of Serpent Mound dataset
539
540 Height above ground
541 The mean height above ground of the points can be computed for each
542 raster cell (the ground elevation is given by the raster map eleva‐
543 tion):
544 g.region raster=elevation -p
545 r.in.lidar input=points.las output=mean_height_above_ground base_raster=elevation method=mean
546 In this type of computation, it might be advantageous to change the
547 resolution to match the precision of the points rather than deriving it
548 from the base raster.
549
550 Multiple file input
551 The file option requres a file that contains a list of file names with
552 the full path. For example, a list of files in the directory
553 /home/user/data:
554 points1.laz
555 points2.laz
556 points3.laz
557 would be lised in the file as:
558 /home/user/data/points1.laz
559 /home/user/data/points2.laz
560 /home/user/data/points3.laz
561 On Linux and OSX, this file can be automatically generated with the
562 command:
563 ls /home/user/data/*.laz > /home/user/data/filelist.txt
564 On Windows:
565 dir /b c:\users\user\data\*.laz > c:\users\user\data\filelist.txt
566 The mean height above ground example above would then be:
567 g.region raster=elevation -p
568 r.in.lidar file=/home/user/data/filelist.txt output=mean_height_above_ground base_raster=elevation method=mean
569 In Python, the list of files can be created using the glob Python mod‐
570 ule:
571 import glob
572 import gscript
573 file_list_name = ’/home/user/data/filelist.txt’
574 with open(, mode=’w’) as file_list:
575 for path in glob.iglob(’/home/user/data/lidar/*.las’):
576 file_list.write(path + "\n")
577 gscript.run_command(’r.in.lidar’, file=file_list_name,
578 output=’mean_height_above_ground’,
579 base_raster=’elevation’ method=’mean’)
580
582 · The "nan" value (as defined in C language) can leak into
583 coeff_var raster maps. Cause is unknown. Possible work-around
584 is: r.null setnull=nan or r.mapcalc ’no_nan = if(map == map,
585 map, null())’.
586
587 · Only one method can be applied for a single run and multiple
588 map output from a single run (e.g. method=string[,string,...]
589 output=name[,name,...] or n=string mean=string) is no sup‐
590 ported.
591 If you encounter any problems (or solutions!) please contact the GRASS
592 Development Team.
593
595 g.region, r.in.xyz, r.mapcalc, r.univar, v.in.lidar, r3.in.lidar,
596 v.vect.stats
597 v.lidar.correction, v.lidar.edgedetection, v.lidar.growing, v.outlier,
598 v.surf.bspline
599 Trimmed mean (Truncated mean, Wikipedia article), OpenTopography (LiDAR
600 point cloud repository)
601
603 · V. Petras, A. Petrasova, J. Jeziorska, H. Mitasova (2016): Pro‐
604 cessing UAV and lidar point clouds in GRASS GIS. XXIII ISPRS
605 Congress 2016 [ISPRS Archives, ResearchGate]
606
607 · ASPRS LAS format
608
609 · LAS library
610
611 · LAS library C API documentation
612
614 Markus Metz
615 Vaclav Petras, NCSU GeoForAll Lab (base_raster option, documentation)
616 based on r.in.xyz by Hamish Bowman and Volker Wichmann
617
618 Last changed: $Date: 2018-11-30 22:03:25 +0100 (Fri, 30 Nov 2018) $
619
621 Available at: r.in.lidar source code (history)
622
623 Main index | Raster index | Topics index | Keywords index | Graphical
624 index | Full index
625
626 © 2003-2019 GRASS Development Team, GRASS GIS 7.6.0 Reference Manual
627
628
629
630GRASS 7.6.0 r.in.lidar(1)