1r.in.lidar(1)                 Grass User's Manual                r.in.lidar(1)
2
3
4

NAME

6       r.in.lidar  - Creates a raster map from LAS LiDAR points using univari‐
7       ate statistics.
8

KEYWORDS

10       raster, import, LIDAR, statistics, conversion, aggregation, binning
11

SYNOPSIS

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

DESCRIPTION

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

NOTES

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

EXAMPLES

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

KNOWN ISSUES

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

SEE ALSO

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

REFERENCES

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

AUTHORS

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

SOURCE CODE

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)
Impressum