49 | | When all point cloud files are loaded into GRASS, the '''region needs to be changed such that it covers the area of all the point clouds''': |
50 | | |
51 | | {{{ |
52 | | g.region rast=mapname1,mapname2,....,mapnameN |
53 | | }}} |
54 | | |
55 | | where mapname1, mapname2, etc are the map names of the imported point cloud data from the above steps. |
56 | | |
57 | | All the separate '''LIDAR maps can now be patched together to make a single large raster''' data set. To do this, use the following command: |
58 | | |
59 | | {{{ |
60 | | r.patch in=mapname1,mapname2,... out=lidar_mosaic |
61 | | }}} |
62 | | |
63 | | where the map names are as before, the imported point cloud rasters, and lidar_mosaic is the output name for the single concatenated raster set. For more details on this command see [http://grass.fbk.eu/gdp/html_grass63/r.patch.html]. |
64 | | |
65 | | |
66 | | === Dealing with small holes === |
67 | | |
68 | | If '''small''' holes are present in your data, say due to small lakes or removed noise, the easiest way to fill these in is to patch the data with a lower resolution version of the LiDAR. This can be done by changing the region to a lower resolution and resampling: |
69 | | |
70 | | {{{ |
71 | | g.region res=5 |
72 | | r.resamp.stats input=lidar_mosaic output=lowres_mosaic |
73 | | }}} |
74 | | |
75 | | which in this example will create a new raster called lowres_mosaic at 5m resolution. Note that this is not suitable for larger holes in the data and other methods should be used in this case such as patching external data or interpolating. |
76 | | |
77 | | This can then be patched onto the original higher resolution LiDAR data such that the high resolution takes priority (as it is listed first in the 'in' option list). |
78 | | |
79 | | {{{ |
80 | | r.patch in=lidar_mosaic,lowres_mosaic out=high_low_patched |
81 | | }}} |
82 | | |
83 | | |
84 | | === Dealing with larger holes - using 3rd party data === |
85 | | |
86 | | If there are large areas of no data then it is recommended that 3rd party DEMs are used to fill these. ASTER and SRTM DEMs have near global coverage and are free to download. This assumes using the ASTER data. |
87 | | |
88 | | As this process is very similar to extending the region of the DEM please see how to do it [here]. |
89 | | |
90 | | |
91 | | === Dealing with larger holes - interpolating existing data === |
92 | | |
93 | | If you do not wish to use 3rd party data or none exists for your area then it is possible it interpolate and extrapolate. |
94 | | |
95 | | This can be done using the following command. Note that this can take a long time to complete depending on the amount of null data that is present in the raster and the resolution and size of the raster. |
96 | | |
97 | | {{{ |
98 | | r.fillnulls input=raster_to_fill output=filled_raster tension=40. smooth=0.1 |
99 | | }}} |
100 | | |
101 | | which will fill in the null values from 'raster_to_fill' and store the new data in 'filled_raster'. The tension and smooth values are used to define the spline interpolation. Note that this method will spam the screen with a lot of "Warnings" which GRASS says can be ignored. See [http://grass.fbk.eu/gdp/html_grass63/r.fillnulls.html] for more information. |
102 | | |
103 | | |
104 | | '''Alternative Method''' |
105 | | |
106 | | If you wished to use an alternative method of interpolation, and not extrapolate outside the edges of the data, then you could follow a procedure similar to this. |
107 | | |
108 | | First create a mask that covers the region of the data. The easiest way is to use your input data at a low resolution. This creates a raster which covers the LIDAR swath but contains no holes in the data (assuming the resolution is selected low enough). To create lower resolution data, say at 20m, use: |
109 | | |
110 | | {{{ |
111 | | g.region res=20 |
112 | | r.resamp.stats input=raster_name output=mask_name |
113 | | }}} |
114 | | |
115 | | To assign the mask and reset the region resolution (in this example to 2m) use: |
116 | | |
117 | | {{{ |
118 | | g.region res=2 |
119 | | r.mask input=mask_name |
120 | | }}} |
121 | | |
122 | | To interpolate the data we will use 'r.surf.idw' which requires the data to be scaled first to retain precision. |
123 | | |
124 | | This command will scale the data by 100: |
125 | | {{{ |
126 | | r.mapcalculator amap=raster_to_scale formula=100*A outfile=rasterx100 help=- |
127 | | }}} |
128 | | |
129 | | Run the interpolation command: |
130 | | {{{ |
131 | | r.surf.idw input=rasterx100 output=interpolatedx100 |
132 | | }}} |
133 | | |
134 | | And rescale the data back |
135 | | {{{ |
136 | | r.mapcalculator amap=interpolatedx100 formula=0.01*A outfile=interpolated help=- |
137 | | }}} |
138 | | |
139 | | this results in a map where the internal holes have been filled, but the area outside the swath coverage remains unchanged. |
140 | | |
141 | | |
142 | | === Filtering the data === |
143 | | |
144 | | It may be wise to filter / smooth the data to remove localised spikes. This can be done using the following command: |
145 | | |
146 | | {{{ |
147 | | r.neighbors input=raster_to_filter output=filtered_raster method=median size=3 --overwrite |
148 | | }}} |
149 | | |
150 | | which will apply a median filter of kernel size 3 to the raster_to_filter, resulting in filtered_raster. More information on the filters that can be applied can be found at [http://grass.fbk.eu/gdp/html_grass63/r.neighbors.html]. |
151 | | |
152 | | |
153 | | === Extending the coverage using ASTER data === |
154 | | |
155 | | If you wish to use the DEM for processing your hyperspectral data then it may be that you need to extend the coverage such that it covers the hyperspectral data. This can be done by patching on ASTER data. Information on this, and how to access ASTER data, can be found [wiki:Help/DEM_scripts#CreatingaDEMfromASTERdatausingasterdem.shscript here], along with how to offset the ASTER data from geoidal heights to spheroidal heights. |
156 | | |
157 | | === Writing out the DEM === |
158 | | |
159 | | The DEM can be written out from GRASS in various formats (see [http://grass.fbk.eu/gdp/html_grass63/raster.html] functions starting 'r.out'). |
160 | | |
161 | | To write the data out as an ASCII grid (for example to use in azgcorr) you could use: |
162 | | |
163 | | {{{ |
164 | | r.out.ascii input=raster_name output=output_filename null=0 |
165 | | }}} |
166 | | |
167 | | which will write out the raster 'raster_name' to the file 'output_filename' and set any null values to 0. To use this DEM the header will need to be converted into a style azgcorr understands, such as [#azgcorrheader here]. |
168 | | |
169 | | To write out the data as an ENVI BIL file (for example to use in APL) you could use: |
170 | | |
171 | | {{{ |
172 | | r.out.gdal format=ENVI type=Float32 input=raster_name output=output_filename nodata=9999 |
173 | | }}} |
174 | | |
175 | | which will write out raster 'raster_name' to a 32-bit floating point ENVI file named 'output_filename', using 9999 to represent null data. |
176 | | |
177 | | '''IMPORTANT NOTE.''' If you wish to use the DEM in APL it '''MUST''' be in WGS84 Latitude / Longitude. If you wish to do this and you are not working in a WGS84 Latitude/Longitude region then you will need to reproject the data into that region before outputting. |
178 | | |
179 | | |
180 | | |
181 | | ------------ |
182 | | == Making the DEM suitable for azgcorr ==#azgcorrheader |
183 | | To make a suitable ASCII DEM for use in the azgcorr software, the header information of the ASCII DEM file must be in a certain format. The required format is to have a header of one line (the first line of the file) with the DEM data following. The format is (as given by the azgcorr help): |
184 | | |
185 | | `or c r xm ym xx yx gi` |
186 | | |
187 | | where: |
188 | | |
189 | | or = row order of the data [0 if South to North, 1 if North to South] |
190 | | |
191 | | c = number of columns |
192 | | |
193 | | r = number of rows |
194 | | |
195 | | xm = minimum easting |
196 | | |
197 | | ym = minimum northing |
198 | | |
199 | | xx = maximum easting |
200 | | |
201 | | yx = maximum northing |
202 | | |
203 | | gi = grid size (spacing) |
204 | | |
205 | | An example header, for a DEM of 2000 rows x 2000 columns at 5m resolution, might be: 1 2000 2000 400000 850000 410000 860000 5 |
206 | | |
| 45 | For more details on this command, and usage outside the NERC-ARF-DAN systems see the [https://github.com/pmlrsg/arsf_dem_scripts/blob/master/doc/source/tutorial_lidar.md#create-a-lidar--aster-dsm-for-use-in-apl tutorial]. |