Changes between Version 9 and Version 10 of Processing/LIDARDEMs


Ignore:
Timestamp:
Apr 22, 2008 5:36:07 PM (11 years ago)
Author:
benj
Comment:

Updated new script file usage and manual procedure

Legend:

Unmodified
Added
Removed
Modified
  • Processing/LIDARDEMs

    v9 v10  
    15152. Run the script file
    1616{{{
    17 lidar2dem.sh <grass_mapset_directory> [Intermediate_file] [--reuse|--overwrite]
     17lidar2dem.sh -g grass_mapset_directory [-b base_name] [-m|-n] [-r|-o] [-h]
    1818}}}
    1919
    20 Note that while it is not necessary to specify an intermediate file (in this case a temporary file will be used), it is recommended that you do so. This is because if you specify one then it can be reused for subsequent runs (saving time), and because the name of the intermediate file is used as a base for the file name of the GRASS map that is created and of the DEM. You may specify --reuse or --overwrite to determine what will be done if the intermediate file already exists - if you do not specify and the file already exists you will be prompted.
     20If you specify a base name then intermediate files (data, mask and histogram) will be created using the given base name with .xyz, .mask and .hist extensions respectively. These can then be re-used for subsequent lidar creation runs if desired (to recreate only one of these files, delete the relevant one and the others will be reused). The base name if given is also used for naming maps within GRASS - if no base name is specified then "lidar" is used for this. If you specify -m (default) then a GRASS mask file will be created and used (speeds up processing by interpolating less blank space), or -n specifies no mask. Specifying -r (default) results in any existing intermediate files with the correct name being re-used, or -o results in them being overwritten if present (ie all intermediate files are re-created from the data files. Specifying -h displays usage information.
    2121
    2222Note also that it is recommended that you check the displayed upper and lower bounds against the displayed histogram to ensure that the automatically chosen values are sensible. If they are not and this causes a problem with the DEM then it will be necessary to reprocess using the manual method as below.
     
    2424== Manual method ==
    2525
    26 1. Merge files and strip off unnecessary UTM zone number by running trim_lidar.sh in the directory containing the lidar files:
    27 Usage: trim_lidar.sh > output_file
     261. Create a directory listing of the data files and save it to a file:
     27{{{
     28\ls -l *.all.bz2 | awk '{print $8}' > dir_file
     29}}}
    2830
    29 2. Generate a histogram for the lidar data to determine min/max reasonable data values by running lidar_histogram.py:
    30 Usage: python lidar_histogram.py input_file
     312. Merge files, strip off unnecessary UTM zone number and generate a GRASS mask by running generate_mask.py in the directory containing the lidar files:
     32{{{
     33python generate_mask.py dir_file mask_file merged_file
     34}}}
    3135
    32 Note for ARSF internal use there is a convenience script in the path - use "lidar_histogram.sh <input_file>"
     36...where dir_file is the file containing your directory listing, mask_file is the point file to be generated and used as a GRASS mask and merged_file is the merged and trimmed lidar data file.
     37Note for ARSF internal use there is a convenience script in the path - use "generate_mask.sh dir_file mask_file merged_file"
     38
     393. Generate a histogram for the lidar data to determine min/max reasonable data values by running lidar_histogram.py:
     40{{{
     41python lidar_histogram.py input_file
     42}}}
     43
     44Note for ARSF internal use there is again a convenience script in the path - use "lidar_histogram.sh input_file"
    3345
    3446This generates a 5x log histogram (ie it's a histogram of the base-10 log of the lidar values binned into 10m bins, multiplied by 5 to scale). If there are a small number of low or high values in the histogram then decide on a scaling cutoff. eg:
     
    6476In the given example, there are a very few values between 20-30m at the bottom end, and a big gap at the top end before a small number of values above 590m (nothing between 240m and 590m). So it would be sensible to pick 30m as a minimum cutoff and 250m as a maximum. Note that because the histogram is on a log scale the difference in numbers of points at both ends is much larger than it looks at first glance. The script will display values that it thinks are appropriate cut-off values.
    6577
    66 3. Check the LIDAR data projection in the header file. Open GRASS, select (or create) an a location in the appropriate projection and set the region appropriately for the dataset - geographic boundaries for the data are given by the script in the previous step, though you may wish to add a small amount of padding to this to ensure that the produced DEM covers the flight area.
     784. Check the LIDAR data projection in the header file. Open GRASS, select (or create) an a location in the appropriate projection and set the region appropriately for the dataset - geographic boundaries for the data are given by the script in the previous step, though you may wish to add a small amount of padding to this to ensure that the produced DEM covers the flight area.
    6779
    68 4. Read in the trimmed lidar file using r.in.xyz. Note that for large areas this will use a LOT of memory - if the command refuses to start complaining of a lack of memory, use the percent argument and the command will automatically run in several passes - this will take longer, but use less memory on each pass.
     805. Read in the mask file (assuming you want to use a mask)
     81{{{
     82v.in.ascii input=mask_file output=mask_points format=point fs=, x=1 y=2 --overwrite
     83}}}
     84
     856. Generate the convex hull of the given points to use as a mask
     86{{{
     87v.hull -a input=mask_points output=mask_poly --overwrite
     88}}}
     89
     907. Convert the vector convex hull to a raster map
     91{{{
     92v.to.rast input=mask_poly output=raster_mask use=val value=1 --overwrite
     93}}}
     94
     958. Set the mask map to the calculated polygon
     96{{{
     97r.mask -o input=raster_mask maskcats=*
     98}}}
     99
     1009. Read in the trimmed lidar file using r.in.xyz. Note that for large areas this will use a LOT of memory - if the command refuses to start complaining of a lack of memory, use the percent argument and the command will automatically run in several passes - this will take longer, but use less memory on each pass.
    69101{{{
    70102r.in.xyz input=<trimmed_lidar_file> output=<lidar_basemap> x=2 y=3 z=4 fs=" " zrange=<min_cutoff>,<max_cutoff> [percent=xx]
    71103}}}
    72104
    73 5. Interpolate gaps in the map using r.fillnulls:
     10510. Interpolate gaps in the map using r.surf.idw
    74106{{{
    75 r.fillnulls input=<lidar_basemap> output=<lidar_interp_map>
     107r.surf.idw input=lidar_basemap output=lidar_interpolated --overwrite
    76108}}}
    77109
    78 6. Reproject the dataset if necessary to match the projection of the flight data (should be the same, but conceivably won't be). See [wiki:Processing/SRTMDEMs Creation of DEMs from SRTM 90m data] for how to do this.
     11011. Clear the GRASS mask
     111{{{
     112r.mask -r input=anything
     113}}}
    79114
    80 7. Generate an ASCII DEM as per [wiki:Processing/NextMapDEMs Creation of DEMs from NextMap data]:
     11512. Reproject the dataset if necessary to match the projection of the flight data (should be the same, but conceivably won't be). See [wiki:Processing/SRTMDEMs Creation of DEMs from SRTM 90m data] for how to do this.
     116
     11713. Generate an ASCII DEM as per [wiki:Processing/NextMapDEMs Creation of DEMs from NextMap data]:
    81118{{{
    82119r.out.ascii input=<lidar_interp_map> output=lidar.dem null=0