United States
Department ofAgriculture
Forest Service

FUSION/LDV: Software for
LIDAR Data Analysis andVisualization

Pacific Northwest
Research Station

Robert J. McGaughey
September 2024 – FUSION Version 4.61

The Forest Service of the U.S. Department of Agriculture is dedicated to the principle ofmultiple use management of the Nation’s forest resources for sustained yields of wood,
water, forage, wildlife, and recreation. Through forestry research, cooperation with theStates and private forest owners, and management of the National Forests and National
Grasslands, it strives—as directed by Congress—to provide increasingly greater service
to a growing Nation.
The U.S. Department of Agriculture (USDA) prohibits discrimination in all its programs
and activities on the basis of race, color, national origin, gender, religion, age, disability,
political beliefs, sexual orientation, or marital or family status. (Not all prohibited bases
apply to all programs.) Persons with disabilities who require alternative means forcommunication of program information (Braille, large print, audiotape, etc.) should
contact USDA’s TARGET Center at (202) 720-2600 (voice and TDD).
To file a complaint of discrimination, write USDA, Director, Office of Civil Rights, Room326- W, Whitten Building, 14th and Independence Avenue, SW, Washington, DC
20250-9410 or call (202) 720-5964 (voice and TDD). USDA is an equal opportunity
provider and employer.
USDA is committed to making its information materials accessible to all USDA
customers and employees.

AuthorRobert J. McGaughey is a research forester, U.S. Department of Agriculture, Forest
Service, Pacific Northwest Research Station, University of Washington, Box 352100,
Seattle, WA 98195-2100, robert.mcgaughey@usda.gov

Contents
FUSION Disclaimer ......................................................................................................... 1
LIDAR Overview .............................................................................................................. 2
How Does LIDAR Work? ............................................................................................. 2
Overview of the FUSION/LDV Analysis and Visualization System .................................. 3
Using FUSION/LDV......................................................................................................... 6
Getting Data into FUSION ........................................................................................... 6
Converting LIDAR Data Files into LDA Files ............................................................... 8
Creating Images Using LIDAR Data ............................................................................ 8
Building a FUSION Project .......................................................................................... 9
FUSION Preferences ................................................................................................... 9
Keyboard Commands for FUSION .................................................................................. 9
Keyboard Commands for LDV ...................................................................................... 11
Keyboard Commands for PDQ ...................................................................................... 15
Command Line Utility and Processing Programs .......................................................... 19
Command Line Options Shared By All Programs ...................................................... 19
Command Log Files................................................................................................... 20
Using 64-bit Versions of Command Line Programs ................................................... 21
Reading Compressed LAS Files (LAZ and COPC formats) ....................................... 21
FUSION-LTK Overview ............................................................................................. 22
ASCII2DTM ............................................................................................................... 26
ASCIIImport ............................................................................................................... 28
CanopyMaxima .......................................................................................................... 29
CanopyModel ............................................................................................................ 32
Catalog ...................................................................................................................... 37
ClipData ..................................................................................................................... 43
ClipDTM ..................................................................................................................... 48
CloudMetrics .............................................................................................................. 49
Cover ......................................................................................................................... 59
CSV2Grid .................................................................................................................. 62
DensityMetrics ........................................................................................................... 63
DTM2ASCII ............................................................................................................... 66
DTM2ENVI ................................................................................................................ 67
DTM2TIF ................................................................................................................... 68
DTM2XYZ .................................................................................................................. 69
DTMDescribe ............................................................................................................. 70
DTMHeader ............................................................................................................... 71
FilterData ................................................................................................................... 72
FirstLastReturn .......................................................................................................... 75
GridMetrics ................................................................................................................ 77
GridSample ................................................................................................................ 90
GridSurfaceCreate ..................................................................................................... 92
GridSurfaceStats ....................................................................................................... 95
GroundFilter ............................................................................................................... 98
ImageCreate ............................................................................................................ 102
IntensityImage ......................................................................................................... 104

JoinDB ..................................................................................................................... 109
LDA2ASCII .............................................................................................................. 110
LDA2LAS ................................................................................................................. 111
MergeData ............................................................................................................... 113
MergeDTM ............................................................................................................... 115
MergeRaster ............................................................................................................ 118
PDQ ......................................................................................................................... 120
PolyClipData ............................................................................................................ 123
RepairGridDTM........................................................................................................ 126
ReturnDensity .......................................................................................................... 128
SplitDTM .................................................................................................................. 130
SurfaceSample ........................................................................................................ 132
SurfaceStats ............................................................................................................ 136
ThinData .................................................................................................................. 138
TiledImageMap ........................................................................................................ 140
TINSurfaceCreate .................................................................................................... 141
TopoMetrics ............................................................................................................. 143
TreeSeg ................................................................................................................... 146
UpdateIndexChecksum/RefreshIndexChecksum .................................................... 150
ViewPic .................................................................................................................... 151
XYZ2DTM ................................................................................................................ 152
XYZConvert ............................................................................................................. 154
Copyright Notifications ................................................................................................ 156
Acknowledgements ..................................................................................................... 157
References .................................................................................................................. 158
Appendix A: File Formats ............................................................................................ 161
PLANS Surface Models (.DTM) ............................................................................... 162
LIDAR Data Files (.LDA) .......................................................................................... 165
Data Index Files (.LDX and .LDI) ............................................................................. 166
LAS LIDAR Data Files (.LAS) .................................................................................. 168
XYZ Point Files ........................................................................................................ 169
Hotspot Files ............................................................................................................ 170
Tree Files ................................................................................................................. 173
Appendix B: DOS Batch Programming and the FUSION LIDAR Toolkit ..................... 180
Batch Programming Overview ................................................................................. 181
Getting help with batch programming commands .................................................... 181
Using the FUSION Command Line Tools ................................................................ 182
Automating Processing Tasks ................................................................................. 182
Appendix C: Using LTKProcessor to Process Data for Large Acquisitions ................. 185
Overview.................................................................................................................. 186
Considerations for Processing Data from Large Acquisitions .................................. 186
Computer software and hardware conflicts .............................................................. 187
Subdividing large datasets ....................................................................................... 192
Batch File for Pre-processing .................................................................................. 193
Batch File for Processing Individual Data Tiles or Analysis Grid Cells..................... 193
Batch File for Final Processing ................................................................................ 194

Example Batch Files ................................................................................................ 194
Appendix D: Building multi-processor workflows using AreaProcessor ....................... 196
Overview.................................................................................................................. 197
Configuring AreaProcessor on your computer ......................................................... 198
Preparing data for AreaProcessor ........................................................................... 199
Processing tile and block strategies......................................................................... 200
Processing batch files .............................................................................................. 201
Configuring the run for multiple processors ............................................................. 202
What to do when something goes wrong ................................................................. 203
Appendix E: Retiling point data using AreaProcessor ................................................. 205
Using AreaProcessor to retile point files .................................................................. 206
Appendix F: Using AreaProcessor to produce return density raster layers ................. 210
Appendix G: Converting ESRI GRID data to ASCII raster format using GDAL ........... 213
Overview.................................................................................................................. 214
Converting data from GRID to ASCII raster format .................................................. 214
Appendix H: Using FUSION/LDV to adjust plot and individual tree locations .............. 215
Overview.................................................................................................................. 216
Requirements .......................................................................................................... 217
FUSION configuration.............................................................................................. 217
Adjusting tree/plot locations ..................................................................................... 218

FUSION Disclaimer
FUSION and all related programs are developed at the US Department of Agriculture,
Forest Service, Pacific Northwest Research Station by an employee of the Federal
Government in the course of their official duties. Pursuant to Title 17, Section 105 of theUnited States Code, this software is not subject to copyright protection and is in the
public domain. FUSION is primarily a research tool. USDA Forest Service assumes noresponsibility whatsoever for its use by other parties, and makes no guarantees,
expressed or implied, about its quality, reliability, or any other characteristic.

1

LIDAR Overview
Light detection and ranging systems (LIDAR) use laser light to measure distances. They
are used in many ways, from estimating atmospheric aerosols by shooting a laser
skyward to catching speeders in freeway traffic with a handheld laser-speed detector.
Airborne laser-scanning technology is a specialized, aircraft-based type of LIDAR thatprovides extremely accurate, detailed 3-D measurements of the ground, vegetation, andbuildings. Developed in just the last 15 years, one of LIDAR’s first commercial uses in
the United States was to survey power line corridors to identify encroaching vegetation.
Additional uses include mapping landforms and coastal areas. In open, flat areas,
ground contours can be recorded from an aircraft flying overhead providing accuracy
within 6 inches of actual elevation. In steep, forested areas accuracy is typically in therange of 1 to 2 feet and depends on many factors, including density of canopy coverand the spacing of laser shots. The speed and accuracy of LIDAR made it feasible tomap large areas with the kind of detail that before had only been possible with timeconsuming and expensive ground survey crews.

Figure 1. Schematic of an airborne laser scanning system.

Federal agencies such as the Federal Emergency Management Administration (FEMA)and U.S. Geological Survey (USGS), along with county and state agencies, began
using LIDAR to map the terrain in flood plains and earthquake hazard zones. The Puget
Sound LIDAR Consortium, an informal group of agencies, used LIDAR in the Puget
Sound area and found previously undetected earthquake faults and large, deep-seated,
old landslides. In other parts of the country, LIDAR was used to map highly detailed
contours across large flood plains, which could be used to pinpoint areas of high risk. In
some areas, entire states have been flown with LIDAR to produce more accurate digitalterrain data for emergency planning and response. LIDAR mapping of terrain uses atechnique called “bare-earth filtering.” Laser scan data about trees and buildings are
stripped away, leaving just the bare-ground data. Fortunately for foresters and othernatural resource specialists, the data being “thrown away” by geologists provide
detailed information describing vegetation conditions and structure.

How Does LIDAR Work?
The use of lasers has become commonplace, from laser printers to laser surgery. In
airborne-laser-mapping, LIDAR systems are taken into the sky. Instruments are2mounted on a single- or twin-engine plane or a helicopter and data are collected overlarge land areas.
Airborne LIDAR technology uses four major pieces of equipment (Figure 1). These area laser emitter-receiver scanning unit attached to the aircraft; global positioning system(GPS) units on the aircraft and on the ground; an inertial measurement unit (IMU)
attached to the scanner, which measures roll, pitch, and yaw of the aircraft; and acomputer to control the system and store data. Several types of airborne LIDAR
systems have been developed; commercial systems commonly used in forestry are
discrete-return, small-footprint systems. “Small footprint” means that the laser beam
diameter at ground level is typically in the range of 6 inches to 3 feet. The laser scanneron the aircraft sends up to 200,000 pulses of light per second to the ground andmeasures how long it takes each pulse to reflect back to the unit. These times are used
to compute the distance each pulse traveled from scanner to ground. The GPS and IMU
units determine the precise location and attitude of the laser scanner as the pulses are
emitted, and an exact coordinate is calculated for each point. The laser scanner uses anoscillating mirror or rotating prism (depending on the sensor model), so that the lightpulses sweep across a swath of landscape below the aircraft. Large areas are surveyed
with a series of parallel flight lines. The laser pulses used are safe for people and allliving things. Because the system emits its own light, flights can be done day or night,
as long as the skies are clear.
Thus, with distance and location information accurately determined, the laser pulses
yield direct, 3-D measurements of the ground surface, vegetation, roads, and buildings.
Millions of data points are recorded; so many that LIDAR creates a 3-D data cloud. Afterthe flight, software calculates the final data points by using the location information andlaser data. Final results are typically produced in weeks, whereas traditional groundbased mapping methods took months or years. The first acre of a LIDAR flight isexpensive, owing to the costs of the aircraft, equipment, and personnel. But when large
areas are covered, the costs can drop to about $1 to $2 per acre. The technology iscommercially available through a number of sources.

Overview of the FUSION/LDV Analysis and Visualization
SystemThe FUSION/LDV software was originally developed to help researchers understand,explore, and analyze LIDAR data. The large data sets commonly produced by LIDAR
missions could not be used in commercial GIS or image processing environments
without extensive preprocessing. Simple tasks such as extracting a sample of LIDAR
returns that corresponded to a field plot were complicated by the sheer size of the data
and the variety of ASCII text formats provided by various vendors. The original versionsof the software allowed users to clip data samples and view them interactively. As a
new data set was delivered, the software was modified to read the data format andfeatures were added depending on the needs of a particular research project. After ayear or so of activity, scientists at the Pacific Northwest Research Station and the
University of Washington decided to design a more comprehensive system to support
their research efforts.
3

The analysis and visualization system consists of two main programs, FUSION and
LDV (LIDAR data viewer), and a collection of task-specific command line programs. The
primary interface, provided by FUSION, consists of a graphical display window and acontrol window. The FUSION display presents all project data using a 2D display typicalof geographic information systems. It supports a variety of data types and formats
including shapefiles, images, digital terrain models, canopy surface models, and LIDAR
return data. LDV provides the 3D visualization environment for the examination andmeasurement of spatially-explicit data subsets. Command line programs provide
specific analysis and data processing capabilities designed to make FUSION suitablefor processing large LIDAR acquisitions.
In FUSION, data layers are classified into six categories: images, raw data, points ofinterest, hotspots, trees, and surface models. Images can be any geo-referenced image
but they are typically orthophotos, images developed using intensity or elevation values
from LIDAR return data, or other images that depict spatially explicit analysis results.
Raw data include LIDAR return data and simple XYZ point files. Points of interest (POI)
can be any point, line, or polygon layer that provides useful visual information or sample
point locations. Hotspots are spatially explicit markers linked to external references suchas images, web sites, or pre-sampled data subsets. Tree files contain data, usually
measured in the field, representing individual trees. Surface models, representing thebare ground or canopy surface, must be in a gridded format. FUSION uses the PLANS
format for its surface models and provides utilities to convert a variety of formats into the
PLANS format. The current FUSION implementation limits the user to a single image,surface model, and canopy model, however, multiple raw data, POI, tree, and hotspot
layers are allowed. The FUSION interface provides users with an easily understood
display of all project data. Users can specify display attributes for all data and cantoggle the display of the different data types.
FUSION allows users to quickly and easily select and display subsets of large LIDAR
data. Users specify the subset size, shape, and the rules used to assign colors toindividual raw data points and then select sample locations in the graphical display or bymanually entering coordinates for the points defining the sample. LDV presents thesubset for the user to examine. Subsets include not only raw data but also the portion of
the image and surface models for the area sampled. FUSION provides the following
data subset types:• Fixed-size square,• Fixed-size circle,• Variable-size square,• Variable-size circle,• Variable-width corridor.
Subset locations can be “snapped” to a specific sample location, defined by POI points
to generate subsets centered on or defined by specific locations. Elevation values for
LIDAR returns can be normalized using the ground surface model prior to display in
LDV. This feature is especially useful when viewing data representing forested regions4

in steep terrain as it is much easier to examine returns from vegetation and compare
trees after subtracting the ground elevation.
LDV strives to make effective use of color, lighting, glyph shape, motion, andstereoscopic rendering to help users understand and evaluate LIDAR data. Color isused to convey one or more attributes of the LIDAR data or attributes derived from otherdata layers. For example, individual returns can be colored using values sampled froman orthophoto of the project area to produce semi-photorealistic visual simulations. LDV
uses a variety of shading and lighting methods to enhance its renderings. LDV provides
point glyphs that range from single pixels, to simple geometric objects, to complex
superquadric objects. LDV operates in monoscopic, stereoscopic, and anaglyph display
modes. To enhance the 3D effect on monoscopic display systems, LDV provides asimple rotation feature that moves the data subset continuously through a simple
pattern (usually circular). We have dubbed this technique “wiggle vision”, and feel it
provides a much better sense of the 3D spatial arrangement of points than provided bya static, fixed display. To further help users understand LIDAR data, LDV can also map
orthographic images onto a horizontal plane that can be positioned vertically within thecloud of raw data points. Bare-earth surface models are rendered as a shaded 3D
surface and can be textured-mapped using the sampled image. Canopy surface or
canopy height models are rendered as a mesh so the viewer can see the data points
under the surface.
FUSION and LDV have several features that facilitate direct measurement of LIDAR
data. FUSION provides a “plot mode” that defines a buffer around the sample area andincludes data from the buffer in a data subset. This option, available only with fixed-sizeplots, makes it easy to create LIDAR data subsets that correspond to field plots. “Plotmode” lets the user measure tree attributes for trees whose stem is within the plot area
using all returns for the tree including those outside the plot area but within the plot
buffer. The size of the plot buffer is usually set to include the crown of the largest trees
expected for a site. When in “plot mode”, FUSION includes a description of the fixedarea portion of the subset so LDV can display the plot boundary as a wire frame
cylinder or cube and inform the user when measurement locations are within or outside
the plot boundary..
LDV provides several functions to help users place the measurement marker and makemeasurements within the data cloud. The following “snap functions” are available tohelp position the measurement marker:• Set marker to the elevation of the lowest point in the current measurement area
(don’t move XY position of marker)• Set marker to the elevation of the highest point in the current measurement area
(don’t move XY position of marker)• Set marker to the elevation of the point closest to the marker (don’t move XY
position of marker)• Move marker to the lowest point in the current measurement area
• Move marker to the highest point in the current measurement area
• Move marker to point closest to the marker

5

•
•

Set marker to the elevation of the surface model (usually the ground surface)
Change the shape and alignment of the measurement marker to better fit thedata points that represent a tree crown

The measurement marker in LDV can be elliptical or circular to compensate for tree
crowns that are not perfectly round. The measurement area can be rotated to betteralign with an individual tree crown. Once an individual tree has been isolated andmeasured, the points within the measurement area can be “turned off” to indicate thatthey have been considered during the measurement process. This ability makes it mucheasier to isolate individual trees in stands with dense canopies.

Using FUSION/LDV
To start using the FUSION system, launch FUSION and load the example project
named “demo_4800K.dvz” using the File…Open menu option. The default sample
options are set to use a stroked box. LIDAR returns will be colored according to theirheight above ground.
To extract and display a sample of data, stroke a rectangular area using the mouse.
The status display in the lower left corner of the FUSION window shows the size of thestroked area. Try for a sample that is about 250 feet by 250 feet. This should yield asample of about 22,000 points. After a short time, the data subset will be displayed in
LDV. To facilitate rapid sample extraction, FUSION uses a simple indexing scheme toorganize the LIDAR data. This indexing process is necessary the first time FUSION
uses a new dataset. Subsequent samples will take less time because the data files only
need to be indexed once.
To manipulate the LIDAR data in LDV, it is easiest to imagine that the data is containedin a glass ball. To rotate the data, use the mouse (with the left button held down) to rollthe ball and thus manipulate the data. As you move the data, LDV may display only asubset of the points depending on the size of the sample.
Options in LDV are accessed using the right mouse button to activate a menu of
options. There are many options and the best way to understand them is to try them.
Additional functions are assigned to keystrokes. These functions are described when
you click the “About LDV” button located in the lower left corner of the LDV window.
Keyboard shortcuts are also listed on the right mouse menu.

Getting Data into FUSIONFUSION merges imagery, LIDAR data, GIS layers, field data, and surface models toprovide an intuitive interface to large project datasets. Ideally, you will have an orthorectified image for the project area (image can be created in FUSION using LIDAR
return data) and LIDAR data. However, the image is not required to use FUSION. Whenyou don’t have a background image, FUSION will automatically create one when you
load point data. The automatic image is simply a graphic depiction of the data extent foreach point file, but it is sufficient to provide a background image. Other data types are
optional.
6

FUSION currently reads several ASCII file formats, LAS files, and compressed LAS files(LAZ format). Its native format, called LDA, is an indexed binary format that allows rapid
random access to large datasets. FUSION also reads LAS and LAZ files and uses thesame indexing scheme to facilitate rapid data sampling. LAS and LAZ files do notneed to be converted to the LDA format for use in FUSION. Utilities are included
that convert ASCII files into the native LDA binary format. The LDA2LAS utility can also
compress and decompress LAS/LAZ files.
FUSION works best with uncompressed data files (LAS instead of LAZ). While theindexing scheme allows reading only a portion of the data file when extracting a sample,
this behavior does not work well with compressed files. In addition, FUSION’s indexing
method will not work with files containing more than 2 billion points. If you try to uselarge files in FUSION, the indexing will likely fail and you will not be able to extract andview sample. This limitation does not affect the command line tools.
Version 4.60 of FUSION introduced support for cloud optimized point clouds (COPC) for
use in the data viewing system (FUSION and LDV). COPC files are based on the LAZ
format and include an embedded spatial index that allows reading points within a limited
geographic extent. When using COPC files, FUSION’s index files are not needed andthere is no performance penalty due to the compressed point data. Performance using
COPC files is faster than that with the same data in LAS format with FUSION index
files.
Versions of FUSION prior to 4.00 required an ortho-rectified image and an associatedworld file to provide scaling information and a backdrop for the project. FUSION 4.00+
does not require an image to work with and display point data. Basically, you can load
point data and an image showing the tile extents will be created on-the-fly for use as the
background image. If you are loading a project file that contains point data, an image
will also be created. FUSION can still display background imagery and utilities areincluded to create images using the intensity value or the elevation recorded with each
LIDAR return.
Version 4.60 of FUSION introduced support for geoTIFF images. This means that world
files are not needed for TIFF images provided the image contains ModelTiePoint andModelPixelScale information. FUSION does not work with ModelTransformation
information (16 parameter affine image transformation). World files are still required forother image formats.
FUSION reads surface models (ground, canopy, or other surfaces of interest) stored in
the PLANS DTM format (described in Appendix A: File Formats). FUSION provides
conversion tools to convert surface models stored in other formats into the PLANS
format. Supported formats include USGS ASCII DEM, USGS SDTS, SURFER, andASCII grid.

7

Converting LIDAR Data Files into LDA FilesFUSION provides two conversion utilities that convert ASCII data formats into the LDA
format. The utilities are accessed using the “Utilities” button on the FUSION control
panel. The “Import LIDAR data in specific ASCII formats…” button brings up the dialog
for converting ASCII data files stored in specific formats. The formats include a generic
XYZ point format but, for the most part, are specific to data that were acquired while
FUSION was being developed. ASCII input files typically have the “.XYZ” extension(using this extension will make it easier to select the files). The formats supported aredescribed elsewhere in this document. The “Import generic ASCII LIDAR data…” option
allows the user to define the format of the ASCII data and specify the LIDAR fields thatwill be converted. FUSION’s internal LDA format includes the following attributes foreach LIDAR return: pulse number, return number, X, Y, Elevation, scan/nadir angle, andintensity. For datasets that do not include all attributes, you can specify default values
for the missing attributes.
LAS format files are read and used directly by FUSION. The same indexing scheme isused to facilitate rapid file access but the files are not converted to the LDA format. The
first time a sample is extracted from a LAS file, the index files are created. Subsequent
sampling operations use the newly created index files.

Creating Images Using LIDAR Data
FUSION provides a utility that uses the intensity value or the elevation for each LIDAR
return to construct an orthographic image and the associated world file to provide
georeferencing information. This utility is accessed using the “Tools” menu and the“Create an image using LIDAR point data…” option under “Miscellaneous utilities”. The
image can be built using several LDA or LAS format files (in case the project organizes
data into multiple files). For most data, you will want to clamp the intensity range to a
specific set of values. To help determine appropriate values for the color mapping, the“Scan for data ranges” button can be used to report the range of values in the data fileand a display a histogram of the intensity values. In most cases, you should not map thefull range of intensity values to the grayscale image. Our experience with several
vendors has taught us that most vendors don’t know much about the intensity values
and can’t even tell you the correct range of values recorded in their data. You canchange the pixel size for the image but the default of 1 unit (same planimetric units in
LIDAR data) generally provides a reasonable image. For low density datasets (<1 returnper square meter), increasing the pixel size will produce an image with fewer voids andwill decrease the size of the image file.
FUSION provides command line programs that also produce intensity images from
LIDAR data. The first, ImageCreate, basically duplicates the functions described above.
The second program, IntensityImage, was developed more recently to produce more
useful images using the LIDAR intensity data. IntensityImage provides automatic
scaling for the range of intensity values and incorporates a point to pixel conversion
process that helps create high-resolution images from LIDAR point data.

8

Building a FUSION ProjectOnce you have an image and some LIDAR data files, you are ready to build the
FUSION project. Click the “Image…” button and select the image you created from the
LIDAR data values. Next, click the “Raw data…” button and select LAS files or the LDA
files created from your ASCII data files. The default symbol type, “None”, is suitable formost projects so just click the OK button. When the symbol type is set to “None”,
FUSION will draw a box that represents the extent of each indexed LIDAR data filewhen you “turn-on” display of the raw data. You now have a FUSION project ready to
go. Click the “Sample options” button to specify sampling options for the LIDAR
subsets, or just stroke a rectangular area to cut out a subset of data and launch the 3D
viewer. The first-time data files are used with FUSION, they will be indexed. The
indexing process may take a few minutes depending on the size of the project area and
LIDAR return density. Indexing is only done once so subsequent samples will display
much faster.

FUSION Preferences
FUSION provides several setting to control its overall behavior. These include
communications settings for using a GPS receiver to provide a “moving marker”
showing the current GPS in the FUSION display, settings for the buffer used when
FUSION is in “plot mode”, and setting that control how FUSION clips data for display in
LDV and the location used to store temporary files.
For many managed computer systems, users do not have access to all folders. In many
configurations, users may not have permission to write files into the “Program Files”
folder or other folders where FUSION might be installed. When FUSION is used in suchenvironments, the option to store temporary data files in the user’s temporary folder
should be checked to ensure that FUSION can pass data sample to LDV. If this option
is not enabled, you will often get a message indicating that there are no data points
within the sample area even when you know for sure that you are sampling within thedata coverage area.

Keyboard Commands for FUSION
The following keystroke and mouse commands area available in FUSION after animage has been loaded.
Keystroke/mouseactionMiddle mousebuttonLeft mouse button
Right mousebuttonMouse wheel
up/down

Description
Pan the display to the location of the mouse cursor
Begin a sample using the location of the mouse cursor
Cancel a sample (the right mouse button must be pressed while
the left button is pressed)
Scroll the display up and down

9

Shift & mousewheel up/downCtrl & mousewheel up/down
Left arrow
Right arrow
Up arrow
Down arrow(+) plus key(-) minus key
Home
F5

Scroll the display left and right
Zoom the display in and out
Pan display to the right
Pan display to the left
Pan display down
Pan display up
Zoom in
Zoom out
Zoom to image extent
Redraw the display

10

Keyboard Commands for LDV
The following keystroke and mouse commands are available in LDV. Many of thesecommands can also be accessed using the right-mouse menu.
Keystroke/mouseactionUp arrow
8 on numeric
keypadDown arrow
2 on numeric
keypadRight arrow
6 on numeric
keypadLeft arrow
4 on numeric
keypadPage up
9 on numeric
keypadPage down
3 on numeric
keypadHome
5 on numeric
keypad7 on numeric
keypadShift & right mousedrag
Mouse wheel
Ctrl & right mousedrag
Ctrl & Shift & rightmouse dragShift & left arrow
Control & left
arrow
Shift & control &left arrow
Shift & right arrow

Context

Description

Viewing

Rotate around screen X axis (away fromviewer)Viewing

Rotate around screen X axis (towardviewer)Viewing

Rotate around screen Y axis (away fromviewer)Viewing

Rotate around screen Y axis (towardviewer)Viewing

Rotate around screen Z axis (counterclockwise)

Viewing

Rotate around screen Z axis (clockwise)

Viewing

Reset rotation to original state

Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on

Raise/lower the measurement marker
Raise/lower the measurement marker
Move measurement marker
Increase/decrease measurement marker
diameterMove marker in negative direction along the
X axis of the data (not X axis of screen)
Rotate marker 1 degree in positive direction
Rotate marker 10 degrees in positive
direction
Move marker in positive direction along the
X axis of the data (not X axis of screen)11

Keystroke/mouseactionControl & rightarrow
Shift & control &right arrow
Shift & up arrow
Control & up arrow
Shift & control &up arrow
Shift & down arrow
Control & down
arrow
Shift & control &down arrow
EscapeBackspace

Enter
Space
+ (plus key)

+ (plus key)
Control & + (pluskey)- (minus key)

- (minus key)
Control & - (minus
key)

Context

Description

Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Measurement
marker on
Wiggle-vision on
Scan-vision on
Measurement
marker on
Measurement
marker on withmeasurement line
Measurement
marker on
Viewing
Viewing withimage plate
activeViewing withsurface active
Viewing using
fixed size
markers
Viewing withimage plate
activeViewing withsurface active
Viewing using
fixed size
markers

Rotate marker 1 degree in negative
direction
Rotate marker 10 degrees in negative
direction
Move marker in positive direction along the
Y axis of the data (not Y axis of screen)
Increase long axis of marker making themarker more elliptical (small step)
Increase long axis of marker making themarker more elliptical (large step)
Move marker in negative direction along the
Y axis of the data (not Y axis of screen)
Decrease long axis of marker making themarker more elliptical (small step)
Decrease long axis of marker making themarker more elliptical (large step)
Stop motion or stop scanning of clipping
planesClear marks and measurement points
Deletes last measurement point

Save measurement point
Activate right-mouse-button menu
Increase transparency of the image plate

Increase transparency of the surface model
Increase size of point markers

Decrease transparency of the image plate

Decrease transparency of the surface model
Decrease size of point markers

12Keystroke/mouseactionLetter A

Context

Description

Measurement
marker on

Shift & letter A
Letter B

Viewing
Measurement
marker on

Letter C

Measurement
marker on
Measurement
marker on

Turn on display of points within
measurement area and above current
marker height
Turn on display of all data points
Turn on display of points within
measurement area and below current
marker height
Move marker to the height of the closest
point within the measurement area
Center the measurement area on theclosest point and move the marker to theheight of the closest point within themeasurement area
Fits the measurement marker to the data
points above the measurement plate. Use
this option to rotate and adjust thedimensions of the marker to better “fit” themarker to a tree crown.
Move measurement marker to groundelevation

Shift & letter C

Letter F

Measurement
marker on

Letter G

Measurement
marker on andsurface display
enabledMeasurement
marker on
Measurement
marker on

Letter H
Shift & letter H

Letter I
Shift & letter I
Control & letter I
Shift & letter I
Letter L
Shift & letter L

Letter O

Image plate
enabledImage plate
enabledImage plate
enabledImage plate
enabledMeasurement
marker on
Measurement
marker on

Measurement
marker on

Move marker to the height of the highest
point within the measurement area
Center the measurement area on thehighest point and move the marker to theheight of the highest point within themeasurement area
Lower image plate (small step)
Raise image plate (small step)
Lower image plate (large step)
Raise image plate (large step)
Move marker to the height of the lowest
point within the measurement area
Center the measurement area on the lowest
point and move the marker to the height of
the lowest point within the measurementarea
Reset measurement marker to a circle

13

Keystroke/mouseactionLetter R

Context

Description

Measurement
Turn off display of points withinmarker on
measurement area
Letter S
Measurement
Move measurement area to the current
marker on
marked point (indicated with a 3D “+”)
Letter T
Measurement
Toggle display of points withinmarker on
measurement area
Letter X
YZ clipping
Lower clipping plane (small step)
enabledShift & letter X
YZ clipping
Raise clipping plane (small step)
enabledControl & letter X
YZ clipping
Lower clipping plane (large step)
enabledShift & letter X
YZ clipping
Raise clipping plane (large step)
enabledLetter Y
XZ clipping
Lower clipping plane (small step)
enabledShift & letter Y
XZ clipping
Raise clipping plane (small step)
enabledControl & letter Y
XZ clipping
Lower clipping plane (large step)
enabledShift & letter Y
XZ clipping
Raise clipping plane (large step)
enabledLetter Z
XY clipping
Lower clipping plane (small step)
enabledShift & letter Z
XY clipping
Raise clipping plane (small step)
enabledControl & letter Z
XY clipping
Lower clipping plane (large step)
enabledShift & letter Z
XY clipping
Raise clipping plane (large step)
enabled
F3
Viewing
Open ground augmentation point dialog
F4
Viewing
Open bare ground model dialog*
F5
Viewing
Open segmentation dialog*
F7
Viewing
Open plot location dialog*
F8
Viewing
Open attribute clipping dialog
F9
Viewing
Open tree measurement dialog*These features are considered experimental and not available in publicly released
versions of FUSION/LDV.

14

Keyboard Commands for PDQ
PDQ is a data visualization tool that provides a more robust data structure and provides
more responsive manipulation of large point clouds. It can be used in place of LDV toview samples generated by FUSION by checking the box next to “Use PDQ” in the
FUSION control panel. PDQ does not offer the same capabilities as LDV so it may not
be suitable for all applications. The following keystroke and mouse commands areavailable in PDQ.
PDQ offers a few special capabilities to help evaluate and view data:• Shade data using the intensity value for each return. Low intensity values arecolored brown and high Values are colored green.
• Shade data points using the return number and colors shown in Figure 2.
• Shade data points using the LAS classification codes (LAS format files only).
Color returns according to the value in the LAS classification field. The colors areshown in Figure 3.
• Color returns using the RGB value stored in the point records within LAS files. By
default, PDQ will use the RGB values, when present, to color points in LAS
format files.
• Provide a scanning mode useful when viewing .DTM format files representing
ground and canopy surfaces. This mode sets up an overhead view and allows
you to move the surface under the point-of-view using the “+” and “-“ keys.
PDQ supports drag-and-drop for .LDA, .LAS, .DTM, and ASCII raster files so you canview files by simply dragging them from a folder view and dropping them into PDQ’s
window.

Figure 2. Colors used when coloring by return. Points labeled in data file as return 0 will becolored using the color for return 1.

15

LAS versions <= 1.3 andV1.4: point records 0-50Created, never classified
1
Unclassified
2
Ground3
Low vegetation
4
Medium vegetation
5
High vegetation
6
Building
7
Low point (noise)
8
Model key-point (masspoint)
9
Water
10
Reserved
11
Reserved
12
Overlap points
13+ Reserved

LAS version 1.4 point records 6-10
0
1
2
3
4
5
6
7
8

Created, never classified
Unclassified
GroundLow vegetation
Medium vegetation
High vegetation
Building
Low point (noise)
Reserved

9
10
11
12
13
14
15
16
17
18
19-63
64-255Water
RailRoad surface
Reserved
Wire-guard (shield)
Wire-conductor (phase)Transmission tower
Wire-structure connector
Bridge deck
High noise
Reserved
User defined

Figure 3. Colors used to represent LAS classification codes in PDQ.

16

Keystroke/mouseactionUp arrow

Context

Description

Viewing

Down arrow

Viewing

Right arrow

Viewing

Left arrow

Viewing

Page upViewing

Page down
Home
Mouse wheel
EscapeA
B
C

Viewing
Viewing
Viewing
Viewing
Viewing
Viewing
ViewingE

Viewing

Shift-E

Stereo-viewing

Shift-Ctrl-E

Stereo-viewing

H
I
J
L
M
N

Viewing
Viewing
Viewing
Viewing
Viewing
ViewingO
P
Q

Viewing
Viewing
Viewing

R
S
Ctrl-TV

Viewing
Viewing
Viewing
ViewingW

Viewing

Rotate around screen X axis (away fromviewer)Rotate around screen X axis (towardviewer)Rotate around screen Y axis (away fromviewer)Rotate around screen Y axis (towardviewer)Rotate around screen Z axis (counterclockwise)
Rotate around screen Z axis (clockwise)
Reset rotation to original state
Zoom in/out
Stop data rotation
Toggle anaglyph modeSet background color to black
Color points using the RGB values in the
LAS file
Decrease eye separation in split-screen
stereo mode
Increase eye separation in split-screen
stereo mode
Reset eye separation in split-screen stereo
mode
Color points using the height/elevation
Toggle display of axes (wireframe cube)
Color points using the return number
Toggle coloring by LAS classification value
Toggle continuous rotation mode
Toggle coloring using intensity data from
LAS files (if available)
Reset orientation (overhead view)
Toggle points display on/iff
Toggle between the low- and high-resolution
surface representations (DTM only)
Begin/end recording to AVI fileToggle split-screen stereo mode
Capture screen image
Toggle between trackball and translation
motion control modes. Translation mode
allows you to roam through the data.
Set background color to white17

Keystroke/mouseactionX

Context

Description

Stereo-viewing

Z
Shift-Z
Ctrl +
Ctrl F5

DTM-scanning
DTM-scanning
Viewing
Viewing
Viewing

Toggle x-eyed/parallel-eyed viewing in splitscreen mode
Lower DTM while in scanning mode
Raise DTM while in scanning mode
Increase symbol size
Decrease symbol size
Toggle scanning mode for DTM evaluation
use + and - to move model

18

Command Line Utility and Processing Programs
Command line utilities and processing programs, called the FUSION LIDAR Toolkit or
FUSION-LTK, provide extensive processing capabilities including bare-earth point
filtering, surface fitting, data conversion, and quality assessment for large LIDAR
acquisitions. These programs are designed to run from a command prompt or usingbatch programs. The FUSION-LTK Programs generally have required and optionalparameters as well as switches to control program options. Switches should be
preceded by a forward slash “/”. If a switch has multiple parameters after the colon “:”,they should be separated by a single comma “,” with no spaces before or after thecomma. Command line programs display their syntax when executed with noparameters.

Command Line Options Shared By All Programs
There are several switches common to all FUSION-LTK programs. They control use of
the FUSION-LTK master log file, activate interactive run modes (when available), andreport program version information. The switches common to all FUSION-LTK programsare:interactive
quiet
verbosenewloglog:nameversionlocalenolaszipdll

skipfilecheck

Present a dialog-based interface. The /interactive switch is notsupported in most programs.
Suppresses the display of all status information during the run.
Displays status information as a program runs. The information may
describe the analysis progress or simply provide an indication thatthe program is still running. The additional information displayedwhen using the /verbose switch is not written to the LTKCL log file.
Erase the existing LTKCL_master.log file and start a new log file.
Use the name specified for the log file.
Displays only version information for the program.
Adjust program logic to input and output locale-specific numericformats (e.g. use a comma for the decimal separator). Use thisoption when you are having trouble reading ASCII input data andyou suspect that a comma is being used as the decimal separator.
This option will also change the comma separator used for output
data such as the CSV files written by CloudMetrics and GridMetrics.
Suppress the use of the LASzip DLL © Martin Isenburg for reading
LAS and LAZ (compressed LAS) files. If you specify this option, or
define the NOLASZIPDLL environment variable (use SETNOLASZIPDLL=TRUE), all FUSION programs that read point data
will rely on older code to read LAS files. Specifying this option also
disables support for compressed LAS (LAZ) files.
Skip logic that checks for valid point files and removes those that areinvalid prior to the start of point processing. This option is designed
to overcome some limitations with windows and wildcard processing.
This option is only useful for programs that read point data.

19

Command Log Files
All FUSION-LTK programs write entries into the FUSION-LTK master log files. Normallythese files are stored in the directory containing the FUSION programs in files named
LTKCL_master.log and LTKCL_master.csv. The /log:name switch can be used to force
a program to write its log entries to a different file. The environment variable, LTKLOG,
can also be used to change the default log file. When using LTKLOG, set the variable tothe full path for the log file (include the folder) unless you want the log file created in thecurrent directory. The .csv log name will be created from the LTKLOG variable using
and extension of .csv. The LTKLOG environment variable can be set from a commandprompt using the following DOS command:
set LTKLOG=mylogfile.log
Once the variable is set, it will be available for all programs run in the same DOS
window (command prompt window). Other windows will not be able to “see” thevariable. The variable can be cleared using the following DOS command:
set LTKLOG=
Use of the LTKLOG environment variable is most effective when the variable is set atthe beginning of a batch program used to accomplish some processing task and clearedat the end of the program. In this way you can direct all log entries associated with aproject to the same log files.
The .log entries include all output normally displayed on the screen when one of the
FUSION-LTK programs runs. All command line parameters are reported and any output
files are listed along with their creation date and time. Output related to the use of the/verbose switch is not included in the log file. The .csv entries simply list the commandlines used to invoke various FUSION-LTK programs. The following columns areincluded in the .csv log:
Program nameVersion
Program build dateCommand line parameters
Start time
Stop time
Elapsed time (seconds)
Status indicator
The logs have proven very useful when trying to remember the command line options
used to create a specific output product or the program version used to conduct ananalysis. By matching the file name, date and time to a log entry, you can easily repeata processing task. The log file can become quite large over time so it is important toeither manage the log by archiving the file and then deleting it (a new log file will bestarted the next time FUSION-LTK program is used) or by using specific log files fordifferent projects. The latter option is facilitated by the /log:name switch but this switch
must be used for all programs that are to write to the specified log file. Using the20

LTKLOG (see Appendix B: DOS Batch Programming and the FUSION LIDAR Toolkit for
details) environment variable allows you to change the log file without specifying the log
on each program command line.

Using 64-bit Versions of Command Line Programs
Beginning with version 4.0, most of the command line programs are available as 32and 64-bit executables. The advantages of the 64-bit versions include slightly faster
execution times and, more importantly, the ability to use more memory and thus workwith larger data sets (points and grid cells). The 64-bit versions of the programs are
identified with “64” at the end of the program name. The 64-bit version can be called
directly from a command prompt or in a batch file. The 32-bit versions also recognize a
special environment variable, FUSION64, which will transfer the command line to the64-bit version whenever a 32-bit version is executed. The advantage of using theenvironment variable is that you don’t have to know which programs have 64-bit
versions available. This also means that existing batch files and other scripts do notneed to be changed to use the 64-bit versions. You can simply define the environment
variable in a command prompt window or system-wide to use the 64-bit version
whenever a command line tool is used. The only disadvantage in using the environment
variable is that there will be a slightly longer execution time compared to directly callingthe 64-bit version as the 32-bit version passes control to the 64-bit version. The
command to set the environment variable looks like this:set FUSION64=TRUE
This command can be placed in any batch file or other processing script to takeadvantage of the 64-bit versions. You can also set this variable so it is active systemwide by following the instructions in this link:
https://helpdeskgeek.com/how-to/create-custom-environment-variables-in-windows/(accessed March 2020)
Create a new user variable named FUSION64 and set its value to TRUE.
AreaProcessor also includes an option to use 64-bit versions in the scripts it createsand uses. It does this by including the SET statement above in the main batch filecreated to direct processing.

Reading Compressed LAS Files (LAZ and COPC formats)
All command line programs, FUSION, and PDQ can read compressed LAS files stored
in the LAZ and COPC formats developed by Martin Isenburg if the LASzip DLL is in the
FUSION install folder. The DLL (32- and 64-bit versions) is available on the LAStools
website (the DLL is distributed as part of LAStools). To install the DLL, unpack the
LAStools distribution and copy the laszip.dll and laszip64.dll files from the LAStools\binfolder to the folder where FUSION is installed. When the DLL is available, FUSION
programs will use it to read LAS and LAZ format files. You can disable use of the DLL
using either the NOLASZIPDLL environment variable or the /nolaszipdll option available
for all command line programs. To disable use of the DLL using the environment

21

variable, use the following command in a command prompt window prior to running
FUSION programs:
set NOLASZIPDLL=TRUE
To enable use of the DLL in the same command prompt window, clear the variable asfollows:
set NOLASZIPDLL=
Compressed LAS files (LAZ format) are typically 75-85% smaller than thecorresponding LAS format file. However, using LAZ files will be slower than similar
operations using LAS files.
The FUSION/LDV viewing system does not perform well when using compressed files
unless the files are Cloud Optimized Point Tiles (COPC) format. With standard LAZ
files, extracting and viewing even small samples takes much longer, or may fail all
together, compared to the times when using uncompressed data. COPC format files,
which have their own indexing, work well in the FUSION/LDV viewing system. Separate
index files (.ldi and .ldx files), needed with LAS files, are not needed when using COPC
format files. Command line tools all perform well with compressed data.
All command line tools that support the /grid, /gridxy, /extent, and /align options workwith the index information in COPC files to make reading data more efficient. While
COPC files can be read as standard LAZ files, large files will be slow to read. Taking
advantage of the COPC indexing allows programs to read data covering a specificextent without reading the entire file. FUSION’s indexing system will work withcompressed files but reading data from the file will be much slower that the same filestored in COPC format.
The FUSION utility LDA2LAS can be used to compress and decompress LAS files.
Input for LDA2LAS is not limited to FUSION’s older LDA format.

FUSION-LTK Overview
The command line utility and processing programs are grouped into six types:
Point
Surface
Image
Conversion
Info
Misc

Operates on point data.
Operates on surfaces.
Operates on images.
Converts data from one format to another.
Provides descriptive information for a data source.
Miscellaneous utilities.

In general, Point utilities use point cloud data to produce either new point clouds orsurfaces and Surface utilities use surfaces to produce new surfaces or point data. The
set of programs included in the toolkit has, and will continue to, evolve as new analysis
methods are discovered or developed. The current set of programs addresses most22

tasks commonly needed when LIDAR data are obtained for a forestry-related project.
The following table summarizes the toolkit programs:
Program nameASCII2DTM

Category
Conversion

ASCIIImport

Conversion

CanopyMaxima

Surface

CanopyModel

Point

Catalog

Point

ClipData

Point

ClipDTM

Surface

CloudMetrics

Point

Cover

Point

CSV2Grid

Conversion

DensityMetrics

Point

DTM2ASCII

Conversion

DTM2ENVI

Conversion

DTM2TIF

Conversion

DTM2XYZ
DTMDescribe

Conversion
Misc

DTMHeader

Info

FilterData
FirstLastReturn

Point
Point

GridMetrics

Point

GridSample

Surface

Description
Converts an ASCII raster surface model into
the PLANS format used by FUSION
Converts variable format ASCII LIDAR data to
LDA or LAS format
Finds and reports surface maxima using avariable-size window based on surface height
Creates a canopy surface model from a point
cloud
Prepares a report describing a LIDAR dataset
and optionally indexes all data files for use in
FUSION
Clips subsamples of data using the lower left
and upper right corners of the area
Clips a portion of a DTM using a userspecified extent.
Computes metrics for a LIDAR data set(usually a data sample)
Computes cover estimates using a bare-earth
surface model and point cloud
Converts data stored in commas separated
value (CSV) format into PLANS dtm format
Computes point density metrics using
elevation-based slices
Converts PLANS dtm files into ASCII raster
formatConverts PLANS dtm files into ENVI standard
format files with associated header files
Converts PLANS dtm files into TIF grayscale
imagesConverts PLANS dtm files into XYZ points
Outputs information from PLANS dtm fileheaders to CSV file
Display header information for PLANS format
surface models and edit some header
elements
Applies various filters to return data
Extracts first and last returns from a point
cloud
Computes metrics for points falling withineach grid cell
Extracts samples of grid values around an XY
position23

GridSurfaceCreate

Point

GridSurfaceStats

Surface

GroundFilter

Point

ImageCreate

Point

IntensityImage

Point

JoinDBLDA2ASCII

Misc
Conversion

LDA2LAS

Conversion

MergeData

Point

MergeDTM

Surface

MergeRaster

Surface

PolyClipData

Point

RepairGridDTM

Surface

ReturnDensity

Point

SplitDTM

Surface

SurfaceSample
SurfaceStats

Surface
Surface

ThinData
TiledImageMap

PointsImage

TINSurfaceCreate

Point

TopoMetrics

Surface

TreeSeg

Surface &
Point
Misc

UpdateIndexChecksum/
RefreshIndexChecksum

Creates a gridded surface model from point
data
Computes surface area and volume for thesurface. Result is a raster layer.
Filters a point cloud to identify bare-earth
pointsCreates an image from LIDAR data files using
the intensity values and specified color ramp
Creates images using the intensity values
from a point cloud
Implements a database join for CSV data files
Converts point data stored in LDA format to
ASCII text format
Converts point cloud files in any supported
format to LAS format
Merges several point cloud files into a single
fileMerges several DTM files into a single DTM
file
Merges several ASCII Raster files into asingle ASCII Raster file
Clips point data using polygons stored inshapefiles
Expands DTM tiles created from ArcInfo GRID
files
Builds a raster data layer containing thenumber of returns in each cell
Subdivides a DTM format file into smaller
tiles.
Interpolates surface values for XY positions
Computes surface area and volume for an
entire surface. Result is a single set of values.
Thins point data to specific pulse densities
Creates HTML web page linking a master
image to individual image tiles using an HTML
image map
Creates a surface model using all points in
LIDAR data files (uses TIN then grids to final
cell size)
Computes topographic metrics from groundsurfaces.
Individual tree segmentation using CHM andclipping of point cloud using crown polygons
Updates the checksum used with a data index
file (used to prevent re-indexing after FUSION
upgrade, post spring 2006)24

ViewPic

Image

XYZ2DTM

Conversion

XYZConvert

Conversion

Displays image files stored in a variety offormats
Creates a PLANS dtm file from XYZ grid
pointsConverts ASCII data files into LDA format andindexes the LDA files

In general, point utilities that produce new point data files create data in LAS format
when the input data are also in LAS format. The LAS files produced by the utilities arecomplete in every way and include the projection information and other variable length
records from the source LAS files (if this information is available in the source files).
This allows you to mix FUSION tools with other tools that read and write LAS format
files. When input data are in FUSION’s LDA format, the tools produce LDA format
output since some information present in the LAS format is not available in the LDA
format.
The following sections describe the LTK programs in detail. These descriptions include
a brief overview of each program, detailed syntax information and command line
parameter descriptions, a technical description of the algorithms involved, andexamples showing common uses for the program. For programs that implement
algorithms developed by other researchers, appropriate citations are included.

25

ASCII2DTM
Overview
ASCII2DTM converts raster data stored in ESRI ASCII raster format into a PLANS
format data file. Data in the input ASCII raster file can represent a surface or rasterdata. ASCII2DTM converts areas containing NODATA values into areas with negative
elevation values in the output data file.

SyntaxASCII2DTM [switches] surfacefile xyunits zunits coordsys zone horizdatum vertdatum
gridfile
surfacefile
Name for output canopy surface file (stored in PLANS DTM format
with .dtm extension).
xyunits
Units for LIDAR data XY:
M for meters,
F for feet.
zunitsUnits for LIDAR data elevations:
M for meters,
F for feet.
coordsys
Coordinate system for the canopy model:
0 for unknown,
1 for UTM,
2 for state plane.
zone
Coordinate system zone for the canopy model (0 for unknown).
horizdatum
Horizontal datum for the canopy model:
0 for unknown,
1 for NAD27,
2 for NAD83.
vertdatum
Vertical datum for the canopy model:
0 for unknown,
1 for NGVD29,
2 for NAVD88,
3 for GRS80.
Gridfile
Name of the ESRI ASCII raster file containing surface data.
Switches
multiplier:#
offset:#nan

The standard FUSION-LTK toolkit switches are supported
Multiply all data values in the input surface by the constant.
Add the constant to all data values in the input surface. The constantcan be negative.
Use more robust (but slower) logic when reading values from the
input file to correctly parse NAN values (not a number).

Technical Details
ASCII2DTM recognizes both the (xllcorner, yllcorner) and (xllcenter, yllcenter) methods
for specifying the location of the raster data. The PLANS DTM format used in FUSION
26

always assumes that the data point (grid point) in the lower left corner is the model
origin and adjusts the location of the raster data accordingly.
ASCII2DTM examines the ASCII raster file to determine whether the elevation values
are integers or floating point numbers. It creates the PLANS DTM file using either
integer or 4-byte floating point values for the elevations.
ASCII2DTM always assumes that the data stored in ASCII raster format is interpreted
as a raster. That is, the value is representative of the entire grid cell. For data that
represent a surface where the values are actually elevations at specific points, the originof the DTM file is set to the center of the lower left cell in the grid.
If you receive surface data in ESRI’s GRID format it is possible to use GDAL
(http://www.gdal.org/) to convert the GRID data into ASCII raster format. Refer toAppendix D: Building multi-processor workflows using AreaProcessor for more details.
If you are using DTM2ASCII to convert data from the PLANS DTM format into ASCII
raster format, you should always use the /raster switch in DTM2ASCII to ensure thatyou can convert the data back to the PLANS DTM format using ASCII2DTM.

ExamplesThe following command converts the ASCII raster file named canopy_southern.asc intoa PLANS format data file named canopy.dtm. Data use the UTM projection in zone 10,
NAD83, NAVD88, and meters for both planimetric and elevation values.
ASCII2DTM canopy.dtm m m 1 10 2 2 canopy_southern.asc

27

ASCIIImport
Overview
ASCIIImport allows you to use the configuration files that describe the format of ASCII
data files to convert data into FUSION’s LDA format. The configuration files are createdusing FUSION’s Tools…Data conversion…Import generic ASCII LIDAR data… menu
option. This option allows you to interactively develop the format specifications needed
to convert and ASCII data file into LDA format.

SyntaxASCIIImport [switches] ParamFile InputFile [OutputFile]
ParamFile
Name of the format definition parameter file (created in FUSION's
Tools...Data conversion...Import generic ASCII LIDAR data... menu
option.
InputFile
Name of the ASCII input file containing LIDAR data.
OutputFile
Name for the output LDA or LAS file (extension will be provided
depending on the format produced). If OutputFile is omitted, theoutput file is named using the name of the input file and theextension appropriate for the format (.lda for LDA, .las for LAS).
Switches

LAS

The standard FUSION-LTK toolkit switches are supported. Progress
information for the conversion is displayed when the /verbose switch
is used.
Output file is stored in LAS version 1.0 format.

Technical Details
ASCIIImport allows FUSION to read most ASCII LIDAR data and convert it to the LDA
format. In operation, each line of the data file is read and parsed according the format
specifications. In general, one point record is created for each line in the input file. The
format specifications allow you to specify a variety of characters that separate data
values and assign specific columns of the data to LIDAR returns variables. ASCII files
with descriptive headers can be processed by specifying the number of lines to skip at
the beginning of the file.

ExamplesThe following command line converts the ASCII data file named tile0023.txt into an LDA
file named tile0023.lda using the format specifications stored in the parameter file
named project.importparam:
ASCIIImport project.importparam tile0023.txt
The following command line provides progress feedback while converting the ASCII
data file named tile0023.txt into an LDA file named 0023.lda using the format
specifications stored in the parameter file named project.importparam:
ASCIIImport /verbose project.importparam tile0023.txt 23.lda
28

CanopyMaxima
Overview
CanopyMaxima uses a canopy height model to identify local maxima using a variablesize evaluation window. The window size is based on the canopy height. For someforest types, this tool can identify individual trees. However, it does not work in all forest
types and it can only identify dominant and codominant trees in the upper canopy. The
local maxima algorithm in CanopyMaxima is similar to that reported in Popescu et al.
(2002) and Popescu and Wynn (2004) and implemented in the TreeVAW software (Kiniand Popescu, 2004).

SyntaxCanopyMaxima [switches] inputfile outputfile
inputfile
outputfile
Switches
ground:filethreshold:#
wse:A,B,C,D,[E,F]

mult:#res:#outxy:minx,miny,maxx
,maxy

crad

shape
img8
img24

Name for the input canopy height model file.
Name for the output CSV file containing the maxima.

Use the specified surface mode(s)l to represent the groundsurface: file may be wildcard or text list file (extension .txt).
Limit analysis to areas above a height of # units (default:
10.0).
Constant and coefficients for the variable window size
equation used to compute the window size given the canopy
surface height window:
width = A + B*ht + C*ht^2 + D*ht^3 + E*ht^4 + F*ht^5
Defaults values are for metric units: A = 2.51503, B = 0, C =0.00901, D = 0, E = 0, F = 0.
Use A = 8.251, B = 0, C = 0.00274, D = E = F = 0 whenusing imperial units.
Window size multiplier (default: 1.0).
Resolution multiplier for intermediate grids (default: 2.0).
A value of 2 results in intermediate grids with twice thenumber of rows and columns
Restrict output of tree located outside of the extent definedby (minx,miny) and (maxx,maxy). Tree on the left and bottom
edges will be output, those on the top and right edges willnot.
Output 16 individual crown radii for each tree. Radii start at 3
o'clock and are in counter-clockwise order at 22.5 degreeintervals.
Create shapefile outputs for the canopy maxima points andthe perimeter of the area associated with each maxima.
Create an 8-bit image showing local maxima and minima(use when 24 bit image fails due to large canopy model).
Create a 24-bit image showing local maxima and minima.

29

new
summary
projection:filenameminmax:#Create a new output file (erase output file if one exists).
Produce a summary file containing tree height summary
statistics.
Associate the specified projection file with shapefile andraster data products.
Change the calculation method for the min/max crown width.
Options:
0 = report the maximum and minimum crown radii
1 = report the maximum and minimum diameters
computed using radii offset by 180 degrees. There isno constraint to the relationship between the minimum
and maximum diameters so they could be offset by±22.5, ±45, ±67.5, or 90 degrees.
2 = report diameter along a N-S line and the diameter
along an E-W line
3 = report the maximum diameter and the diameter
perpendicular to the max diameter line and the rotation
to the max line

Technical Details
In operation, CanopyMaxima interpolates a new, higher resolution surface using the
inputfile and then used the new surface to find local maxima. The resolution of the new
surface is controlled using the /res:# switch. CanopyMaxima scans the new surface andidentifies the highest point within a variable window. The window size is determined by
the height of the surface at the center of the window using the following equation:
𝑤𝑖𝑑𝑡ℎ = 𝐴 + 𝐵 ∗ ℎ𝑡 + 𝐶 ∗ ℎ𝑡 2 + 𝐷 ∗ ℎ𝑡 3 + 𝐸 ∗ ℎ𝑡 4 + 𝐹 ∗ ℎ𝑡 5
The default equation coefficients (taken from Kini and Popescu 2004 for mixed pinesand deciduous trees) provide the following equation:
𝑤𝑖𝑑𝑡ℎ(𝑚) = 2.51503 + 0.00901ℎ𝑡 2This equation assumes that height (ht) is expressed in meters. For imperial units, thefollowing equivalent equation is recommended:
𝑤𝑖𝑑𝑡ℎ(𝑓𝑡) = 8.251 + 0.00274ℎ𝑡 2
Users of CanopyMaxima are encouraged to fit their own window size coefficients using
locally obtained tree height and crown width measurements.
As CanopyMaxima moves the window over the canopy height surface, the window size
is adjusted to produce a width (diameter) that is an odd multiple of the high-resolution
surface cell size. Then a circular window is used to identify the pixels that are comparedto the height of the pixel in the center of the window to determine if the center pixel is alocal maxima.

30

CanopyMaxima is most often used to identify individual dominant and codominant trees
as represented in a canopy height model. It works best for conifer trees that are
relatively isolated. In dense stands, trees growing in close proximity to one anothercannot be separated. The result is a single local maxima where there should be morethan one maxima. The algorithm does not perform well in deciduous forests because
the crown shape for such trees tends to be more rounded and crowns tend to overlap
one another near the top of the tree
Output from CanopyMaxima is a spreadsheet-compatible CSV file that contains thelocation of the maxima and the height value. In addition, the output is formatted suchthat it can be loaded into FUSION and displayed as individual tree models within point
cloud samples. The height to the base of the tree crown is computed as ½ the height
and the minimum and maximum crown widths are computed using crown radii derived
from 16 radial profiles extracted from the high-resolution canopy surface. Spacing ofpoints along the profile is half the cell size used for the high-resolution surface. The
crown radius along each profile is determined using one of two rules:• If a point is a local minimum, the horizontal distance to the point is used as thecrown radius along the profile,• If a series of three points have heights less than 66% of the tree height, thedistance the second point is used as the crown radius.
The default reported minimum and maximum crown widths are two times the average ofthe 16 radii (horizontal distances). The /minmax:# option provides control over the
method used to compute the minimum and maximum crown width and the crownrotation. The output .csv file can be used as “trees” in FUSION. FUSION always renders
crowns using a symmetric symbol and the average of the minimum and maximum
crown widths. If you use options 2 or 3 with the /minmax option, the trees will berendered correctly in the LDV as wireframe objects but not in FUSION.
When the /img8 or /img24 switches are used, an image is produced that shows thelocation so of the local maxima (red pixels) and local minima (blue pixels). The image isuseful as an overlay for orthorectified imagery to better understand how successfully thealgorithm identified individual trees.

ExamplesThe following example finds the local maxima using a canopy height surface named andsaves the maxima to the file named testtrees.csv. In addition, a 24-bit image is
produced showing the location of canopy maxima and minima.
CanopyMaxima /img24 canopy_maxima_test_1m.dtm testtrees.csv

31

CanopyModel
Overview
CanopyModel creates a canopy surface model using a LIDAR point cloud. By default,
the algorithm used by CanopyModel assigns the elevation of the highest return withineach grid cell to the grid cell center. CanopyModel provides for smoothing of thegenerated surface using a median or a mean filter or both. Specialized logic, activatedusing the /peaks switch, preserves local maxima in the surface while smoothing to force
the surface to adhere to the tops of trees. CanopyModel provides options to compute a
texture metric (coefficient of variation of surface values within an n by n window), slope,or aspect for the canopy model and output them as the final surface. When used with abare-earth model, CanopyModel subtracts the ground elevations from the returnelevations to produce a canopy height model. Output from CanopyModel is a PLANS
format DTM file that uses floating point elevation values and contains coordinate
projection information.

SyntaxCanopyModel [switches] surfacefile cellsize xyunits zunits coordsys zone horizdatumvertdatum datafile1 datafile2 …
surfacefile
cellsize
xyunits

zunitscoordsyszone
horizdatumvertdatum

datafile1

Name for output canopy surface file (stored in PLANS DTM format
with .dtm extension).
Desired grid cell size in the same units as LIDAR data.
Units for LIDAR data XY:
M for meters,
F for feet.
Units for LIDAR data elevations:
M for meters,
F for feet.
Coordinate system for the canopy model:
0 for unknown,
1 for UTM,
2 for state plane.
Coordinate system zone for the canopy model (0 for unknown).
Horizontal datum for the canopy model:
0 for unknown,
1 for NAD27,
2 for NAD83.
Vertical datum for the canopy model:
0 for unknown,
1 for NGVD29,
2 for NAVD88,
3 for GRS80.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT formats)...may
be wildcard or name of text file listing the data files. If wildcard or
text file is used, no other datafile# parameters will be recognized.

32

datafile2

Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on the lengthof each file name. When using multiple data files, it is best to use awildcard for datafile1 or create a text file containing a list of the data
files and specifying the list file as datafile1.

Switches
median:#smooth:#texture:#slope
aspectoutlier:low,highmultiplier:#
return:stringclass:string

ignoreoverlap
ground:file

hole:heightascii
surfacepeaks
pointcountApply median filter to model using # by # neighbor window.
Apply mean filter to model using # by # neighbor window.
Calculate the surface texture metric using # by # neighbor window.
Calculate surface slope for the final surface.
Calculate surface aspect for the final surface.
Omit points with elevations below low and above high if used with abare-earth surface this option will omit points with heights below low
or above high.
Multiply the output values by the constant (#).
Specifies the returns to be included in the sample (can include
A,1,2,3,4,5,6,7,8,9,F,L,O) Options are specified without commas(e.g. /return:123) For LAS files only: F indicates first and only
returns, L indicates last of many returns.
Used with LAS format files only. Specifies that only points withclassification values listed are to be used when creating the canopy
surface. Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character of string is“~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAX V1.4+ format).
Use the specified bare-earth surface model(s) to normalize the
LIDAR data. The file specifier can be a single file name, a“wildcard” specifier, or the name of a text file containing a list ofmodel files (must have “.txt” extension). In operation, CanopyModel
will determine which models are needed by examining the extentsof the input point data.
Defines the threshold for the hole filling logic. Any areas at or below
the height will be filled unless the /nofill option is used.
Write the output surface in ASCII raster format in addition to writing
the surface in DTM format.
Use the bare-earth surface model in conjunction with values
specified in /outlier to omit points based on their height above theground surface but create a surface that is not normalized relative
to the bare-earth surface (the surface uses the point elevations).
Preserve localized peaks in the final surface. Only useful with/median or /smooth.
Output the number of data points in each cell in addition to the
canopy surface/height values. Counts are output in .DTM format. If33

nofill

grid:X,Y,W,H

gridxy:X1,Y1,
X2,Y2

align:dtmfile

extent:dtmfile

rasterorigin

there are no points for a cell, the elevation/height value for the cell
is set to 999.0.
Don’t fill holes in the surface model. In general, holes result from alack of data within a cell. The default behavior is to fill holes in theinterior of the surface model.
Force the origin of the output grid to be (X,Y) instead of computing
an origin from the data extents and force the grid to be W units wideand H units high...W and H will be rounded up to a multiple ofcellsize.
Force the origin of the output grid (lower left corner) to be (X1,Y1)
instead of computing an origin from the data extents and force theupper right corner to be (X2, Y2). X2 and Y2 will be rounded up to a
multiple of cellsize.
Force alignment of the output grid to use the origin (lower left
corner), width and height of the specified dtmfile. Behavior is thesame as /gridxy except the X1,Y1,X2,Y2 parameters are read fromthe dtmfile.
Force the origin and extent of the output grid to match the lower left
corner and extent of the specified PLANS format DTM file but
adjust the origin to be an even multiple of the cell size and the widthand height to be multiples of the cell size.
Offset the origin and adjust the extent of the surface so raster data
products created using the surface will align with the extent
specified with the /grid or /gridxy options. /rasterorigin is only usedin conjunction with the /grid or /gridxy option.

The order of the filter median and smooth switches is important. The first filter specified
on the command line will be the first filter applied to the model (median or smooth). You
cannot use /texture:#, /slope, and /aspect in combination.

Technical Details
CanopyModel uses the return with the highest elevation to compute the canopy surface
model. If the /ground switch is used to produce a canopy height model, the groundelevation interpolated from the bare-earth surface model(s) is subtracted from the returnelevation prior to determining the highest return value. It is important that the bare-earthmodel(s) truly represents the ground surface as any spikes due to residual vegetation
returns in the point set used to create the bare-earth model will result in incorrect return
heights and possible an incorrect canopy height model.
The behavior of the /outlier switch depends on whether of not the /ground switch isused. Without the /ground switch, /outlier uses the return elevations and the low andhigh values to filter out returns based on the elevation. When used with the /groundswitch, the height above ground is used to filter out returns. In general, the /outlier
switch is more useful when used with the /ground switch.

34

When either of the smoothing switches is used (/smooth or /median), an initial surface iscomputed using the highest return elevation for each cell. Then the initial surface isused to produce the final, smoothed surface. During the smoothing operation, the/peaks switch activates logic that compares the cell being modified to the other cells inthe smoothing window. If the target cell elevation is higher that all the neighboring cell
elevations, its elevation will not be changed.
CanopyModel can be used with bare-earth point sets to create a ground surface modelthat sits on top of the bare-earth points. In contrast, GridSurfaceCreate creates asurface that represents the average elevation for all points within a cell so the final
surface it produces lies within the bare-earth point set. The /texture, /slope, and /aspectswitches can be used with bare-earth point sets to produce descriptive layers for the
ground surface.
By default, CanopyModel fills “holes” in the surface where there were no points. The
filling logic uses an eight-way search to find valid values on the surface and then uses a
distance weighted average to compute values for the “holes”. This hole-filling logic canbe disabled with the /nofill switch.

ExamplesThe following command will create a canopy surface model using a 5- by 5-meter grid.
XY and elevation data are in meters. Data are referenced in the UTM coordinate system
in zone 10. The horizontal datum is NAD83 and the vertical datum is NAVD88. Data
files used to create the surface are listed in a text file named list.txt (shown below).
CanopyModel canopy_surface.dtm 5 m m 1 10 2 2 list.txt
The text file used to specify data file names contains the following:
000263.las000264.las
000265.las
The following command will create the same canopy surface model but in this example,
data files are listed explicitly on the command line.
CanopyModel canopy_surface.dtm 5 m m 1 10 2 2 000263.las 000264.las 000265.las
The following command will create the same canopy surface model but in this example,
a wildcard specifier is used to reference the data files. When using wildcard specifiers,
you need to make sure the specifier will result in the correct list of data files. You cantest this by using the DIR command along with the specifier to verify the files that will be
used to create the surface model (e.g., DIR *.las)
CanopyModel canopy_surface.dtm 5 m m 1 10 2 2 *.las
The following command line will create a canopy height model using the ground models
contained in the current directory and the same data files as the precious example.
CanopyModel /ground:*.dtm canopy_height.dtm 5 m m 1 10 2 2 *.las35

The following command will create the surface model and then apply a 5 by 5 cell
median filter to smooth the surface (/median:5). Local maxima will be preserved in thesurface (/peaks) to force the surface to adhere to the tops of trees.
CanopyModel /peaks /median:5 canopy_surface.dtm 5 m m 1 10 2 2 *.las

36

Catalog
Overview
Catalog produces a set of descriptive reports describing several importantcharacteristics of LIDAR data sets. It is most often used to evaluate a new acquisition
for internal quality, completeness of data coverage and return or pulse density. The
primary output of Catalog is a web page that contains a summary of all data tiles
evaluated including attribute summaries for each tile and overall summaries for theentire data set. Catalog provides options that will create the index files needed to use
the LIDAR data with FUSION making it the logical first step in any analysis procedure.
In addition to the web page, Catalog can produce images representing the coveragearea, pulse and return densities, and intensity values for the entire acquisition. Whendata are stored in LAS format, Catalog includes a summary of points by classification
code from the LAS data. All images produced by Catalog have associated world files sothey can be used within FUSION to provide a frame-of-reference for analysis. Catalog
also produces a FUSION hotspot file that provides specific details for each data tile in
the FUSION environment.

SyntaxCatalog [switches] datafile [catalogfile]
datafile
catalogfile

Switches
image
index
newindex
drawtiles
coveragecountreturns

LIDAR data file template or name of a text file containing
a list of file names (list file must have .txt extension).
Base name for the output catalog file (extensions will be
added).

Create image files showing the coverage area for each
LIDAR file.
Create LIDAR data file indexes if they don't already exist.
Create new LIDAR data file indexes for all files (even if
they already exist).
Draw data file extents and names on the intensity image.
Create one image that shows the nominal coverage area
for all data files included in the catalog. Also creates a
FUSION hotspot file that provides details for each file inthe catalog.
Adds columns in the CSV and HTML output to show thenumber of returns by return number for each data file andall data files combined. Runs that use this option can takemuch longer to process because Catalog has to readevery point in the data files to count up the different
returns. In theory, LAS files have this information in theirheader. However, file produced by some version of
TerraScan do not have these fields populated with theactual number of data points by return number.

37

uselascounts

rawcounts

density:area,min,max

firstdensity:area,min,max

intensity:area,min,max

imageextent:minx, miny,maxx, maxy
bmp
outlier:multiplierUse the return counts stored in LAS file headers when
/countreturns is specified to speed up the processing.
Some software does not populate these items in theheader so you have to make sure that the LAS header
contains the return counts. When /countreturns is
specified without /uselascounts or when processing data
not stored in LAS format, the entire file is scanned tocount the number of returns by return number.
Outputs the number of returns (or first returns) in eachcell. Used in conjunction with the /density and /firstdensity
options. The output is in PLANS DTM format.
Creates an image for all data files that shows the return
density for the area represented by each pixel. area is the
pixel area, min is the minimum acceptable point density
per unit area, and max is the upper limit for theacceptable density range. Cells with point densities fallingwithin the min-max range are colored green, cells withpoint densities below the minimum are colored red, andcells with densities above the maximum are colored blue.
Creates an image for all data files that shows the densityof first returns for the area represented by each pixel.
area is the pixel area, min is the minimum acceptable
point density per unit area, and max is the upper limit for
the acceptable density range. Cells with first return
densities falling within the min-max range are coloredgreen, cells with point densities below the minimum arecolored red, and cells with densities above the maximum
are colored blue.
Creates an intensity image for all data files using the
average intensity for all first returns within each pixel.
area is the pixel area, min is the minimum intensity value,
and max is the maximum intensity value. A black to whitecolor ramp is mapped to the range of intensity values
defined by min and max. Ideally, min and max
correspond to the range of intensity values present in thedata. However, you may not always know the range ofvalues for a given data set.
Limit the area covered by image products to the specified
extent.
Save second copy of intensity image in BMP format withassociated world file.
Performs a simple analysis to identify data tiles that might
contain elevation outliers. The analysis marks tiles where
the minimum, maximum, or range of elevations areoutside the range defined by:mean value +- multiplier * std dev

38

class:string

ignoreoverlap
noclasssummary

validate:maxreturnprojection:filename

The default multiplier is 2.0.
(LAS files only) Specifies that only points withclassification values listed in string are to be included in
the processing. Classification values should be separated
by a comma e.g. (2,3,4,5). If the first character of string is“~”, all classes except those listed will be used. Older
versions used /lasclass. /lasclass will still work but new
scripts should use /class.
Ignore points with the overlap flag set (LAX V1.4+
format).
Do not create a summary of return counts by LAS
classification values. This summary requires an extra
read of the entire point data set and can add a significant
amount of time to processing. If you don’t need thesummary, use this option to speed things up.
Produce report describing potential errors in point data
files. Report will contain files with errors the might cause
problems for other FUSION programs.
Associate the specified projection file with image
products. Make sure the projection file uses the one-line
format and not a multiline format as some programs won’t
recognize the multiline format files.

The "image" switch requires data file indexes. If indices do not already exist for all data
files, use the "index" option to force their creation.

Technical Details
When creating intensity images, Catalog uses the average intensity for all returns withina cell to compute the grayscale color for the cell. This logic differs from that of theCreateImage program which uses the maximum intensity value for a cell. As a result,the images created by Catalog will differ from those created by CreateImage.
The outlier detection logic in Catalog is very limited. In areas dominated by flat or
relatively flat topography, the logic will usually identify data tiles with erroneous returns
due to birds, multipathing, or system noise. In areas with steep topography, the logic willoften miss such artifacts since the erroneous returns have elevations that may beoutside the range in the vicinity of the return but are within the range for the entire datatile.
The /density and /firstdensity switches should not be used with very small cell sizes(area <= 1 data unit). In general, LIDAR acquisitions result in uniformly spaced points
on the ground. However, the spacing varies across the scan for most systems andusing a cell that is too small will result in misleading results in the density images. Whenevaluating the density images, the user should consider the type of scan pattern usedby the LIDAR system and the acquisition specifications. The point densities will varydepending on the position within the scan area, the total scan width (angle), pulse rate,39

and flying speed. For acquisitions with minimal side lap, densities at the edge of thescan will be highly variable (for zig-zag scan patterns) when evaluated using a small cellsize.
The parameters for the /density and /firstdensity switches define the area of the cell andthe thresholds used to classify pulse/return density for the cell. Cells used for theseproducts are always square and the width/height is:𝑐𝑒𝑙𝑙𝑠𝑖𝑧𝑒 = √𝑐𝑒𝑙𝑙𝑎𝑟𝑒𝑎
Density thresholds are expressed in pulses (or return) per square unit using the sameunits as those used for horizontal positions of the returns. The Table 1 shows equivalentdensity values when the horizontal units are meters and feet.
The /image switch is obsolete. Use the /intensity switch instead. /image produces one
image for each data tile and while this may be useful for small data sets containing only
a few tiles, it produces a large number of images that must be examined when the data
set is large with many tiles. In addition, /image requires data indexing prior to creation of
the images. /intensity does not require index files and may be much faster when index
files are not needed for other analysis tasks.
Table 1. Equivalent pulse (or return) densities for metric and imperial units of measure.

Density (pulses (or returns) per unit2) when horizontal units
are:MetersFeet
0.5
0.04641
0.092920.185840.3716
60.557480.7432100.929112
1.1149The /rawcounts switch produces raster output that provides detailed information
describing the pulse (first return) and return density. The outputs are stored in the
PLANS DTM data format and can be converted to ASCII raster format using theDTM2ASCII utility. The /rawcounts switch is used in conjunction with the /density and/or/firstdensity switches and the output products use the same grid cell size specified inthese switches.
If you plan to process the point data to produce metrics over large areas using scripts
created by LTKProcessor, it is highly recommended that you use the /rawcounts switch
in combination with /firstdensity switch and a fairly small cell size. This will produce apulse density data layer that can be used by the LTKProcessor program to optimize thetile sizes used for processing. Cell size of around 10 m (100 m 2) provide sufficient detail40

to optimize the tile size. See “Appendix C: Using LTKProcessor to Process Data forLarge Acquisitions” for details regarding the use of LTKProcessor.
The /class(or /lasclass) switch lets you use specific types of returns for the Catalog
summaries. This option only works with data files stored in LAS format. Part of thestandard output for Catalog is a table that summarizes the number of returns byclassification value. Use of the /class switch will result in this summary for only theclassification values specified with the switch. The standard classification codes for LAS
files are shown in the following table:
LAS versions <= 1.3 andV1.4: point records 0-50Created, never classified
1
Unclassified
2
Ground3
Low vegetation
4
Medium vegetation
5
High vegetation
6
Building
7
Low point (noise)
8
Model key-point (masspoint)
9
Water
10
Reserved
11
Reserved
12
Overlap points
13+ Reserved

LAS version 1.4 point records 6-10
0
1
2
3
4
5
6
7
8

Created, never classified
Unclassified
GroundLow vegetation
Medium vegetation
High vegetation
Building
Low point (noise)
Reserved

9
10
11
12
13
14
15
16
17
18
19-63
64-255Water
RailRoad surface
Reserved
Wire-guard (shield)
Wire-conductor (phase)Transmission tower
Wire-structure connector
Bridge deck
High noise
Reserved
User defined

ExamplesThe following command produce a simple summary report containing the coordinate
extents, total number of returns, and the nominal return density for each data tile.
Output includes a web page (HTML file) and a spreadsheet compatible file containing
the summary information. No image files are produced.
Catalog *.las
The following command produces the overall summary information, creates index file for
FUSION, and produces intensity images and images depicting the pulse and return41

densities. The intensity image uses a 2.5- by 2.5-meter pixel (area = 6.25 m2) and maps
the range of intensity values from 0 to 90 to a grayscale color ramp. The return density
image uses a 5- by 5-meter pixel (area = 25 m2) and colors areas with less the 2
returns/m2 red, cells with 2 to 8 returns/m2 green and cells with more than 8 returns/m2
blue. The first return (or pulse) density image uses a 5- by 5-meter pixel (area = 25 m2)
and colors areas with less the 1 pulse/m2 red, cells with 1 to 6 pulses/m2 green and cellswith more than 6 pulses/m2 blue.
Catalog /index /intensity:6.25,0,90 /density:25,2,8 /firstdensity:25,1,6 *.las42

ClipData
Overview
ClipData creates sub-samples of LIDAR data for various analysis tasks. The subsample can be round or rectangular and can be large or small. ClipData provides manyof the same sampling options found in FUSION but it is not used by FUSION to performsubsampling of LIDAR data sets (FUSION has its own logic to accomplish this task).
ClipData is often used to create sample of LIDAR returns around a specific point ofinterest such as a plot center or GPS measurement point. Subsequent analyses using
programs like CloudMetrics facilitate comparing field data to LIDAR point cloud metrics.
ClipData can extract a single sample or multiple samples using a single command.
When creating several samples, it is much more efficient to use the optional syntax toclip several samples using a single command line.
ClipData can also sub-sample data within the sample area using the elevation values
for the returns. When used in conjunction with a bare-earth surface model, this logic
allows for sampling a range of heights above ground within the sample area.
ClipData can extract specific returns (1st, 2nd, etc) or first and last returns (LAS files only)
for the sample area. This capability, when used with a large sample area, can extract
specific returns from an entire data file.
As part of the sampling process, ClipData can add (or subtract) a fixed elevation fromeach return elevation effecting adjusting the entire sample up or down. This capability,
when used with a large sample area, can adjust entire data files up or down to helpalign data from different LIDAR acquisitions.

SyntaxClipData [switches] InputSpecifier SampleFile [MinX MinY MaxX MaxY]
InputSpecifier
SampleFile

MinX MinY
MaxX MaxY
Switches
shape:#

decimate:#

LIDAR data file template, name of a text file containing a list of filenames (must have .txt extension), or a FUSION Catalog CSV file.
Name for subsample file (extension will be added) or a text filecontaining sample information for 1 or more samples. Each line in
the text file should have the subsample filename and the MinX
MinY MaxX MaxY values for the sample area separated by
spaces or commas. The output filename cannot contain spaces.
Lower left corner of the sample area bounding box.
Upper right corner of the sample area bounding box.

Shape of the sample area:
0 rectangle,
1 circle.
Skip # points between included points (must be > 0).

43

ground:file
dtm:filezmin:#
zmax:#
zpercent:#heighttimemin:#timemax:#

anglemin:#anglemax:#zero

biaselev:#
return:stringclass:string

ignoreoverlap
line:#

noindexindex

Use the specified bare-earth surface model to normalize the
LIDAR data (subtract the bare-earth surface elevation from eachlidar point elevation). Use with /zmin to include points above zmin
or with /zmax to include points below zmax (file must be
FUSION/PLANS format). file may be wildcard or text list file
(extension .txt only) that specifies more than one ground surface
model. In operation, only the models that cover the sample area
will be used to normalize point data. The /ground switch wasadded to make ClipData more consistent with other LTK
programs.
Include points above # elevation. Use with /dtm to include points
above # height.
Include points below # elevation. Use with /dtm to include points
below # height.
Include only the upper # percent of the points. If # is (-) only thelower # percent of the points. # can be -100 to +100.
Convert point elevations into heights above ground using thespecified DTM file. Always Used with /dtm.
Include points with GPS times greater than # (LAS only).
Include points with GPS times less than or equal to # (LAS only).
Interpretation of # depends on the GPS time recorded in the LAS
point records.
Include points with scan angles greater than # (LAS only).
Include points with scan angles less than or equal to # (LAS only).
Save subsample files that contain no data points. This is usefulwhen automating conversion and analysis tasks and expecting a
subsample file every time ClipData is executed.
Add an elevation offset to every LIDAR point: # can be + or -.
Specifies the returns to be included in the sample. String can
include A,1,2,3,4,5,6,7,8,9,F,L. A includes all returns. For LAS
files only: F indicates first and only returns, L indicates last of
many returns. F and L will not work with non-LAS files.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character of stringis “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAX V1.4+ format).
LAS files only: Only include returns from the specified flight line.
Line numbering varies by acquisition so you need to know yourdata to specify values for the flight line number.
Do not use the data index files to access the data. This is usefulwhen the order of the data points is important or when all returns
for a single pulse need to stay together in the subsample file.
Create FUSION index files for the SampleFile.

44

lda

nooffsetcleanlasprecision:scaleX,
scaleY,scaleZ

Write output files using FUSION's LDA format when using LAS
input files. The default behavior after FUSION version 3.00 is towrite data in LAS format when the input data are in LAS format.
When using input data in a format other than LAS, sample files
are written in LDA format.
Produce an output point file that no longer has the correct georeferencing. This is used when you need to work with the point
cloud but cannot reveal the actual location of the features
represented in the point cloud. This option modifies the header
values in the LAS header for the output files.
Only output points that adhere to the LAS format specification(valid GPS time, return # from 1 to 5, within header extent, points
not flagged as withheld. Valid for LAS format input.
Control the scale factor used for X, Y, and Z values in output LAS
files. These values will override the values in the source LAS files.
There is rarely any need for the scale parameters to be smaller
than 0.001.

Technical Details
ClipData uses FUSION index files, when they are available, to determine which data
files need to be read to find returns within the sample area and to help reduce thenumber of points that need to be read within a given data file. Performance will besignificantly slower if the data has not been indexed. Indexing is best accomplishedusing the Catalog program.
If the /noindex switch is used, the index files will not be used. This is most often used
when you need to preserve the original pulse and point order after the clipping process.
When you specify the /index switch, ClipData creates FUSION index files for the sample
file if it contains points. Having the index file significantly improves the performance ofseveral LTK programs.
The method used to compute the radius for round sample uses the average of the widthand height of the sample area. This means that you should use sample cornercoordinates that define a square area. Anything other than a square area will yield
unexpected results when used with the /shape:1 switch.
The /class switch allows you to include or omit returns based on the value stored in the
LAS classification field. The LAS format specification includes a set of “standard” codesused to classify points. Some of the codes indicate specific features or structures andother indicate that the return is an outlier or point that should otherwise be ignored. The
standard classification codes for LAS files are shown in the following table:

45

LAS versions <= 1.3 andV1.4: point records 0-50Created, never classified
1
Unclassified
2
Ground3
Low vegetation
4
Medium vegetation
5
High vegetation
6
Building
7
Low point (noise)
8
Model key-point (masspoint)
9
Water
10
Reserved
11
Reserved
12
Overlap points
13+ Reserved

LAS version 1.4 point records 6-10
0
1
2
3
4
5
6
7
8

Created, never classified
Unclassified
GroundLow vegetation
Medium vegetation
High vegetation
Building
Low point (noise)
Reserved

9
10
11
12
13
14
15
16
17
18
19-63
64-255Water
RailRoad surface
Reserved
Wire-guard (shield)
Wire-conductor (phase)Transmission tower
Wire-structure connector
Bridge deck
High noise
Reserved
User defined

When using the /anglemin:# or /anglemax:# options the numeric parameter specifies avalue that is compared to the scan angle rank filed in the LAS point records. For LAS
format versions up to 1.3, this field is defined as:a signed one-byte number with a valid range from -90 to +90. The Scan Angle
Rank is the angle (rounded to the nearest integer in the absolute value sense) at
which the laser point was output from the laser system including the roll of theaircraft. The scan angle is within 1 degree of accuracy from +90 to –90 degrees.
The scan angle is an angle based on 0 degrees being nadir, and –90 degrees tothe left side of the aircraft in the direction of flight.
For LAS format version 1.4, an additional scan angle field is added that increases theresolution and range of the scan angles. The code for ClipData is designed to use thisfield when reading version 1.4 files but as of version 2.6 of ClipData, FUSION programs
can’t write version 1.4 files so ClipData will fail when working with version 1.4 files.

ExamplesThe following command clips a 100- by 100-meter square sample from a single data file(000263.las) and stores it in a file names test.las:
clipdata 000263.las test.las 520500 5196000 520600 5196100

46

The following command clips a 100- by 100-meter round sample from a single data file(000263.las) and stores it in a file names test.las:
clipdata /shape:1 000263.las test.las 520500 5196000 520600 5196100

47

ClipDTM
Overview
ClipDTM clips a portion of the gridded surface model and stores it in a new file. The
extent of the clipped model is specified using the lower left and upper right cornercoordinates.

SyntaxClipDTM [switches] InputDTM OutputDTM MinX MinY MaxX MaxY
InputDTM
OutputDTM
MinX MinY
MaxX MaxY
Switches
shrinkmultiplier:#

Name of the existing PLANS format DTM file to be clipped.
Name for the new PLANS format DTM file.
Lower left corner for the output DTM.
Upper right corner for the output DTM.

Shrink the extent of the input model by the amounts specified by
MinX MinY MaxX MaxY. MinX is removed from left side, MinY isremoved from bottom, MaxX is removed from right side, and MaxY
is removed from top.
Multiply the output values by the constant (#).

Technical Details
When clipping a DTM, the lower left corner will be rounded down and the upper rightcorner will be rounded up to the nearest multiple of the InputDTM cell size. If thespecified extent is outside the DTM area, the extent will be adjusted to match the extent
of the InputDTM. The OutputDTM will use the same cell size and projection information
as the InputDTM.

ExamplesThe following command line clips a subsample of the surface stored in FL_allarea.dtm
and stores the resulting surface in clip.dtm:
ClipDTM FL_allarea.dtm clip.dtm 567320.4 7654984.2 569490.6 7655439.9
The following reduces the size of a surface stored in FL_allarea.dtm by 50 units on all
sides and stores the result in shring.dtm:
ClipDTM /shrink FL_allarea.dtm cshrink.dtm 50.0 50.0 50.0 50.0

48CloudMetrics
Overview
CloudMetrics computes a variety of statistical parameters describing a LIDAR data set.
Metrics are computed using point elevations and intensity values (when available). In
operation, CloudMetrics produces one record of output for each data file processed.
Input can be a single LIDAR data file, a file template that uses DOS file specifier rules, a
simple text file containing a list of LIDAR data file names, or a LIDAR data catalog
produced by the Catalog utility. Output is appended to the specified output file unlessthe /new switch is used to force the creation of a new output data file. Output isformatted as a comma separated value (CSV) file that can be easily read by database,statistical, and MS-Excel programs.
CloudMetrics is most often used with the output from the ClipData program to compute
metrics that will be used for regression analysis in the case of plot-based LIDAR
samples or for tree classification in the case of individual tree LIDAR samples.

SyntaxCloudMetrics [switches] InputDataSpecifier OutputFileName
InputDataSpecifier

OutputFileName

Switches
above:#

newfirstinpulse
firstreturn
first
highpoint
subsetid

LIDAR data file template, name of text file containing a list of
LIDAR data file names (must have .txt extension), or a catalog
file produced by the Catalog utility.
Name for output file to contain cloud metrics (using a .csv willassociate the files with MS-Excel).

Compute various cover estimates using the specified
heightbreak (#). See the technical detail for specific cover
metrics that are computed.
Creates a new output file and deletes any existing file with thesame name. A header is written to the new output file.
Use only the first return for a pulse to compute metrics. Such
returns may not always be labeled as return 1.
Use only first returns to compute metrics.
Same as /firstreturn
Produce a limited set of metrics that includes only the highest
return within the data file.
Produce a limited set of metrics ([ID], #pts, Mean ht, Std dev ht,
75th percentile, cover). Must be used with the /above:# option.
Parse the data file name to create an identifier for the output
record. Data file names should include a number (e.g.
sample003.las) or the default identifier of 0 will be assigned to
the file. The identifier is placed in the first column of the output
record before the input file name.

49

rid

pa

minht:#

maxht:#

outlier:low,highignoreoverlap
strata:[#,#,#,…]

intstrata:[#,#,#,…]

kde:[window,mult]rgb:color

Parse the data file name to create an identifier for the output
record but start at the end of the filename. Data file names can
include any characters but the end of the name should include anumber preceded by a non-numeric character (e.g.
2017_01_13_sample003.las). The identifier is placed in the firstcolumn of the output record before the input file name.
Output detailed percentile data used to compute the canopy
profile area. Output file name uses the base output name with“_percentile” appended.
Use only returns above # (use when data in the input data files
have been normalized using a ground surface model. In older
versions of CloudMetrics this switch was htmin.
Use only returns below # (use when data is normalized to
ground) to compute metrics. The maxht is not used when
computing metrics related to the /strata or /intstrata options.
Omit points with elevations below low and above high. Whenused with data that has been normalized using a groundsurface, low and high are interpreted as heights above ground.
You should use care when using /outlier:low,high with /minht
and /maxht options. If the low value specified with /outlier isabove the value specified with /minht, the value for /outlier will
override the value specified for /minht. Similarly, if the high value
specified with /outlier is less than the value specified for /maxht,
the /outlier value will override the value for /maxht.
Ignore points with the overlap flag set (LAX V1.4+ format).
Count returns in various height strata. # gives the upper limit foreach strata. Returns are counted if their height is >= the lower
limit and < the upper limit. The first strata contains points < thefirst limit. The last strata contains points >= the last limit. Default
strata: 0.15, 1.37, 5, 10, 20, 30.
Compute metrics using the intensity values in various heightstrata. Strata for intensity metrics are defined in the same way
as the /strata option. Default strata: 0.15, 1.37.
Compute the number of modes and minimum and maximum
node using a kernal density estimator. Window is the width of amoving average smoothing window in data units and mult is amultiplier for the bandwidth parameter of the KDE. Default
window is 2.5 and the multiplier is 1.0
Compute intensity metrics using the color value from the RGB
color for the returns. Valid with LAS version 1.2 and newer data
files that contain RGB information for each return (point record
types 2, 3 and 7). Valid color values are R, G, B, or N. N (forNIR) is only valid for LAS 1.4+ files with point record formats 8
and 10.

50

relcoveralldensity

Obsolete as of CloudMetrics version 2.0. Metrics are computed
as part of the default set of metrics.
Compute the proportion of first (or all) returns above the mean
and mode values.
Obsolete as of CloudMetrics version 2.0. Metrics are computed
as part of the default set of metrics.
Use all returns when computing density (percent cover, cover
above the mean and cover above the mode) default is to use
only first returns when computing density.

Technical Details
CloudMetrics computes the following statistics using elevation and intensity values foreach LIDAR sample:
Total number of returns
Count of returns by return number (support for up to 9 discrete returns)
Minimum
Maximum
MeanMedian (output as 50th percentile)
ModeStandard deviation
Variance
Coefficient of variation
Interquartile distance
Skewness
Kurtosis
AAD (Average Absolute Deviation)
MADMedian (Median of the absolute deviations from the overall median)
MADMode (Median of the absolute deviations from the overall mode)
L-moments (L1, L2, L3, L4)
L-moment skewness
L-moment kurtosis
Percentile values (1st, 5th, 10th , 20th, 25th, 30th, 40th, 50th, 60th, 70th, 75th, 80th, 90th,
95th, 99th percentiles)
Canopy relief ratio ((mean - min) / (max – min))Generalized means for the 2nd and 3rd power (Elev quadratic mean and Elev
cubic mean)
In addition to the above metrics, CloudMetrics also computes various ratios of returns
above a heightbreak when the /above:# switch is used:
Percentage of first returns above a specified height (canopy cover estimate)
Percentage of first returns above the mean height/elevation

51

Percentage of first returns above the mode height/elevation
Percentage of all returns above a specified height
Percentage of all returns above the mean height/elevation
Percentage of all returns above the mode height/elevation
Number of returns above a specified height / total first returns * 100
Number of returns above the mean height / total first returns * 100
Number of returns above the mode height / total first returns * 100
In addition to the ratios above, the point counts used to compute these ratios are also
included in the output.
In FUSION V4.00, a new metric was added, profile area. Profile area was first describedin Hu, et al. 2019 as the area under the height percentile profile or curve. They foundthe metric useful to compare pre- and post-fire canopy structure at both the individual
tree and pixel scales. The implementation in CloudMetrics and GridMetrics varies fromthat described in Hu et al. 2019. Heights are normalized using the 99 th percentile height
instead of the maximum height to eliminate problems related to high outliers and thearea under the percentile curve is computed directly from 1 percent slices instead of
fitting a polynomial to the percentile heights and computing the area under thepolynomial. Testing of the alternate formulation showed little difference between the
profile area computed using the fitted polynomial and the raw percentile data. The lattermethod is computationally more efficient and it also eliminates the problem of selecting
the appropriate order for the polynomial. The /pa switch is available to output thepercentile data used to compute the profile area. Point heights when computing profile
area are constrained to be at least 0.0. It is common to have a few below-ground points
in data due to surface fitting and interpolation. The resulting negative heights cause
problems in the calculation of profile area so code was included to constrain the heights.
In addition, the 99th percentile height must be greater than 0 to compute profile area.
For cells for which this is not the case, profile area is set to a value of -9999.0.
The /highpoint and /subset switches were added to support very specific analyses. They
may not be useful for all users. When the /highpoint switch is used, only the following
statistics are reported:
Total number of returns
High point X
High point Y
High point elevation
When the /subset switch is used, only the following statistics are reported:
ID (if the /id switch is specified)Total number of returns
Mean height (or elevation)
Standard deviation of height (or elevation)
75th percentile value
Canopy cover estimate

52

Output is provided in CSV (comma separated values) format with one record (line) ofdata for each LIDAR data file processed. When the /new switch is used or when the
output file does not exist, a header record is added to the newly created output file.
Subsequent runs of CloudMetrics with the same output file will append data to theexisting file. Files produced by CloudMetrics are easily read in to MS-Excel for further
analysis.
When the /id switch is used, file names should include numbers. The logic used tocreate the identifier from the file name, simply looks for numeric characters and uses
them to create a number. If the file name does not include any numeric characters, thedefault identifier of 0 is assigned to the file. The /id switch affects all output including theshortened version produced when the /highpoint switch is used.
Output includes the full file specifier for the LIDAR data file as well as the “file title”. The“file title” contains only the filename portion of the file specifier. For example, if the full
specifier is “C:\LIDAR_data\clip0074.las”, the file title will be “clip0074”. This extra
identifier is useful when the results of the /id switch are ambiguous (two or morefilenames containing the same number).
If you mix the output from runs that use the /id or /above:# switches with runs that donot, column alignment will be incorrect in the output data file. The resulting files may notread correctly into database or spreadsheet programs.
The cover value computed in CloudMetrics when the /above:# switch is used iscomputed as follows:𝑐𝑜𝑣𝑒𝑟 =

(𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑓𝑖𝑟𝑠𝑡 𝑟𝑒𝑡𝑢𝑟𝑛𝑠 > ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘)𝑡𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑓𝑖𝑟𝑠𝑡 𝑟𝑒𝑡𝑢𝑟𝑛𝑠

Figure 4 illustrates the concept of estimating canopy cover using LIDAR first return data:
In Figure 4, overstory canopy is defined as any vegetation greater than the height break(3 meters in this example) above the ground. Of the 21 LIDAR pulses that enter the
canopy, 16 first returns are recorded above the 3-meter threshold. The LIDAR-based
overstory cover estimate would be computed as 16/21 or 76 percent. The height breakis specified with the /above:# switch.

53

Figure 4. Schematic of the cover calculation process.

The /firstinpulse and /firstreturn switches cause different behaviors. When /firstinpulse isused, logic tries to figure out which returns represent the first return for a each laser
pulse. When data are clipped into tiles for delivery or into samples representing specificareas (e.g., forest measurement plots), returns for a specific pulse may be split between
two data files. The result is that the return labeled as the first return for a pulse may not
be included in the sample. When /firstinpulse is specified, the first return for each pulse
is used to compute metrics even if it is not labeled as return 1. When /firstreturn is used,
only returns identified as the first return (return number 1) are used to compute metrics.
The percentile values are computed using the following method(http://www.resacorp.com/method_5.htm, last accessed August 2016):

54

Product moments are typically used to describe the characteristics of a distribution. The
most common moments are the first (mean), second (variance), third (skewness), andfourth (kurtosis). Variance provides an indication of the variability in the samples,skewness provides some indication of how asymmetric the distribution is, and kurtosis
gives an indication of how “peaky” that distribution is. Unfortunately these statistics
computed using product moments show considerable bias and variance depending on
the sample size and the presence of outliers. In addition, the range of values for
skewness and kurtosis is not bounded making it difficult to use them as predictor
variables in regression analyses. Using product moments, skewness is computed using
the following equation:and kurtosis is computed using the following equation:

The formulae for skewness and kurtosis were taken fromhttp://www.itl.nist.gov/div898/handbook/eda/section3/eda35b.htm (last accessed August2016).
A more robust set of statistics, based on the method of L moments, is presented by
Hosking (1990). L moments are computed using linear combinations of ordered data
values (elevation and intensity for LIDAR returns). Ratios of L moments provide
statistics that are comparable to variance, skewness and kurtosis described above. The
first four L moments (𝜆1 , 𝜆2 , 𝜆3 , 𝜆4 ) are estimated using the direct sample estimators
proposed by Wang (1996) and the L moment ratios corresponding to coefficient ofvariation (𝜏2 ), skewness (𝜏3 ), and kurtosis (𝜏4 ) are computed as follows (theoreticalparameter ranges are also shown):𝜆𝜏2 = 20 < 𝜏2 < 1

𝜆1

𝜆𝜏3 = 𝜆3−1 < 𝜏3 < 1

2

𝜆

1

2

4

𝜏4 = 𝜆4(5𝜏3 2 − 1) ≤ 𝜏4 < 1

Average Absolute Deviation (AAD) is computed using the following equation:

55

Median absolute deviation from the median (MADMedian) is a robust estimator of thevariability within a data sample. MADMedian is compute using the following equation:
𝑀𝐴𝐷𝑚𝑒𝑑𝑖𝑎𝑛 = 𝑚𝑒𝑑𝑖𝑎𝑛𝑖 (|𝑋𝑖 − 𝑚𝑒𝑑𝑖𝑎𝑛𝑗 (𝑋𝑗 )|)Median absolute deviation from the mode (MADMode) is another estimator of variability
within a data sample. MADMode is computed using the following equation:
𝑀𝐴𝐷𝑚𝑜𝑑𝑒 = 𝑚𝑒𝑑𝑖𝑎𝑛𝑖 (|𝑋𝑖 − 𝑚𝑜𝑑𝑒𝑗 (𝑋𝑗 )|)Generalized means for the 2nd (Elev quadratic mean) and the 3rd (Elev cubic mean)
power are computed using the following equation with p=2 and p=3 respectively:
𝑛

1

𝑝
1
𝑝
𝑀𝑝 = ( ∑ 𝑥𝑖 )𝑛𝑖=1Mode is computed by dividing the data range (either elevation or intensity) into 64
classes and counting the number of returns in each class. The mode is then the classwith the largest number of values. In cases where several classes have the same
number of returns, the mode will be the class with the lowest value. Mode values are
not necessarily unique since several values may occur with equal frequency. In
addition, the precision of the mode estimate varies depending on the height range of thepoint data. Data with a smaller range of heights will have a more precise value for themode while data with a larger range will have a less precise value. This occurs because
64 bins are always used to partition the data regardless of the height range of the data.
For these reasons, the mode should be used with caution. Mean or median may bebetter measures of the central tendency of the elevation or intensity values in a point
cloud.
The /strata and /intstrata options compute a subset of the metrics for points within thespecified height bands. The default strata heights (0.15, 1.37, 5, 10, 20, 30 for /strata
and 0.15, 1.37 for /intstrata) are provided to simplify use of these options. The following
metrics are computed for each height band when /strata is used:
Number of returns in the strata
Minimum elevation/height for the points in the strata
Maximum elevation/height for the points in the strata
Average elevation/height for the points in the strata
Mode value for elevation/height for the points in the strata

56

Median value for elevation/height for the points in the strata
Standard deviation of the elevation/height for the points in the strata
Skewness of the elevations/heights for the points in the strata
Kurtosis of the elevations/heights for the points in the strata
When /intstrata is used, the same metrics are computed using the intensity values forthe points in each height band.
The /kde option uses kernel density estimation (KDE) with a Gaussian kernel toconstruct a probability density function for the point heights in the sample. KDE isessentially a data smoothing approach used to make inferences regarding the
distribution of target elements based on the collection of returns in the sample. Outputs
from the KDE approach are the number of modes (peaks), the minimum and maximum
mode values (peak heights), and the range between the minimum and maximum mode
values. The formula for the kernel density estimator with a Gaussian kernel is:𝑝̂ (𝑥) =1𝑁(𝑥−𝑥𝑖 )2
)
−(
2ℎ2
∑𝑒

𝑁√2𝜋ℎ 𝑖=1

The x values range over the extent of the point heights. The number of samples, N, isfixed at 512. xi is the height of the i th point. The smoothing constant (h) is calculatedusing Silverman’s rule-of-thumb (Silverman 1986, p 48, eqn 3.31):
1ℎ = 0.9 ∗ 𝐴 ∗ 𝑁 −5
where:𝐴=

min (𝑠𝑡𝑑 𝑑𝑒𝑣, 𝑖𝑛𝑡𝑒𝑟𝑞𝑢𝑎𝑟𝑡𝑖𝑙𝑒 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒)
1.34

The smoothing constant is multiplied by the optional mult parameter. Prior to peakdetection, the probability density function is smoothed using a moving window averagewith a window size specified by the optional window parameter. A value of 0.0 for thewindow parameter disables the smoothing logic so peaks are derived from the “raw”
density function. Peaks are detected by looking for changes from a positive slope to anegative slope.
Use caution when using the /RGB switch since the order of the output columns for the
Intensity, R, G, B and NIR metrics are the same. It is very easy to mix outputs from runs
intended to compute the metrics using the color values with each other and those where
the actual intensity value was used to compute metrics.

ExamplesThe following command line would generate metrics for all LIDAR data files in thecurrent directory and store them in a CSV file named metrics.csv. If the output file,57

metrics.csv, already exists, output will be appended to the file and no header will be
added to the file.
cloudmetrics *.las metrics.csv
The following command would generate metrics for all LIDAR data files in the current
directory and store them in a new file named metrics.csv. If the output file, metrics.csv,
already exists, it will be overwritten and a new header line will be added before any
metrics are written. The names of individual data files will be used to create an identifierthat will be added as the first column of data in the output file.
cloudmetrics /new /id *.las metrics.csv

58

CoverOverview
Cover computes estimates of canopy closure using a grid. Output values for coverestimates range from 0.0 to 100.0 percent. Canopy closure us defined as the number ofreturns over a specified height threshold divided by the total number of returns withineach cell. In addition, Cover can compute the proportion of pulses that are close to abare-ground surface model to help assess canopy penetration by the laser scanner. Wit
the addition of an upper height limit, Cover can compute the proportion of returns fallingwithin specific height ranges providing estimates of relative vegetation density forvarious height strata.

SyntaxCover [switches] groundfile coverfile heightbreak cellsize xyunits zunits coordsys zone
horizdatum vertdatum datafile1 datafile2...
groundfile

coverfileheightbreakcellsize
xyunits

zunitscoordsyszone
horizdatumvertdatum

File specifier for the bare-ground surface model used to normalize all
return elevations. The file specifier can be a single file name, a“wildcard” specifier, or the name of a text file containing a list of model
files (must have “.txt” extension). In operation, Cover will determine
which models are needed by examining the extents of the input point
data.
Name for the cover data file. The cover data is stored in the PLANS
DTM format using floating point values.
Height break for the cover calculation.
Grid cell size for the cover data.
Units for LIDAR data XY:
M for meters,
F for feet.
Units for LIDAR data elevations:
M for meters,
F for feet.
Coordinate system for the cover data:
0 for unknown,
1 for UTM,
2 for state plane.
Coordinate system zone for the cover data (0 for unknown).
Horizontal datum for the cover data:
0 for unknown,
1 for NAD27,
2 for NAD83.
Vertical datum for the cover data:
0 for unknown,
1 for NGVD29,
2 for NAVD88,
3 for GRS80.

59

datafile1

datafile2

First LIDAR data file (LDA, LAS, ASCII LIDARDAT formats)...may be
wildcard or name of text file listing the data files. If wildcard or text fileis used, no other datafile# parameters will be recognized.
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on the length ofeach file name. When using multiple data files, it is best to use awildcard for datafile1 or create a text file containing a list of the data
files and specifying the list file as datafile1.

Switchesallclass:string

ignoreoverlap
penetration

upper:#

Use all returns to calculate the cover data. The default is to use only
first returns.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g. (2,3,4,5)
and can range from 0 to 31. If the first character of string is “~”, allclasses except those listed will be used.
Ignore points with the overlap flag set (LAX V1.4+ format).
Compute the proportion of returns close to the ground surface bycounting the number of returns within +-heightbreak units of theground.
Use an upperlimit when computing the cover value. This allows you to
calculate the proportion of returns between the heightbreak andupperlimit.

Technical Details
When computing cover, returns with elevations <= heightbreak are counted. Whencomputing cover with an upper height limit, returns with elevations (or height above
ground) >= heightbreak and <= upperlimit are counted. When computing penetration,
returns with heights above ground >= -heightbreak and <= +heightbreak are counted.
The specific equation when the /all switch is NOT used is:𝑐𝑜𝑣𝑒𝑟1𝑠𝑡 =(𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 1𝑠𝑡 𝑟𝑒𝑡𝑢𝑟𝑛𝑠 ≥ ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘)∗ 100
𝑡𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 1𝑠𝑡 𝑟𝑒𝑡𝑢𝑟𝑛𝑠

When the /all switch is used the equation is:𝑐𝑜𝑣𝑒𝑟𝑎𝑙𝑙 =(𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑟𝑒𝑡𝑢𝑟𝑛𝑠 ≥ ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘)∗ 100
𝑡𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑟𝑒𝑡𝑢𝑟𝑛𝑠

When the /penetration option is used without the /all option, this is the equation used:(−ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘 ≥ 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 1𝑠𝑡 𝑟𝑒𝑡𝑢𝑟𝑛𝑠 ≤ ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘)𝑝𝑒𝑛𝑒𝑡𝑟𝑎𝑡𝑖𝑜𝑛1𝑠𝑡 =∗ 100
𝑡𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 1𝑠𝑡 𝑟𝑒𝑡𝑢𝑟𝑛𝑠
60When the /penetration option is used with the /all option, this is the equation used:𝑝𝑒𝑛𝑒𝑡𝑟𝑎𝑡𝑖𝑜𝑛𝑎𝑙𝑙 =(−ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘 ≥ 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑟𝑒𝑡𝑢𝑟𝑛𝑠 ≤ ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘)∗ 100
𝑡𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 1𝑠𝑡 𝑟𝑒𝑡𝑢𝑟𝑛𝑠

Penetration and cover values computed using the same heightbreak will sum to 100.0
except where you have return heights equal to the heightbreak. For these cells, the sum
will be slightly higher than 100.0.
To produce cover estimates that are meaningful, the cell size must be larger than thesize of individual tree crowns. With small cell sizes (less than ~5 meters but the actual
value varies depending on the size of the tree crowns) the distribution of cover values
over a large area tends to be heavy on values near 0 and 100 because each cell serves
to test for the presence or absence of a tree instead of providing a reasonable sample
area for assessing vegetation cover. For most forest types, cell sizes of 15-meter orlarger produce good results.
By default, Cover uses only first returns to compute cover. All returns can be used by
specifying the /all switch. Figure 4 illustrates the concept of estimating canopy coverusing LIDAR first return data.

ExamplesThe following command creates cover estimates using a 15- by 15-meter grid and aheightbreak of 3 meters. Data are in the UTM coordinate system, zone 10, with units forboth horizontal values and elevations of meters. The data uses the NAD83 horizontal
and NAVD88 vertical datums.
Cover 000263_ground_1m.dtm 000263_cover_15m.dtm 3 15 m m 1 10 2 2 000263.las
The following command computes the proportion of the pulses that penetrate canopy toreach the ground using a 30- by 30-meter grid and a ground tolerance of 2 meters.
Cover /penetration 000263_ground_1m.dtm 000263_grndpen_30m.dtm 2 30 m m 1 10 2 2000263.las61

CSV2Grid
Overview
CSV2Grid converts data stored in comma separated value (CSV) format into ASCII
raster format. In operation, users specify the column from the CSV file to convert.
CSV2Grid expects a header file that corresponds to the input file. The header file nameis formed from the input file name by appending the text “_ascii_header” and changing
the extension to “.txt”. Normally, the CSV files used with CSV2Grid are produced by
GridMetrics.

SyntaxCSV2GRID [switches] inputfile column outputfile
inputfile
Name of the input CSV file. This file is normally output from
GridMetrics.
columnColumn number for the values to populate the grid file (column
numbers start with 1).
outputfile
Name for the output ASCII raster file.
Switches
multiplier:#ndzero:#Multiply all data values by the constant (#).
If the value in the target column is NODATA, look at the value incolumn # and, if it is a valid value (not NODATA), change the value
for the target column to 0.0 for output to the ASCII grid file. This
option is useful when the ASCII grid file will be used for further
analysis in GIS or statistical packages.

Technical Details
CSV2Grid must be able to find the header file associated with inputfile. The header
contains the ASCII raster grid header and is copied directly into the outputfile.
For use with ArcInfo, the outputfile should be named using an extension of “.asc”.

ExamplesThe following command converts the data from the third column of the CSV file named
return_density.csv into ASCII raster file named return_density.asc:
CSV2Grid return_density.csv 3 return_density.asc

62

DensityMetrics
Overview
DensityMetrics is designed to output a series of grids where each grid contains density
information for a specific range of heights above ground. Densities are reported as the
proportion of the returns within the layer. Output consists of a CSV file with columns that
correspond to the layers and PLANS format DTM files (one for each layer) containing
the point density information.

SyntaxDensityMetrics [switches] groundfile cellsize slicethickness outputfile datafile1 datafile2... datafileN
groundfile
File specifier for the bare-ground surface model used to normalize
all return elevations. The file specifier can be a single file name, a“wildcard” specifier, or the name of a text file containing a list ofmodel files (must have “.txt” extension). In operation,
DemsityMetrics will determine which models are needed byexamining the extents of the input point data.
cellsize
Desired grid cell size for the point density data in the same units as
the point data.
slicethickness
Thickness for each “slice” in the same units as the point elevations.
outputfile
Base file name for output. Metrics are stored in CSV format withthe extension .csv unless the /nocsv switch is specified, Other
outputs are stored in files named using the base name andadditional descriptive information.
datafile1
First LIDAR data file (LDA, LAS, ASCII LIDARDAT formats)...may
be wildcard or name of text file listing the data files. If wildcard or
text file is used, no other datafile# parameters will be recognized.
datafile2
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on the lengthof each file name. When using multiple data files, it is best to use awildcard for datafile1 or create a text file containing a list of thedata files and specifying the list file as datafile1.
Switches
outlier:low,highmaxsliceht:highignoreoverlap
nocsv
class:string

Ignore points with elevations below low and above high. Low andhigh are interpreted as heights above ground as defined by thegroundfile.
Limit the range of height slices to 0 to high.
Ignore points with the overlap flag set (LAX V1.4+ format).
Do not create a CSV output file for cell metrics.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included when computing
density metrics. Classification values should be separated by acomma e.g. (2,3,4,5) and can range from 0 to 31. If the first63

firstslices:#,#,#,…

grid:X,Y,W,H

gridxy:X1,Y1,
X2,Y2

align:dtmfile

buffer:width

cellbuffer:widthcharacter of string is “~”, all classes except those listed will beused.
Use only first returns to compute all metrics. The default is to use
all returns to compute the metrics.
Use specific slice height breaks rather that evenly spaced breaks
based on the range of heights in the data. You can specify amaximum of 64 slice heights. The first slice always starts at 0.0.
Slice heights must be specified in ascending order. The highest
slice will contain the count of all points with heights greater than orequal to the last height break. Slice height ranges are defined as:
lower ht <= point height < upper height.
Force the origin of the output grid to be (X,Y) instead of computing
an origin from the data extents and force the grid to be W units
wide and H units high...W and H will be rounded up to a multiple ofcellsize.
Force the origin of the output grid (lower left corner) to be (X1,Y1)
instead of computing an origin from the data extents and force theupper right corner to be (X2, Y2). X2 and Y2 will be rounded up toa multiple of cellsize.
Force alignment of the output grid to use the origin (lower left
corner), width and height of the specified dtmfile. Behavior is thesame as /gridxy except the X1,Y1,X2,Y2 parameters are read fromthe dtmfile.
Add an analysis buffer of the specified width (same units as LIDARdata) around the data extent when computing metrics but only
output metrics for the area specified via /grid, /gridxy, or /align.
When /buffer is used without one of these options, metrics are
output for an area that is inside the actual extent of the return data
as metrics within the buffer area are not output.
Add an analysis buffer specified as the number of extra rows andcolumns around the data extent when computing metrics but only
output metrics for the area specified via /grid, /gridxy, or /align.
When /cellbuffer is used without one of these options, metrics are
output for an area that is inside the actual extent of the return data
as metrics for the buffer area are not output.

Technical Details
The CSV files output (CSV file output is suppressed if the /nocsv switch is specified)from DensityMetrics include the row and column of the cell (0, 0 is upper left row/col),the maximum return height for the cell, the total number of returns in the cell, and thenumber of returns within each height slice. Returns are considered “in a slice” if theheight above ground is greater than or equal to the base height for the slice and lessthan the upper height for the slice. If a return is below the ground surface, the elevationis changed to 0.0 and it is counted in the lowest slice. A text file that contains the header
information for the CSV file is included for use with CSV2Grid. The header file is named64using the name of the output file with the phrase “_ascii_header” appended and theextension “.txt”.
When the /grid, /gridxy, or /align switches are used, DensityMetrics tests the extent ofindexed LDA files and LAS files to see if any points in the file fall within the specified
grid area. If the file extent and the grid area do not overlap, the file is skipped. This
allows you to use DensityMetrics to compute statistics for small sample areas without
identifying the specific data tiles that contain the sample. You specify the desired
sample area and all data tiles and let DensityMetrics figure out which tiles contain points
within the sample area. If you are not using indexed LDA files or LAS files, such an
approach will result in slow performance as every point in all tiles must be read andtested to see if it is within the grid area.
A PLANS format surface file is produced for each height slice. The cell values in thesurface are the proportion of returns within the slice expressed as a percentage ranging
from 0 to 100.
The number of slices that can be used in DensityMetrics depends on the extent of thedata, the cell size, and the amount of available memory. For processing efficiency,
DensityMetrics must hold the point count data for all slices in memory. Specifying asmall slicethickness without using a maxsliceht can result in too many slices in whichcase, DensityMetrics will fail.

ExamplesThe following command creates density metrics for the data stored in tile0023.las andoutputs both a CSV and PLANS surface files. Height slices are 3 meter in thickness andreturn densities are summed using a 5- by 5-meter cell.
DensityMetrics bareearth.dtm 5 3 tile0023_density.csv tile0023.las65

DTM2ASCII
Overview
DTM2ASC converts data stored in the PLANS DTM format into ASCII raster files. Suchfiles can be imported into GIS software such as ArcInfo. DTM2ASCII provides the samefunctionality as the Tools…Terrain model…Export model… menu option in FUSION.

SyntaxDTM2ASCII [switches] inputfile [outputfile]
inputfile
outputfile

Switches
csv

rastermultiplier:#

Name of the PLANS DTM file to be converted into ASCII raster format.
Name for the converted file. If outputfile is omitted, the output file namewill be constructed from the inputfile name and the extension .asc.
When the csv switch is specified, the default extension used to construct
an output file name is .csv.

Output data values in comma separated value format. Header is thecolumn number. Data are arranged in rows with the northern-most row
first in the file.
Interpret the DTM points as the attribute for a cell and adjust the originof the ASCII grid file so that the lower left data point is the center of thelower left grid cell. For almost all applications, you should use the/raster option.
Multiply the output values by the constant (#).

Technical Details
If the PLANS DTM file uses floating point data values, the ASCII raster file will use
floating point values with 6 digits to the right of the decimal point. If the PLANS DTM
uses integer values, the ASCII raster file will use integer values. NODATA will belabeled with a value of -9999.0000 for floating point files or -9999 for integer files.

ExamplesThe following command will convert a PLANS DTM file into ASCII raster format. The
output file will be named 000263_ground_1m.asc.
DTM2ASCII /raster 000263_ground_1m.dtm

66

DTM2ENVI
Overview
DTM2ENVI converts data stored in the PLANS DTM format into ENVI standard format
raster files. Such files can be imported into GIS software such as ENVI and ArcInfo.

SyntaxDTM2ENVI [switches] inputfile [outputfile]
inputfile
outputfile

Switches
south

Name of the PLANS DTM file to be converted into ASCII raster format.
Name for the converted file. If outputfile is omitted, the output file namewill be constructed from the inputfile name and the extension .nvi. The
associated ENVI header file is named by appending “.hdr” to the
inputfile name.

Specifies that data are located in the southern hemisphere.

Technical Details
The ENVI data file is created using the same numeric format as the PLANS DTM file. All
PLANS DTM data types are supported. Geo-referencing information is included in the
ENVI header file using the “map info” tag. Areas in the DTM grid that have no data willbe “marked” with a value of -9999.0 in the ENVI format file and the appropriate value
will be included in the “data ignore value” tag in the ENVI header file.

ExamplesThe following command will convert a PLANS DTM file into ENVI standard raster
format. The output file will be named 000263_ground_1m.nvi and the associated header
file will be named 000263_ground_1m.nvi.hdr.
DTM2ENVI 000263_ground_1m.dtm

67

DTM2TIF
Overview
DTM2TIF converts data stored in the PLANS DTM format into a TIFF image andcreates a world file that provides coordinate system reference data for the image. Such
images can be imported into GIS software or used in other analysis processes.

SyntaxDTM2TIF [switches] inputfile [outputfile]
inputfile
outputfile

Switchesmask

Name of the PLANS DTM file to be converted into ASCII raster format.
Name for the converted file. If outputfile is omitted, the output file namewill be constructed from the inputfile name and the extension .tif.

Produces a mask image showing the areas in the DTM with valid data
values. In the mask image, a value of 0 indicates a cell with invalid data
(NODATA value) and a value of 255 indicates a cell with a valid data
value.

Technical Details
DTM2TIF creates grayscale TIFF images that represent the data stored in a PLANS
format DTM file. The range of values in the DTM file is scaled to correspond to grayvalues ranging from 1 to 255 in the TIFF image. The gray level value of 0 is reserved toindicate NODATA areas in the DTM file (values less than 0.0). DTM2TIF creates aworld file to provide coordinates system information for the TIFF image. The world file isnamed using the same file name as the TIFF image but with the extension .tfw.

ExamplesThe following command will convert a PLANS DTM file into TIFF image. The output file
will be named 000263_ground_1m.tif and the associated world file will be named
000263_ground_1m.tfw.
DTM2TIF 000263_ground_1m.dtm

68

DTM2XYZ
Overview
DTM2XYZ converts data stored in the PLANS DTM format into ASCII text files
containing XYZ points. Such files can be imported into GIS software as point data withthe elevation as an attribute or used in other analysis processes.

SyntaxDTM2XYZ [switches] inputfile [outputfile]
inputfile
outputfile

Switchesvoid
csv

noheaderName of the PLANS DTM file to be converted into ASCII raster format.
Name for the converted file. If outputfile is omitted, the output file namewill be constructed from the inputfile name and the extension .xyz. If the/csv switch is used, the extension will be .csv.

Output points from DTM with NODATA value (default is to omit).
NODATA value is -9999.0 for the elevation.
Output XYZ points in comma separated value format (CSV). If /csv isused with no outputfile, an extension of .csv will be used to form theoutput file name.
Do not include the column headings in CSV output files. Ignored if /csv
is not used

Technical Details
The XYZ point file consists of one record for each grid point. Each record contains theX, Y, and elevation for the DTM grid point. If creating an ASCII text file, the values are
separated by spaces and if creating a CSV format file, by commas. For CSV files, thefirst line contains column labels unless the /noheader switch is specified.

ExamplesThe following command will convert a PLANS DTM file into XYZ points stored in ASCII
format. The output file will be named 000263_ground_1m.xyz.
DTM2XYZ 000263_ground_1m.dtm

69

DTMDescribe
Overview
DTMDescribe reads header information for PLANS format DTM files and outputs theinformation to an ASCII text file compatible with most spreadsheet and databaseprograms. DTMDescribe can provide information for a single file or multiple files.

SyntaxDTMDescribe [switches] inputfile outputfile
inputfile
outputfile

Switchesstats

DTM file name, DTM file template, or name of a text file containing a listof file names (must have .txt extension).
Name for the output ASCII CSV file. If no extension is provided, an
extension (.csv) will be added.

Compute descriptive statistics for the data values in the DTM.

Technical Details
DTMDescribe produced output files in comma separated value (CSV) format andincludes column labels in the first line of the file. The following header information fromthe DTM file is included in the CSV file:
File name
Descriptive name
Origin (X, Y)
Upper right (X, Y)
Number of columns
Number of rows
Column spacing
Row spacing
Minimum data value
Maximum data value
Horizontal units
Vertical units
Variable type
Coordinate system
Coordinate zone
Horizontal datum
Vertical datum

ExamplesThe following example outputs the header information for all DTM files in the current
directory to the CSV file named summary.csv.
DTMDescribe *.dtm summary.csv

70

DTMHeader
Overview
DTMHeader is an interactive program. It is described in the Command Line Utility
section because it provides a means to examine and modify PLANS DTM file header
information. DTMHeader allows you to easily view and change the header information
for a PLANS DTM file. To make it most convenient, associate the .dtm extension with
DTMHeader so you can simply double-click a .dtm file to view the header. The values in
the header that can be modified are:Planimetric units,
Elevation units,
Descriptive name,Coordinate system and zone,
Horizontal datum,
Vertical datum.

SyntaxDTMHeader [filename]filename

Name of the PLANS DTM file to be examined.

Technical Details
The standard FUSION-LTK switches are not recognized by DTMHeader and it does notwrite entries to the FUSION-LTK master log file.
When run with no filename, DTMHeader allows the user to interactively select a DTM
file for examination.
If you make changes to a header value, you will be prompted to save the file when you
exit the program or when you try to access a different DTM file.

71

FilterData
Overview
FilterData applies various filters to return data files to produce new return data files with
only the returns that meet the filter requirements. The most common application for
FilterType is to remove “outliers” from return data files. Other filter options overlay the
return data with a user-specified grid and produce output return files that contain only
the returns with the minimum or maximum elevation for each grid cell.

SyntaxFilterData [switches] FilterType FilterParms WindowSize OutputFile DataFile
FilterType

FilterParms

WindowSize
OutputFile
DataFile

Switcheslda

layersindex
invertminsd:#

Filtering algorithm used to remove returns from the DataFile(s).
The following options (by name) are supported:
outlierremoves returns above or below the meanelevation plus or minus FilterParms * standard
deviation of the elevations
outlier2
More robust outlier removal (experimental)
minimum removes all returns except the return with theminimum elevation
maximum removes all returns except the return with the
maximum elevation
Parameters specific to the filtering method. For outlier this is themultiplier applied to the standard deviation. For minimum andmaximum, FilterParms is ignored (but a value must be included on
the command line...use 0)
Size of the window used to compute the standard deviation ofelevations or the minimum/maximum return
Name of the output file. If any part of the name includes spaces,
include the entire name in double quotation marks
LIDAR data file name or template or name of a text file containing
a list of file names (list file must have .txt extension).

Write output files using FUSION's LDA format when using LAS
input files. The default behavior after FUSION version 3.00 is towrite data in LAS format when the input data are in LAS format.
When using input data in a format other than LAS, sample files
are written in LDA format.
Output intermediate raster data layers.
Create FUSION index files for the output file.
Inverts the elevations for points so the logic will work for points
below ground. Use with outlier2.
Minimum standard deviation for points within a comparison
window for filtering to take place. Default is 1.0 (same units as72

minpts:#minrange:#mingap:#gapratio:#class:string

ignoreoverlap
precision:scaleX,
scaleY,scaleZ

reclass:[#]elevation data). This switch is only useful when using the outlier
filter.
Minimum number of points in the comparison window for filtering
to take place. This option can be used with all filters but mustspecify at least 3 points when used with the outlier filter.
Minimum range in elevations within a window for outlier filtering totake place. Default is 150.0 elevation units Used only with theoutlier2 filter.
Minimum vertical distance that define a gap. Used to isolate points
above the majority of points in the filter window. Used only withthe outlier2 filter.
Proportion of points in window that can be above a vertical gap.
Ranges from 0.0 to 1.0 Used only with the outlier2 filter.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character of stringis “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAX V1.4+ format).
Control the scale factor used for X, Y, and Z values in output LAS
files. These values will override the values in the source LAS files.
There is rarely any need for the scale parameters to be smaller
than 0.001.
Change the classification code for points identified as outliers andwrite them to the output file. The optional value is the classification
code assigned to the points. Only valid when used with the outlier
and outlier2 filters.

Technical Details
FilterData was developed to help LIDAR data users eliminate outliers from filesdelivered by vendors. In general, vendors identify outliers (returns above expected
elevations for vegetation and structures or returns below the ground surface) and either
use the LAS classification field to label the return as an outlier or delete them from thefiles delivered to their client. However, sometimes not all outliers are removed. The
presence of unlabeled outliers can cause problems for bare-earth filtering algorithms
and vegetation analysis as well as other analyses. FilterData offers a way for the data
user to produce “clean” data files for use in subsequent analyses.
FilterData provides an outlier filter that identifies and removes returns based on therange of observed elevation values in the comparison window. In operation, the outlier
filter works by computing the mean elevation and standard deviation of elevations foreach cell in the comparison grid. Then, individual return elevations are compared torange defined as follows:𝑚𝑒𝑎𝑛 𝑒𝑙𝑒𝑣𝑎𝑡𝑖𝑜𝑛 ± (𝐹𝑖𝑙𝑡𝑒𝑟𝑃𝑎𝑟𝑚𝑠 ∗ 𝐸𝑙𝑒𝑣𝑎𝑡𝑖𝑜𝑛𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛)73

Only returns with elevations within the range are written to the output file. Generally,using a range of ± 5.0 * Standard deviation and a large window size (100 m) eliminates
most outliers. In areas if steep terrain with returns from birds, a range of ± 3 * Standard
deviation may produce better results. The outlier filter can also be used on return files
produced using the maximum filter to eliminate high returns from small objects such astransmission towers and lines. Flat areas with no above-ground features can result in avery low standard deviation of the return elevations. For data files containing suchareas, it may be necessary to use the /minsd:# switch to control filtering in cells withsmall standard deviations. The default is to use a minimum threshold standard deviationof 1.0 (same units as the return elevations). For most areas, this will be sufficient. If you
specify a smaller threshold, you may find that all returns within the comparison window
are removed.
FilterData also provides a minimum and maximum classification feature that produces
output files that contain only the return with the minimum or maximum elevations foreach cell in the comparison grid.

ExamplesThe following command line produces an output file (q1334585_NO.las) that contains
only returns with elevations that are within 4 standard deviations of the mean elevation
for all returns in the 10- by 10-meter grid cell:
FilterData outlier 4.0 10 q1334585_NO.las q1334585.las
The following command line produces an output file (q1334585_max.las) that contains
the returns with the maximum elevation within each 5- by 5-meter grid cell:
FilterData maximum 0 5 q1334585_max.las q1334585.las74

FirstLastReturn
Overview
FirstLastReturn extracts first and last returns from a LIDAR point cloud. It is mostcommonly used when the point cloud data are provided in a format that does not
identify the last return of a pulse. FirstLastReturn provided two definitions of last returns:
the last return recorded for each pulse and the last return recorded for pulse with morethan one return. The former includes first returns that are also the last return recorded
for a pulse and the latter does not.

SyntaxFirstLastReturn [switches] OutputFile DataFile
OutputFile

DataFile

Switches
index
ignoreoverlap
lastnotfirstuselaslda

precision:scaleX,
scaleY,scaleZ

Base file name for output data files. First and last returns are
written to separate files that are named by appending“_first_returns” and “_last_returns” to the base file name.
LIDAR data file template or name of a text file containing a list of
file names (list file must have .txt extension).

Create FUSION index files for the files containing the first andlast returns.
Ignore points with the overlap flag set (LAX V1.4+ format).
Do not included first returns that are also last returns in the last
returns output file.
Use information stored in the LAS point records to determine
which returns are first and last returns.
Write output files using FUSION's LDA format when using LAS
input files. The default behavior after FUSION version 3.00 is towrite data in LAS format when the input data are in LAS format.
When using input data in a format other than LAS, sample files
are written in LDA format.
Control the scale factor used for X, Y, and Z values in output LAS
files. These values will override the values in the source LAS
files. There is rarely any need for the scale parameters to besmaller than 0.001.

Technical Details
FirstLastReturn provides two options for determining which returns are the first and lastof a pulse. The first method, used with ASCII and LDA format files, identifies a newpulse (and a new first return) whenever it encounters a first return or a 2 nd, 3rd, 4th, .etc.
return without a corresponding 1st, 2nd, 3rd, etc. return. The first return of the pulse issaved to the first return output file and the last return of the previous pulse is saved to
the last return output file. The second method, available for use with LAS format files
only, relies on information stored in each point record to determine if a return is the firstor last return of the pulse. With both methods, use of the /lastnotfirst switch determines75whether or not first returns for pulses with only one return are included in the last return
output files. When the /lastnotfirst switch is specified, the last return output file willcontain only returns that are the “last of many” for the pulse.
FirstLastReturn does not use FUSION index files to read data as this could lead toseparation of returns from the same pulse when the returns occur in different tiles within
the indexing grid.
For projects where the data have been divided into tiles for delivery to the client, returns
from the same pulse will inevitably end up in different tiles and thus in different files. For
such projects, the first and last return output files will contain returns that may not truly
be a first or last return. If data for such projects is delivered in LS format, using the/uselas switch will prevent this problem and result in output files that contain the correct
returns.
OutputFile and DataFile can be the same since the actual output file names will be
modified.

ExamplesThe following command extracts the first and last returns from the LDA data file named
tile0023.lda and stores the returns in files named tile0023_resample_first_returns.lda
and tile0023_resample_last_returns.lda:
FirstLastReturn tile0023_resample.lda tile0023.lda
The following command extracts the first and “last of many” returns from the LDA data
file named tile0023.lda and stores the returns in files named
tile0023_resample_first_returns.lda and tile0023_resample_last_returns.lda and creates
FUSION index files for the output files:
FirstLastReturn /lastnotfirst /index tile0023_resample.lda tile0023.lda

76

GridMetrics
Overview
GridMetrics computes a series of descriptive statistics for a LIDAR data set. Output is araster (grid) represented in database form with each record corresponding to a single
grid cell. GridMetrics is similar to CloudMetrics except it computes metrics for all returns
within each cell in the output grid. Cloudmetrics computes a single set of metrics for theentire data set. The default output from GridMetrics is an ASCII text file with comma
separated values (CSV format). Field headings are included and the files are easily
read into database and spreadsheet programs. Optionally, GridMetrics can output rasterlayers stored in PLANS DTM format. GridMetrics compute statistics using both elevationand intensity values in the same run. GridMetrics can apply the fuel models developed
to predict canopy fuel characteristics in Douglas-fir forest type in Western Washington(Andersen, et al. 2005). Application of the fuel models to other stand types orgeographic regions may produce questionable results.

Syntax
GridMetrics [switches] groundfile heightbreak cellsize outputfile datafile1 [datafile2 ...
datafileN]
groundfile

heightbreakcellsize
outputfile

datafile1

datafile2

Name for ground surface model(s) (PLANS DTM with .dtm
extension)...may be wildcard or name of text file listing the data
files. Multiple ground models can be used to facilitate processingof large areas where a single model for the entire acquisition is
too large to hold in memory.
Height break for cover calculation.
Desired grid cell size in the same units as LIDAR data.
Base name for output file. Metrics are stored in CSV format with
.csv extension unless the /nocsv switch is used. Other outputs
are stored in files named using the base name and additionaldescriptive information.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT formats)...may
be wildcard or name of text file listing the data files. If wildcard or
text file is used, no other datafile# parameters will be recognized.
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on thelength of each file name. When using multiple data files, it is best
to use a wildcard for datafile1 or create a text file containing a listof the data files and specifying the list file as datafile1.

Switches
outlier:low,highclass:string

Omit points with elevations below low and above high. low andhigh are interpreted as heights above ground.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included when computing

77

ignoreoverlap
id:identifier

minpts:#minht:#

nocsv
nogroundfailnozdiskgroundnointdtm

firstnointensity

metrics. Classification values should be separated by a commae.g. (2,3,4,5) and can range from 0 to 31. If the first character ofstring is “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAX V1.4+ format).
Include the identifier string as the last column in every record in
the outputfile. The identifier will be included in all files containing
metrics (elevation, intensity, and topo). The identifier cannot
include spaces.
Minimum number of points in a cell required to compute metrics(default is 4 points).
Minimum height used for points used to compute metrics. Density
is always computed using all points including those with heights
below the specified minimum height.
Do not create an output file for cell metrics.
Do not use a ground surface model. When this option is
specified, the groundfile parameter should be omitted from thecommand line. Cover estimates, densitytotal, densityabove, anddensitycell metrics are meaningless when no ground surface
model is used unless the LIDAR data have been normalize to theground surface using some other process.
Verify that all ground surface models can be opened and readand exit immediately if there are any problems. The default
behavior is to go ahead and compute metrics using point
elevations (no normalization to create point heights).
Do not load ground surface models into memory. When thisoption is specified, larger areas can be processed but processing
may be 4 to 5 times slower. Ignored when /noground option isused.\Do not create an internal DTM to use when normalizing point
elevations. The default behavior is to create an internal modelthat corresponds to the extent of the point data (or the area
specified using the /grid, /gridxy, or /align switches). In somecases, creating the internal model causes problems withprocessing. Most often this caused problems for small areas withmetrics being computed for a large cell size. The internal model
was created to cover a slightly larger area than the data extent
resulting in bad metrics along the top and right sides of the data
extent.
Use only first returns to compute all metrics. Default is to use all
returns for metrics.
Do not compute metrics using intensity values (default is tocompute metrics using both intensity and elevation values).

78

rgb:color

fuel
grid:X,Y,W,H

gridxy:X1,Y1,
X2,Y2

align:dtmfile

extent:dtmfile

buffer:width

cellbuffer:width

strata:[#,#,#,…]

intstrata:[#,#,#,…]

Compute intensity metrics using the color value from the RGB
color for the returns. Valid with LAS version 1.2 and newer data
files that contain RGB information for each return (point record
types 2, 3 and 7). Valid color values are R, G, B, or N. N (for NIR)
is only valid for LAS 1.4+ files with point record formats 8 and 10.
Apply fuel parameter models (cannot be used with /first switch).
Force the origin of the output grid to be (X,Y) instead ofcomputing an origin from the data extents and force the grid to be
W units wide and H units high...W and H will be rounded up to a
multiple of cellsize.
Force the origin of the output grid (lower left corner) to be (X1,Y1)
instead of computing an origin from the data extents and force
the upper right corner to be (X2, Y2). X2 and Y2 will be rounded
up to a multiple of cellsize.
Force alignment of the output grid to use the origin (lower left
corner), width and height of the specified dtmfile. Behavior is thesame as /gridxy except the X1,Y1,X2,Y2 parameters are readfrom the dtmfile.
Force the origin and extent of the output grid to match the lower
left corner and extent of the specified PLANS format DTM file but
adjust the origin to be an even multiple of the cell size and thewidth and height to be multiples of the cell size.
Add an analysis buffer of the specified width (same units as
LIDAR data) around the data extent when computing metrics but
only output metrics for the area specified via /grid, /gridxy, or/align. When /buffer is used without one of these options, metrics
are output for an area that is inside the actual extent of the returndata as metrics within the buffer area are not output.
Add an analysis buffer specified as the number of extra rows andcolumns around the data extent when computing metrics but only
output metrics for the area specified via /grid, /gridxy, or /align.
When /cellbuffer is used without one of these options, metrics are
output for an area that is inside the actual extent of the returndata as metrics for the buffer area are not output.
Count returns in various height strata. # gives the upper limit foreach strata. Returns are counted if their height is >= the lower
limit and < the upper limit. The first strata contains points < thefirst limit. The last strata contains points >= the last limit. Default
strata: 0.15, 1.37, 5, 10, 20, 30.
Compute metrics using the intensity values in various heightstrata. Strata for intensity metrics are defined in the same way as
the /strata option. Default strata: 0.15, 1.37.

79kde:[window,mult]ascii

topo:dist,latraster:layers

Compute the number of modes and minimum and maximum
node using a kernel density estimator. Window is the width of amoving average smoothing window in data units and mult is amultiplier for the bandwidth parameter of the KDE. Default
window is 2.5 and the multiplier is 1.0
Store raster files in ASCII raster format for direct import into
ArcGIS. Using this option preserves metrics with negative values.
Such values are lost when raster data are stored using the
PLANS DTM format. This switch is ignored unless it is used withthe /raster switch.
Compute topographic metrics using the groundfile(s) and output
them in a separate file. Distance is the cell size for the 3 by 3 cell
analysis area and lat is the latitude (+north, -south).
It is likely that this option will be removed at some point. The
amount of code required to implement this option is quite large
and the DTM files produced by the option cannot support
negative numbers. There are better ways to get individual metrics
for input into other analyses. For example, you can use the
CSV2Grid utility to extract specific columns from the .CSV files
produced by GridMetrics. Use of the /raster option is
discouraged.
Create raster files containing the point cloud metrics. layers is alist of metric names separated by commas. Raster files are
stored in PLANS DTM format or ASCII raster format when the/ascii switch is used. Topographic metrics are not available withthe /raster:layers switch.
Available metrics are:count
Number of returns above the minimum
heightdensitytotal
total returns used for calculating coverdensityabove
returns above heightbreakdensitycell
Density of returns used for calculating
cover
min
minimum value for cellmaxmaximum value for cellmeanmean value for cellmode
modal value for cellstddevstandard deviation of cell values
variance
variance of cell values
cv
coefficient of variation for cellcover
cover estimate for cell
abovemean
proportion of first (or all) returns above
the mean80

abovemodeskewnesskurtosis
AAD
p01
p05
p10
p20
p25
p30
p40
p50
p60
p70
p75
p80
p90
p95
p99
iq
90m10
95m05
r1count
r2count
r3count
r4count
r5count
r6count
r7count
r8count

proportion of first (or all) returns above
the mode
skewness computed for cell
kurtosis computed for cellaverage absolute deviation from mean
for the cell
1st percentile value for cell (must be
p01, not p1)
5th percentile value for cell (must be
p05, not p5)
10th percentile value for cell
20th percentile value for cell
25th percentile value for cell
30th percentile value for cell
40th percentile value for cell
50th percentile value (median) for cell
60th percentile value for cell70th percentile value for cell75th percentile value for cell80th percentile value for cell
90th percentile value for cell
95th percentile value for cell
99th percentile value for cell75th percentile minus 25th percentile forcell
90th percentile minus 10th percentile forcell
95th percentile minus 5th percentile for
cellCount of return 1 points above theminimum height
Count of return 2 points above theminimum height
Count of return 3 points above theminimum height
Count of return 4 points above theminimum height
Count of return 5 points above theminimum height
Count of return 6 points above theminimum height
Count of return 7 points above theminimum height
Count of return 8 points above theminimum height81

r9countrothercountallcoverafcover
allcount
allabovemean
allabovemodeafabovemeanafabovemodefcountmean
fcountmodeallcountmean
allcountmodetotalfirst
totalallCount of return 9 points above theminimum height
Count of other returns above theminimum height(all returns above cover ht) / (total
returns)(all returns above cover ht) / (total first
returns)
number of returns above cover ht(all returns above mean ht) / (total
returns)(all returns above ht mode) / (total
returns)(all returns above mean ht) / (total first
returns)(all returns above ht mode) / (total first
returns)
number of first returns above mean ht
number of first returns above ht mode
number of returns above mean ht
number of returns above ht mode
total number of 1st returns
total number of returns

alldensity

For example, /raster:min,max,p75 would produce raster files
containing the minimum, maximum and 75th percentile values foreach cell.
This switch is obsolete as of GridMetrics version 3.0.

intensity

Use all returns when computing density (percent cover) default is
to use only first returns when computing density.
This switch is obsolete as of GridMetrics version 3.0.
Compute metrics using intensity values (default is elevation).

Technical Details
Output from GridMetrics is divided into several files. The point cloud metrics are stored
in two files. The first is identified as “elevation_stats” and the second as“intensity_stats”. The file with elevation metrics also contains a variety of cover metrics
computed using combinations of first and all returns. If the /kde switch is used, its output
variables (4 values) are placed at the end of all other metrics in the “elevation_stats” file.
In addition, header files containing coordinate system and grid cell size information are
created in the same folder as the metrics. The header files are used when data in CSV
format are converted into ASCII raster format. When either the /strata or /intstrata
options are used, their output is stored in a separate file (both elevation and intensity
strata metrics in the same file). The file is identified as “strata_stats”. A header is also82

created that contains the coordinate systems and grid cell size information. When the/topo:dist,lat switch is used, a third set of output files containing topographic attributes is
produced. For example, when /strata, /intstrata, and /topo switches are used and theoutputfile is specified as “metrics.csv” the following output files are produced:
metrics_all_returns_elevation_stats.csv
metrics_all_returns_elevation_stats_ascii_header.txt
metrics_all_returns_intensity_stats.csv
metrics_all_returns_intensity_stats_ascii_header.txt
metrics_all_returns_strata_stats.csv
metrics_all_returns_strata_stats_ascii_header.txt
metrics_topo_stats.csv
metrics_topo_stats_ascii_header.txt
If the /first switch is specified, the file names would change as follows:
metrics_first_returns_elevation_stats.csv
metrics_first_returns_elevation_stats_ascii_header.txt
metrics_first_returns_intensity_stats.csv
metrics_first_returns_intensity_stats_ascii_header.txt
metrics_first_returns_strata_stats.csv
metrics_first_returns_strata_stats_ascii_header.txt
metrics_topo_stats.csv
metrics_topo_stats_ascii_header.txt
GridMetrics computes the following descriptive statistics:
Column
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Elevation metric
Row
Col
Center X
Center Y
Total return count above htmin
Elev minimum
Elev maximum
Elev mean
Elev mode
Elev stddev
Elev variance
Elev CV
Elev IQ
Elev skewness
Elev kurtosis
Elev AAD
Elev L1
Elev L2
Elev L3
Elev L4
Elev L CV
Elev L skewness

83

Intensity metric
Row
Col
Center X
Center Y
Total return count above htmin
Int minimum
Int maximum
Int meanInt mode
Int stddev
Int variance
Int CVInt IQ
Int skewness
Int kurtosis
Int AADInt L1
Int L2Int L3
Int L4
Int L CV
Int L skewness

Column
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

Elevation metric
Elev L kurtosis
Elev P01
Elev P05
Elev P10
Elev P20
Elev P25
Elev P30
Elev P40
Elev P50
Elev P60
Elev P70
Elev P75
Elev P80
Elev P90
Elev P95
Elev P99
Return 1 count above htmin
Return 2 count above htmin
Return 3 count above htmin
Return 4 count above htmin
Return 5 count above htmin
Return 6 count above htmin
Return 7 count above htmin
Return 8 count above htmin
Return 9 count above htmin
Other return count above htmin
Percentage first returns above
heightbreak
Percentage all returns above
heightbreak(All returns above heightbreak) /(Total first returns) * 100
First returns above heightbreakAll returns above heightbreak
Percentage first returns above
mean
Percentage first returns above
mode
Percentage all returns above mean
Percentage all returns above mode
(All returns above mean) / (Total
first returns) * 100(All returns above mode) / (Total
first returns) * 100
First returns above meanFirst returns above mode
All returns above mean
All returns above mode
Total first returns
Total all returns
Elev MAD median
Elev MAD mode
Canopy relief ratio((mean - min) / (max – min))Elev quadratic mean

84

Intensity metric
Int L kurtosis
Int P01
Int P05
Int P10Int P20
Int P25
Int P30
Int P40
Int P50
Int P60
Int P70
Int P75
Int P80
Int P90
Int P95
Int P99

Column
70
71
72
73
74
75

Elevation metric
Elev cubic mean
Profile area
KDE elev modes*
KDE elev min mode*
KDE elev max mode*
KDE elev mode range*

Intensity metric*In FUSION V4.0 and later, these metrics have been shifted to the right 1 column.
When the /topo:dist,lat switch is used, the following metrics are computed:
Column
1
2
3
4
5
6
7

8
9
10
11

Topographic metric
Row
Col
Center X
Center Y
Surface elevation
Surface slope (degrees)
Surface aspect (degrees azimuth, 0degrees at 12 o’clock, increasing
clockwise)
Profile curvature * 100 (in directionof slope)
Plan curvature * 100 (perpendicular
to slope)
Solar radiation index
Overall curvature

When the /strata or /intstrata switch is used, the computed strata metrics are stored in asingle file as described above. The first set of columns contains the elevation metrics
and the second set of columns contains the intensity metrics. The bounding elevations
for the elevation and intensity strata can be different so care should be taken to ensurethat any additional analyses use the metrics correctly. The following strata metrics arecomputed:
Column
1
2
3
4
5
6
7
8
9
10
11
12
…

Strata metric
Row
Col
Total return count for 1st strata
Minimum elevation for 1st strata
Maximum elevation for 1st strata
Average elevation for 1st strata
Mode of elevations for 1st strata
Median elevation for 1st strata
Standard deviation of elevations within the 1st strata
Coefficient of variation for elevations within the 1st strata
Skewness of elevations within the 1st strata
Kurtosis of elevations within the 1st strata
Metrics for additional elevation strata
Total return count for 2nd strata
Minimum intensity for 2nd strata85Column…

Strata metricMaximum intensity for 2nd strata
Average intensity for 2nd strata
Mode of intensity for 2nd strata
Median intensity for 2nd strata
Standard deviation of intensity within the 2nd strata
Coefficient of variation for intensity within the 2nd strata
Skewness of intensity within the 2nd strata
Kurtosis of intensity within the 2nd strata
Metrics for additional intensity strata

The /raster switch is provided to make it easy to compute a few metrics and convert thelayers into files compatible with ArcInfo. The PLANS DTM format used for the layers
cannot represent negative values so you should be careful using this option as a few ofthe layers will often have negative values. In addition, the layers produced when the/raster switch is used must be held in memory so fewer points (returns) can beprocessed when the /raster switch is used. The actual effect on the number of points
depends on the number of raster layers requested and the size of the bare-groundsurface models used to normalize return elevations. In general, use of the /rasterswitch is not recommended. You can easily extract specific metrics from the CSV
output file to create ASCII raster files using the CSV2Grid utility and you can merge
several ASCII raster files into a single file using the MergeRaster utility.
When computing cover, returns with elevations <= heightbreak are counted. Covervalues are computed as described in the CloudMetrics section. The specific equation is:
𝐶𝑜𝑣𝑒𝑟 =(#𝑟𝑒𝑡𝑢𝑟𝑛𝑠 > ℎ𝑒𝑖𝑔ℎ𝑡𝑏𝑟𝑒𝑎𝑘)𝑡𝑜𝑡𝑎𝑙 𝑟𝑒𝑡𝑢𝑟𝑛𝑠

To produce cover estimates that are meaningful, the cell size must be larger than
individual tree crowns. With small cell sizes (less than 5 meters) the distribution of covervalues over a large area tends to be heavy on values near 0 and 100 because each cell
serves to test for the presence or absence of a tree instead of providing a reasonablesample area for assessing vegetation cover. For most forest types, cell sizes of 15meters or larger produce good results.
Figure 4 illustrates the concept of estimating canopy cover using LIDAR first return data.
If the densitycell raster data layer is requested, it will specify the proportion of the
returns above the cover height limit. Normally this would be the proportion of first
returns. If the alldensitycell raster data layer is requested, the resulting layer would
represent the proportion of all returns above the cover height limit.
When the /grid, /gridxy, or /align switches are used, GridMetrics tests the extent ofindexed LDA files and LAS files to see if any points in the file fall within the specified
grid area. If the file extent and the grid area do not overlap, the file is skipped. This
allows you to use GridMetrics to compute statistics for small sample areas without
identifying the specific data tiles that contain the sample. You specify the desired

86sample area and all data tiles and let GridMetrics figure out which tiles contain points
within the sample area. If you are not using indexed LDA files or LAS files, such an
approach will result in slow performance as every point in all tiles must be read andtested to see if it is within the grid area.
Distribution statistics (skewness and kurtosis) are computed using product moments
and L moments as described in the CloudMetrics description.
The median of the absolute deviations from the median (MADMedian) and the medianof the absolute deviations from the mode (MADMode) are compute as described in the
CloudMetrics description.
The generalized mean for the 2nd power (also called the quadratic mean and labeled as“Elev quadratic mean”) and the 3rd power (labeled as “Elev cubic mean”) are computed
as described in the CloudMetrics description.
In FUSION V4.00, a new metric was added, profile area. Profile area was first describedin Hu, et al. 2019 as the area under the height percentile profile or curve. They foundthe metric useful to compare pre- and post-fire canopy structure at both the individual
tree and pixel scales. The implementation in CloudMetrics and GridMetrics varies fromthat described in Hu et al. 2019. Heights are normalized using the 99 th percentile height
instead of the maximum height to eliminate problems related to high outliers and thearea under the percentile curve is computed directly from 1 percent slices instead of
fitting a polynomial to the percentile heights and computing the area under thepolynomial. Testing of the alternate formulation showed little difference between the
profile area computed using the fitted polynomial and the raw percentile data. The lattermethod is computationally more efficient and it also eliminates the problem of selecting
the appropriate order for the polynomial. Point heights when computing profile area areconstrained to be at least 0.0. It is common to have a few below-ground points in data
due to surface fitting and interpolation. The resulting negative heights cause problems in
the calculation of profile area so code was included to constrain the heights. In addition,
the 99th percentile height must be greater than 0 to compute profile area. For cells forwhich this is not the case, profile area is set to a value of -9999.0.
When GridMetrics is used with the /topo:dist,lat switch, a solar radiation index (SRI) andother topographic indices are computed for each input point. SRI combines information
about the aspect, slope, and latitude into a single index that describes the amount ofsolar radiation theoretically striking an arbitrarily oriented surface during the hour
surrounding noon on the equinox (Keating et al. 2007). The parameters for the /topo
switch define the size of the surface cell and the latitude for the study area. In operation,
elevations are interpolated for points defining a three- by three-cell grid where each gridcell is dist by dist units. These elevations are then used to compute the slope, aspect,and curvature for the surface patch (Zevenbergen and Thorne 1987). For mostapplications, the distance (or cell size) should not be small. The overall goal is todescribe the terrain shape and not to capture every micro-topographic detail. SRI as
defined by Keating et al. (2007) ranges from -1.0 to 1.0 but the full range is not possible87

at every location due to the effect of latitude on the index. For GridMetrics, this range
has been adjusted to range from 0.0 to 2.0. SRI does not consider the change in theamount of solar radiation that occurs over the course of a day or year or changes that
result from topographic shading. However it distills information about slope, aspect, andlatitude into a single linear value useful for comparing locations. When /topo:dist,lat is
specified, output includes the slope, aspect, profile curvature (along the slope), plancurvature (across the slope), and SRI all reported with 6 decimal digits regardless of thestorage type for the elevations in the surface model. The formula used to compute SRI(adapted from Keating et al. 2007) is:
𝑆𝑅𝐼 = 1.0 + cos(𝑙𝑎𝑡𝑖𝑡𝑢𝑑𝑒) ∗ cos(𝑠𝑙𝑜𝑝𝑒) + sin(𝑙𝑎𝑡𝑖𝑡𝑢𝑑𝑒) ∗ sin(𝑠𝑙𝑜𝑝𝑒) ∗ cos (𝑎𝑠𝑝𝑒𝑐𝑡)
where:
latitude is the latitude in degrees with north latitudes positive and south latitudes
negative
slope is the inclination of the surface from the horizontal position in degrees
aspect is the surface azimuth angle in degrees relative to south (180.0 – calculated
aspect)
The median, quartile and percentile values calculated for the points are computed using
the following method (http://www.resacorp.com, last accessed December 2005):

The fuel models available in GridMetrics are taken from Andersen et al. (2005). The
models are applicable to Douglas-fir forest types in Western Washington. Application toother forest types or geographic regions may produce questionable results. The specificparameters estimated are: canopy fuel weight, bulk density, base height, and height.
𝑐𝑎𝑛𝑜𝑝𝑦 𝑓𝑢𝑒𝑙 𝑤𝑒𝑖𝑔ℎ𝑡 (𝑘𝑔⁄ℎ𝑎) = (22.7 + 2.9ℎ25 − 1.7ℎ90 + 106.6𝐷)2
𝑐𝑎𝑛𝑜𝑝𝑦 𝑏𝑢𝑙𝑘 𝑑𝑒𝑛𝑠𝑖𝑡𝑦(𝑘𝑔⁄𝑚3 ) = 𝑒 (−4.3+3.2ℎ𝐶𝑉+0.02ℎ10+0.13ℎ25 −0.12ℎ90+2.4𝐷) ∗ 1.037
𝑐𝑎𝑛𝑜𝑝𝑦 𝑏𝑎𝑠𝑒 ℎ𝑒𝑖𝑔ℎ𝑡(𝑚) = 3.2 + 19.3ℎ𝐶𝑉 + 0.7ℎ25 + 2.0ℎ50 − 1.8ℎ75 − 8.8𝐷

88𝑐𝑎𝑛𝑜𝑝𝑦 ℎ𝑒𝑖𝑔ℎ𝑡(𝑚) = 2.8 + 0.25ℎ𝑚𝑎𝑥 + 0.25ℎ25 − 1.0ℎ50 + 1.5ℎ75 + 3.5𝐷
These models assume elevations are in meters and require that the bare-earth surface
model be a good representation of the true ground surface.
Multiple ground surface models can be used in GridMetrics to facilitate processing oflarge acquisitions. When using multiple ground surface models, the default behavior is
to load only those models into memory that overlap the data extent or the extent
specified using /grid, /gridxy, or /align (possibly in combination with the /buffer or/cellbuffer options). If you find that your computer has insufficient memory to process
the desired area, you can try the /diskground option to use logic that does not read theground surface models into memory. Use of the /diskground option will allow processing
for larger areas but also slows the processing by a factor of 4 to 5. To maximize
processing speed, it is best to reduce the extent of the area processed rather than use
the /diskground option.
When using the /RGB option, you can only specific a single color component. Thismeans that to compute metrics using the Red, Green, and Blue components requires
three separate runs of GridMetrics. Output from the color metrics will be stored inseparate files labeled to identify the color component used to compute the metrics.

ExamplesThe following command will compute metrics using elevations values and store them in
CSV format. Cover values are computed using a height break of 3 meters and themetrics are computed for a 15- by 15-meter grid.
GridMetrics 000263_ground_1m.dtm 3 15 000263_metrics.csv 000263.las
The following command will compute metrics using elevations values and store them in
CSV format. Metrics will cover a 1000 by 1000 meter area. The analysis area isbuffered by 100 meters on all sides but the output metrics will only cover the extent
specified in the /gridxy option. The ground model specification is expanded into a list
containing several ground models. However, only the ground surface models thatoverlap the buffered analysis area are loaded and used for processing. Cover values
are computed using a height break of 3 meters and the metrics are computed for a 15by 15-meter grid.
GridMetrics /gridxy:634000,7546000,635000,7547000 /buffer:100 *.dtm 3 15
Tile38_metrics.csv *.las89

GridSample
Overview
GridSample produces a comma separated values (CSV) file that contains values for thegrid cells surrounding a specific XY location. Input is a file containing a list of XY
coordinate pairs, one pair per line of the file. The user specifies the size of the sample
window on the command line. Output is a CSV file containing the original XY locationand the grid values from the sample window.

SyntaxGridSample [switches] gridfile inputfile outputfile windowsize
gridfile
inputfile

outputfile
windowsize

Switches
centerName for ground surface model (PLANS DTM with .dtm extension).
Name of the ASCII text file containing the XY sample locations. This
file can be in CSV format but should not include a header line. The XY
values can be separated by spaces, commas, or tabs.
Name for the output data file. Output is stored in CSV format.
Size of the sample window in grid cells. The windowsize must be an
odd number.

Include the location of the center of the cell containing the sample pointin the outputfile.

Technical Details
GridSample uses a grid interpretation of a PLANS format DTM file. This means thateach data point in the DTM file represents a square area and the data point is located at
the center of the area represented. GridSample computes the grid cell row and column
closest to each input XY location using the following formulas:

𝑟𝑜𝑤 = (𝑖𝑛𝑡) (𝑐𝑜𝑙𝑢𝑚𝑛 = (𝑖𝑛𝑡) (𝐷𝑇𝑀𝑟𝑜𝑤𝑠𝑝𝑎𝑐𝑖𝑛𝑔
2.0)
𝐷𝑇𝑀𝑟𝑜𝑤𝑠𝑝𝑎𝑐𝑖𝑛𝑔(𝑌 − 𝐷𝑇𝑀𝑜𝑟𝑖𝑔𝑖𝑛𝑌) +𝐷𝑇𝑀𝑐𝑜𝑙𝑢𝑚𝑛𝑠𝑝𝑎𝑐𝑖𝑛𝑔
2.0)
𝐷𝑇𝑀𝑐𝑜𝑙𝑢𝑚𝑛𝑠𝑝𝑎𝑐𝑖𝑛𝑔(𝑋 − 𝐷𝑇𝑀𝑜𝑟𝑖𝑔𝑖𝑛𝑋) +Then it extracts grid values for the sample window and writes them to the outputfile. If
the XY location is outside the extent of the grid file, the grid values are set to -1.0 and
output to the outputfile. If some of the grid cells within the sample are outside the grid
file extent, values of -1.0 are included in the outputfile.
Grid values are output by rows starting at the upper left corner of the sample area.
Column labels are provided in the outputfile to indicate the arrangement of sample

90

values. All samples associated with a location are output on a single line within the CSV
file. Users that want to use the CSV files with Excel should be aware that there arelimits on the number of columns that can be read from CSV files. This limit varies
depending on the Excel version.
The output CSV file reports grid values with 6 decimal digits for grid files that containfloating point values and with 0 decimal digits for grid files that contain integer values.

ExamplesThe following example reads locations from the file named plotsSE.txt and outputs gridvalues in a 5 by 5 pixel window from the grid surface canopy_complexity.dtm into the
outputfile named plot_samples.csv.
GridSample canopy_complexity.dtm plotsSE.txt plot_sample.csv 5
The inputfile, plotsSE.txt contains the following records:
524750.0,5200000.0524750.0,5200250.0
524750.0,5200500.0524750.0,5200750.0524750.0,5201000.0
525000.0,5200000.0
525000.0,5200250.0
525000.0,5200500.0
525000.0,5200750.0
525000.0,5201000.0
The outputfile, plot_samples.csv contains the following values (values were truncated to
one decimal place for this example):
X,Y,"R+1 C-1","R+1 C+0","R+1 C+1","R+0 C-1","R+0 C+0","R+0 C+1","R-1 C-1","R-1 C+0","R-1 C+1"
524750.0,5200000.0,156.2,156.6,156.7,156.7,156.9,157.1,156.8,157.0,157.2
524750.0,5200250.0,162.5,162.2,161.7,162.6,162.4,161.8,162.4,162.5,162.0
524750.0,5200500.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0
524750.0,5200750.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0
524750.0,5201000.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0
525000.0,5200000.0,146.9,147.0,146.9,146.8,147.0,147.0,147.1,147.1,146.7
525000.0,5200250.0,143.9,143.6,143.3,144.0,143.8,143.5,144.3,144.0,143.7
525000.0,5200500.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0
525000.0,5200750.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0
525000.0,5201000.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0,-1.0

91GridSurfaceCreate
Overview
GridSurfaceCreate creates a gridded surface model using collections of random points.
The surface model is stored in PLANS DTM format using floating point elevation values.
Individual cell elevations are calculated using the average elevation of all points within
the cell. GridSurfaceCreate is most often used with bare-earth point sets obtained from
LIDAR vendors or by using the GroundFilter program.

SyntaxGridSurfaceCreate [switches] surfacefile cellsize xyunits zunits coordsys zone
horizdatum vertdatum datafile1 datafile2...
surfacefile
cellsize
xyunits

zunitscoordsyszone
horizdatumvertdatum

datafile1

datafile2

Name for output surface file (stored in PLANS DTM format with .dtm
extension).
Grid cell size for the surface.
Units for LIDAR data XY:
M for meters,
F for feet.
Units for LIDAR data elevations:
M for meters,
F for feet.
Coordinate system for the surface:
0 for unknown,
1 for UTM,
2 for state plane.
Coordinate system zone for the surface (0 for unknown).
Horizontal datum for the surface:
0 for unknown,
1 for NAD27,
2 for NAD83.
Vertical datum for the surface:
0 for unknown,
1 for NGVD29,
2 for NAVD88,
3 for GRS80.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT formats)...may be
wildcard or name of text file listing the data files. If wildcard or text fileis used, no other datafile# parameters will be recognized.
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on the length ofeach file name. When using multiple data files, it is best to use awildcard for datafile1 or create a text file containing a list of the data
files and specifying the list file as datafile1.

92

Switches
median:#smooth:#slope:#
spike:#

residuals
filldist:#lasclass:#class:string

ignoreoverlap
minimum
maximum
grid:X,Y,W,H

gridxy:X1,Y1,
X2,Y2

align:dtmfile

extent:dtmfile

Apply median filter to model using # by # neighbor window.
Apply mean filter to model using # by # neighbor window.
Filter areas from the surface with slope greater than # percent.
Filter final surface to remove spikes with slopes greater than #percent. Spike filtering takes place after all other smoothing andfiltering.
Compute residual statistics for all points.
Maximum search radius (in cells) used when filling holes in thesurface. Default is 99 cells.
Use only returns with a classification code of # to create the surface
model (LAS data files only). As of version 1.92, this option has beensuperseded by the /class switch and should no longer be used.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g. (2,3,4,5)
and can range from 0 to 31. If the first character of string is “~”, allclasses except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).
Use the lowest point in each cell as the surface elevation.
Use the highest point in each cell as the surface elevation.
Force the origin of the output grid to be (X,Y) instead of computing an
origin from the data extents and force the grid to be W units wide andH units high...W and H will be rounded up to a multiple of cellsize.
Force the origin of the output grid (lower left corner) to be (X1,Y1)
instead of computing an origin from the data extents and force theupper right corner to be (X2, Y2). X2 and Y2 will be rounded up to a
multiple of cellsize.
Force alignment of the output grid to use the origin (lower left corner),
width and height of the specified dtmfile. Behavior is the same as/gridxy except the X1,Y1,X2,Y2 parameters are read from the dtmfile.
Force the origin and extent of the output grid to match the lower left
corner and extent of the specified PLANS format DTM file but adjust
the origin to be an even multiple of the cell size and the width andheight to be multiples of the cell size.

The order of the /median and /smooth switches is important...the first filter specified on
the command line will be the first filter applied to the model. Slope filtering takes place
after all other smoothing operations.

Technical Details
By default, GridSurfaceCreate computes the elevation of each grid cell using the
average elevation of all points within the cell. This method seems to work well with
LIDAR data that has been filtered to identify bare-earth points. LIDAR return elevations
typically have errors due to ranging and GPS-IMU error. Using the average of all returnelevations in the cell acknowledges this error and results in a surface that lies within the93cloud of bare-earth points. The /minimum switch allows you to create the surface using
the lowest point in each cell as the surface elevation. For some applications, this resultsin surfaces that are better behaved that those using the average of all return elevationsin the cell. However, when using the /minimum switch you should specify a small cellsize to avoid producing a surface that lies below the bare-earth point set. In general,
you need to experiment with settings for GroundFilter and GridSurfaceCreate to find the
combination of options that produce bare-earth surfaces that meet your needs.
In general, smoothing using the /median or /smooth switches is unnecessary provided
that the data points used to create the surface are truly bare-earth points. Smoothing
will result in some loss of surface detail particularly in areas with sharply definedfeatures such as road cut banks, stream banks, and eroded areas. For data point setsthat included some residual returns from vegetation, smoothing (especially using the/median switch) may be necessary to produce a useable ground surface. For data setsacquired over urban areas, it is not uncommon to have returns from building rooftops
included in the bare-earth point set. For such data, smoothing with a window size that islarger than the largest building footprint is required to remove the surface anomalies
associated with the returns from rooftops. Such smoothing generally degrades theterrain features to a point where most surface detail is lost.
Filtering to remove steep spikes, specified using the /spike switch, works well to remove
spikes related to residual returns from vegetation in areas of moderate topography.
Spikes are only removed if they are also a local maximum within a 3 by 3 point window.
In areas with steep topography, spike filtering may result in excessive smoothing ofterrain features; especially those features that define transitions from low slope to highslop areas.
Cells that contain no points are filled by interpolation using neighboring cells. Cells on
the edge of the data coverage with no neighbors with valid elevations in one or more
directions are flagged with NODATA values.

ExamplesThe following command produces a surface model using a 1- by 1-meter grid. No
smoothing is done for the final surface. Data are in the UTM coordinate system, zone
10, with units for both horizontal values and elevations of meters. The data uses the
NAD83 horizontal and NAVD88 vertical datums.
GridSurfaceCreate 000263_gnd_1m.dtm 1 m m 1 10 2 2 000263_gnd_pts.las
The following command produces a surface model using a 1- by 1-meter grid. A mediansmoothing filter using a 3 by 3 cell window is used to smooth the final surface.
GridSurfaceCreate /median:3 000263_gnd_1m.dtm 1 m m 1 10 2 2 000263_gnd_pts.las

94GridSurfaceStats
Overview
GridSurfaceStats computes the surface area and volume under a surface (or between
the surface and a ground surface). When used with a canopy height or surface model, it
provides information useful for describing canopy surface roughness and the volume
occupied by tree canopies.

SyntaxGridSurfaceStats [switches] inputfile outputfile samplefactor
inputfile
outputfile
samplefactor

Switches
ground:file

ascii
area
halfcellsvonlygrid:X,Y,W,H

gridxy:X1,Y1,
X2,Y2

align:dtmfile

extent:dtmfile

Name for the input DTM surface file including the .dtm extension.
Base name for the output DTM files containing the surface statistics
including the .dtm extension.
Multiplier for outputfile cell size. outputfile cells will represent
samplefactor * samplefactor cells from the inputfile.

Use the specified surface model to represent the ground surface file
may be wildcard or text list file (extension .txt only). A valueinterpolated from the file will be subtracted from every grid point in
the inputfile.
Output all files in ASCII raster format with the .asc extension. Filesin DTM format will not be written.
Compute the surface area of inputfile instead of the surface area
divided by the flat cell area.
Force alignment of the output grid to match the grid used by
GridMetrics. This option cannot be used with the /grid, /gridxy,/extent, or /align switches.
Output only the surface volume metric layer.
Force the origin of the output grid to be (X,Y) instead of computing
an origin from the data extents and force the grid to be W units wideand H units high...W and H will be rounded up to a multiple ofcellsize.
Force the origin of the output grid (lower left corner) to be (X1,Y1)
instead of computing an origin from the data extents and force theupper right corner to be (X2, Y2). X2 and Y2 will be rounded up to a
multiple of cellsize.
Force alignment of the output grid to use the origin (lower left
corner), width and height of the specified dtmfile. Behavior is thesame as /gridxy except the X1,Y1,X2,Y2 parameters are read fromthe dtmfile.
Force the origin and extent of the output grid to match the lower left
corner and extent of the specified PLANS format DTM file but
adjust the origin to be an even multiple of the cell size and the widthand height to be multiples of the cell size.

95Technical Details
Surface area and volume are computed by dividing each grid cell in the surface into two
triangles from the lower left to the upper right corner. Then the area of each triangle iscomputed using the 3D coordinates of the triangle vertices. Area is the magnitude of thecross product of the three vertices. Volume under the surface for each triangle iscomputed by multiplying the flat triangle area (1/2 of the grid cell area) by the average
elevation (or height) of the three vertices. Totals for each cell in the outputfile arecomputed by summing the areas and volumes for the samplefactor * samplefactor cells
from the inputfile. Area and volume are only computed when all four corners of a cell in
the inputfile have valid data. If any vertex has an invalid elevation (or height), the areaand volume for the entire cell is 0.0.
The /grid, /gridxy, /align, and /extent switches allow you to force the extent of thesurface metrics to provide better alignment with output from GridMetrics.
GridSurfaceStats computes the following values for each samplefactor * samplefactor
cell area from the input surface:
Value
Maximum height
Potential volume
Surface area ratio
Surface area (with /area
switch)Surface volume
Surface volume ratio

Description
Maximum height value for the samplefactor *samplefactor cell window in the input surface
Volume under the samplefactor * samplefactor cell
window using the maximum height.
𝑆𝑢𝑟𝑓𝑎𝑐𝑒 𝑎𝑟𝑒𝑎 𝑜𝑓 𝑠𝑎𝑚𝑝𝑙𝑒𝑓𝑎𝑐𝑡𝑜𝑟 ∗ 𝑠𝑎𝑚𝑝𝑙𝑒𝑓𝑎𝑐𝑡𝑜𝑟 𝑐𝑒𝑙𝑙
𝐹𝑙𝑎𝑡 𝑎𝑟𝑒𝑎 𝑜𝑓 𝑡ℎ𝑒 𝑠𝑎𝑚𝑝𝑙𝑒𝑓𝑎𝑐𝑡𝑜𝑟 ∗ 𝑠𝑎𝑚𝑝𝑙𝑒𝑓𝑎𝑐𝑡𝑜𝑟 𝑐𝑒𝑙𝑙Surface area of samplefactor * samplefactor cell
Volume under the samplefactor * samplefactor cell
window using the cell heights.
𝑆𝑢𝑟𝑓𝑎𝑐𝑒 𝑣𝑜𝑙𝑢𝑚𝑒
𝑃𝑜𝑡𝑒𝑛𝑡𝑖𝑎𝑙 𝑣𝑜𝑙𝑢𝑚𝑒

ExamplesThe following example computes area and volume for the canopy height model named
ALLAREA_CHM.DTM using a 5 by 5 window and writes the results to files whosenames use the base name: CHM_STATS.DTM:
GridSurfaceStats ALLAREA_CHM.DTM CHM_STATS.DTM 5
Five output files are produced with names formed by adding the following to the baseoutputfile name:_max_height_potential_volume_surface_area_ratio
96

_surface_volume_surface_volume_ratio
In the example above the following files would be created:
CHM_STATS _max_height.dtm
CHM_STATS _potential_volume.dtm
CHM_STATS _surface_area_ratio.dtm
CHM_STATS _surface_volume.dtm
CHM_STATS _surface_volume_ratio.dtm

97GroundFilter
Overview
GroundFilter is designed to filter a cloud of LIDAR returns to identify those returns thatlie on the probable ground surface (bare-earth points). GroundFilter does not produce a
perfect set of bare-earth returns in that it does not completely remove returns fromlarge, relatively flat, elevated surface such as building roofs. Most vegetation returns are
removed with the appropriate coefficients for the weight function and sufficient
iterations. Experimentation with GroundFilter has shown that the default coefficients forthe weight function produce good results in high-density point clouds (> 4 returns/sq m).
The program can be used with low-density point clouds but some experimentation may
be needed to select appropriate coefficients. In general, GroundFilter produces pointsets that result in surface models that are adequate for calculating vegetation heights.
The point set and resulting models may not be adequate when the bare-earth surface isthe primary product.
The output from GroundFilter is a file containing only the points classified as groundreturns stored in LDA or LAS format. The output file can be used with the
GridSurfaceCreate or TINSurfaceCreate utilities to produce a ground surface model.

SyntaxGroundFilter [switches] outputfile cellsize datafile1 datafile2 ...
outputfile
cellsizedatafile1

datafile2

The name of the output LIDAR data file containing points
classified as bare-earth returns.
The cell size used for intermediate surface models. This is used
for intermediate surfaces and is not the cell size for the final
ground surface model created using GridSurfaceCreate or
TINSurfaceCreate.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT
formats)...may be wildcard or name of text file listing the data
files. If wildcard or text file is used, no other datafile#parameters will be recognized.
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on thelength of each file name. When using multiple data files, it isbest to use a wildcard for datafile1 or create a text filecontaining a list of the data files and specifying the list file asdatafile1.

Switcheslda

Write output files using FUSION's LDA format when using LAS
input files. The default behavior after FUSION version 3.00 is towrite data in LAS format when the input data are in LAS format.

98

surface
median:#smooth:#finalsmooth

outlier:low,highgparam:#wparam:#aparam:#bparam:#tolerance:#

iterations:#
class:string

ignoreoverlap
reclass:[#}extent:X1,Y1,X2,Y2

trim:X1,Y1,X2,Y2

When using input data in a format other than LAS, sample files
are written in LDA format.
Create a surface model using the final ground points.
Use a median filter for the intermediate surface model with # by
# window.
Use a focal mean filter for the intermediate surface model with# by # window.
Apply smoothing after the final iteration before selecting bareearth points. Only used when /smooth or /median switch isused.
Omit points with height above ground below low and above
high.
Value for the g parameter of the weight equation (see equation
below). The default value is -2.0.
Value for the w parameter of the weight equation (see equation
below). The default value is 2.5.
Value for the a parameter of the weight equation (see equation
below). The default value is 1.0.
Value for the b parameter of the weight equation (see equation
below). The default value is 4.0.
Tolerance value for the final filtering of the ground points. Only
points within # units of the final intermediate surface model will
be included in the output file. If no tolerance is specified, theweight value is used to filter points.
Number of iterations for the filtering logic (default is 5).
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character ofstring is “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format)
Reclassify the identified ground points using class #. Default
value is 2. When the /reclass option is used, all points in the
input file(s) are written to the output file. For ground points, theclassification value is changed to #. For all other points, theclassification value remains the same unless the value is thesame as the reclass # and the point is not identified as aground point. For these points, the class for the point is set to 1.
You cannot use the /reclass option with the /lda option.
Only consider points within the extent defined by (X1,Y1) and(X2, Y2) for filtering. /extent determines which points are
considered for filtering.
Only output points within the extent defined by (X1,Y1) and (X2,
Y2). /trim is used along with /extent to allow filtering using
points within a larger extent but only output points within thesmaller extent. This minimizes edge artifacts in the final point99

diagnostics

precision:scaleX,
scaleY,scaleZ

set and surface created using the points. /trim determines
which filtered points are output.
Display diagnostic information during the run and produce
diagnostic files that include the LIDAR returns over holes in theintermediate surface model, below surface points, and above
surface points.
Control the scale factor used for X, Y, and Z values in output
LAS files. These values will override the values in the source
LAS files. There is rarely any need for the scale parameters tobe smaller than 0.001.

The order of the /median and /smooth switches is important...the first filter specified on
the command line will be the first filter applied to the model. Slope filtering takes place
after all other smoothing operations.
The /extent and /trim options allow you to filter data for specific areas with a project or tooverlay a processing grid over large datasets. When filtering large datasets, you canmanually generate a processing tile arrangement and then specify the cornercoordinates of each tile using the /trim option. Add a buffer to the corner coordinates
and use the buffered coordinates with the /extent option. This should provide a set offiltered ground points that will produce surface models with minimal edge artifacts. If you
are processing data using scripts generated by LTKProcessor or AreaProcessor, use
the buffered tile coordinates with the /extent option and the unbuffered coordinates withthe /trim option in the batch file used to process each tile.

Technical Details
The filtering algorithm (adapted from Kraus and Pfeifer, 1998) is based on linear
prediction (Kraus and Mikhail, 1972) with an individual accuracy for each measurement.
It is implemented as an iterative process. In the first step, a surface is computed withequal weights for all LIDAR points. This results in a surface that lies between the true
ground and the canopy surface. Terrain points are more likely to be below the surface
and vegetation points above the surface. The distance and direction to the surface isused to compute weights for each LIDAR point using the following weight function:

The parameters a and b determine the steepness of the weight function. For mostapplications values of 1.0 and 4.0 for a and b respectively have produced adequate
results. The shift value, g, determines which points are assigned a weight of 1.0 (themaximum weight value). Points below the surface by more than g, are assigned aweight of 1.0. The above ground offset parameter, w, is used to establish an upper limit
for points to have an influence on the intermediate surface. Points above the level100defined by (g + w) are assigned a weight of 0.0. In the current implementation, values
for g and w are fixed throughout the filtering run. Kraus and Pfeifer, 1998 used anadaptive process to modify the g parameter for each iteration. After the final iteration,
bare-earth points are selected using the final intermediate surface. All points withelevations that satisfy the first two conditions of the weight function are considered bareearth points. If the /tolerance:# switch is used, all points within the specified tolerance ofthe final surface are considered bare-earth points.
The /finalsmooth switch will result in slightly more aggressive smoothing of theintermediate surface model just before the final point selection process. In general, theadditional smoothing results in a bare-earth point set that does not include points along
sharply defined features such as road cut banks, stream banks, and eroded areas.
Users should experiment with this switch to see if it meets their needs.
When the /surface switch is used, a surface model is created using the final bare-earth
points. The cell elevation is the average elevation of all points in a cell. The model cellsize is the same as the intermediate surface cell size (specified by cellsize andsmoothing is done depending on the /smooth and /median switches. In general, thesurface model produced by GroundFilter is too coarse to be useful. It provides a quick
check on the results of the bare-earth filtering as the resulting PLANS DTM file can bedisplayed for evaluation in the PDQ viewer.
Diagnostics, enabled using the /diagnostics switch, can help diagnose situations where
GroundFilter does not seem to be producing good bare-earth point sets. Diagnostics
include descriptive summaries for each iteration and the intermediate surface models
produced for each iteration. In addition, the PDQ viewer will be launched to show eachintermediate surface as it is created.

ExamplesThe following command filters a data file and produces a new data file that contains only
bare-earth points:
GroundFilter 000263_ground_pts.las 5 000263.las
The following command uses 8 iterations, a g value of 0.0, and a w value of 0.5 to filtera data file and produces a new data file that contains only bare-earth points:
GroundFilter /gparam:0 /wparam:0.5 /iterations:8 000263_ground_pts.las 5 000263.las101ImageCreate
Overview
ImageCreate creates an image from LIDAR data using the intensity value or elevation of
the highest return within an image pixel. Optionally uses the height above a surface
model to create the image. The output image is geo-referenced using a world file. The
extent of the image is computed so that the image origin is a multiple of the pixel size.
The default image file format is JPEG.

SyntaxImageCreate [switches] ImageFileName PixelSize DataFile1 DataFile2 ... DataFileN
ImageFileName
PixelSize
DataFile1…DataFileN

Switchesbmp
jpeg
coloroption:n

dtm:filename
minimum:value

maximum:value

startcolor:value

stopcolor:value

Name for the output image file. The file will be stored in thespecified format regardless of the extension.
Size (in the same units as the LIDAR data) of each pixel inthe output image.
LIDAR data files stored in binary LDA or LAS formats or
ASCII LIDARDAT format (LIDARDAT format may not be
supported in future versions).

Store the output image file in Windows BMP format and set
output image file extension to “.bmp”.
Store the output image file in JPEG format and set output
image file extension to “.jpg”.
Method used to assign color to each image pixel. Validvalues for n and their interpretation are:0
Assign color using intensity
1
Assign color using elevation
2
Assign color using height above surface.
Name of the surface file used to compute heights. Only
PLANS format surface models are recognized.
Minimum value used to constrain the color assigned to a
pixel. Returns with values less than value will be coloredusing the starting color.
Maximum value used to constrain the color assigned to a
pixel. Returns with values greater than value will be coloredusing the ending color.
Starting color in the color ramp used to assign pixel colors.
Value can be a single number representing a combined
RGB color or a series of three values separated by commas
representing the R, G, and B color components.
Ending color in the color ramp used to assign pixel colors.
Value can be a single number representing a combined
RGB color or a series of three values separated by commas
representing the R, G, and B color components.

102

hsv
rgb
backgroundcolor:value

Use the HSV color model to create the color ramp.
Use the RGB color model to create the color ramp.
Background color for areas of the image not covered by
LIDAR data. Value can be a single number representing a
combined RGB color or a series of three values separated
by commas representing the R, G, and B color components.

Technical Details
When creating an image using intensity values for individual LIDAR returns,
ImageCreate automatically scales the range of values from 0.0 to the intensity value
corresponding to the 95th percentile of intensity values in the data. You can override
this behavior by specifying a minimum and maximum range value.
Image extents are computed after scanning the LIDAR data for minimum and maximum
XY values. The min/max values are adjusted so the area covered by the image always
begins on an even multiple of the cell size. To make the adjustments, the area coveredby the image is expanded and shifted to the correct origin.
ImageCreate creates images using the JPEG format by default. The /bmp switch allows
creation of images in windows BMP format. The extension of the ImageFileName will bechanged depending on the image format. This means that the image created by
ImageCreate may have a name different from that specified by ImageFileName if you
specify the wrong extension for the image file format being produced.

ExamplesThe following example creates an image using the intensity values stored in tile001.las.
The range of intensity values is truncated using a minimum value of 10 and a maximum
value of 90 and the image uses pixels that are 2- by 2-meters.
ImageCreate /rgb /min:10 /max:90 /back:0,0,0 tile001_intensity.bmp 2 tile001.las

103

IntensityImage
Overview
Airborne laser scanning (commonly referred to as LIDAR) data have proven to be agood source of information for describing the ground surface and characterizing the sizeand extent of man-made features such as road systems and buildings. The technology
has gained a strong foothold in mapping operations traditionally dominated byphotogrammetric techniques. In the forestry context, airborne laser scanning data havebeen used to produce detailed bare-earth surface models and to characterize
vegetation structure and spatial extent. Hyyppä et al. (2004) provide an overview of
LIDAR applications for forest measurements. One often overlooked component of
LIDAR data, return intensity, is seldom used in analysis procedures. LIDAR return
intensity is related to the ratio of the amount of the laser energy detected by the receiver
for a given reflection point to the amount of total energy emitted for the laser pulse(Baltsavias, 1999; Wehr and Lohr, 1999). Because this ratio is quite small (Baltsavias,
1999), intensity values reported in LIDAR data are scaled to a more useful range (8-bit
values are common). Intensity values are collected by most sensors in use today andproviders include the intensity values in point cloud data files stored in the standard LAS
format (ASPRS, 2005). Flood (2001) points out that while intensity data have been
available for some time, their use in commercial data processing workflows is limited.
Song et al. (2002) evaluated the potential for identifying a variety of surface materials(asphalt, grass, house roof, and trees) using LIDAR intensity in an urban environment.
Charaniya et al. (2004) used LIDAR point data, LIDAR intensity, USGS 10m-resolution
digital elevation model, and black-and-white ortho-photographs to classify LIDAR points
into the same categories. Hasegawa (2006) conducted experiments to investigate theeffects of target material, scan geometry and distance-to-target on intensity values
using a typical airborne scanner attached to a fixed mount on the ground. He also
evaluated the use of airborne LIDAR data to identify a variety of materials. He
concluded that some materials were easily separated (soil, gravel, old asphalt, andgrass) while others were not easy to separate (cement, slate, zinc, brick, and trees).
Brennan and Webster (2006) utilized a rule-based object-oriented approach to classify avariety of land cover types using LIDAR height and intensity data. They found that bothheight and intensity information were needed to separate and classify ten land covertypes. Brandtberg (2007) also found that use of intensity data significantly improved
LIDAR detection and classification of leaf-off eastern deciduous forests.

SyntaxIntensityImage [switches] CellSize ImageFile DataFile1 DataFile2
CellSize
ImageFiledatafile1

The pixel size used for the intensity image (same units as LIDARdata).
Name for the image file.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT formats)...may be
wildcard or name of text file listing the data files. If wildcard or text
file is used, no other datafile# parameters will be recognized.

104

datafile2

Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on the lengthof each file name. When using multiple data files, it is best to use awildcard for datafile1 or create a text file containing a list of the data
files and specifying the list file as datafile1.

Switchesminint:#maxint:#intrange:min,max

intcell:#void:R,G,B
allreturns
lowestlowallsaveint
rasterorigin
diskonly
hist

jpg
projection:filen
ameclass:string

ignoreoverlap

Minimum intensity percentile used for the image. Default is 2
percent.
Maximum intensity percentile used for the image. Default is 98
percent.
Force the scaling of intensity values using the specified min and max
values. Setting the min value to -1 should force the output range tostart with 1 instead of 0. Doing this in combination with /void:0,0,0
will allow you to identify areas with no data in the output image as
they will have a value of 0 for all color bands.
Cell size multiplier for intermediate images. Default is 1.5.
Color for areas with no data values. Default is red (255, 0, 0).
Use all returns to create the intensity image instead of only first
returns.
Use the lowest return in the pixel area to assign the intensity value.
The /lowest switch should be used with the /allreturns switch for best
effect.
Combines the /lowest and /allreturns switches. /lowall will have noeffect when used with either the /lowest or /allreturns switches.
Save the intermediate image files. Usually used to diagnose
problems.
Force alignment to match other raster products generated from point
data (offsets the origin of the image by 1/2 pixel).
Do not attempt to read all returns into memory for processing.
Produce the intensity histogram data files. Histogram data files areproduced in CSV format for both the raw frequency histogram andthe normalized cumulative frequency histogram.
Save the intensity image using the JPEG format. The default format
is BMP.
Associate the specified projection file with image products.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g. (2,3,4,5)
and can range from 0 to 31. If the first character of string is “~”, allclasses except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).

105

Technical Details (McGaughey et al., 2007):
Algorithms for converting point data, i.e. LIDAR returns, into raster representations, i.e.,
images, are well defined and easily programmed. However, the non-uniform density of
LIDAR returns and the desire to produce high-resolution images makes it necessary to
implement more complex rasterization algorithms.
The overall goal in IntensityImage is to create a useful, high-resolution image thatminimizes the visible effects of sampling artifacts and voids in the final images. In mostcases, it is desirable to create images using a pixel size that is a function of the pulse
footprint at ground level and the pulse spacing. For example, if LIDAR data are acquired
at a density of 4 pulses/m2 using a pulse size of 0.6 m (measured at ground level), one
would like to create images that use pixels that are about 0.25 m 2. In theory, this ispossible. In practice, however, a large proportion of pixels will have no LIDAR returns
and will need to be filled because of non-uniformity of horizontal spacing of points within
the LIDAR data cloud. Figure 5 shows an image produced using LIDAR data acquired
at a density of 5.5 pulses/m2 (0.43 m between pulses) using a pulse size of 0.33 m(average diameter at ground level). Image pixels are 0.45 by 0.45 m. Red pixels in theimage indicate areas where there were no first returns within the pixel. Most such“voids” could be filled after rasterization is complete using interpolation techniques.
However, interpolation may not provide information for the pixel that represents a “realmaterial” since reflectance values of two different materials cannot be meaningfully
averaged. For example, a pixel filled with the average of a high and low reflectancevalue indicates medium reflectivity. Filling the “void” with such a value could be
misleading since the material associated with the pixel is not the “average” of thesurrounding materials.

Figure 5. Image produced using LIDAR intensity data for first returns. Red pixels in the image
indicate areas where there were no first returns within the pixel. LIDAR data were acquired at adensity of 5.5 pulses/m2 (0.43 m between pulses) using a pulse size of 0.33 m (average diameter at
ground level). Image pixels are 0.45 by 0.45 m. Image represents an area that is 434 m wide and411 m high.

106

To help fill void areas and produce high resolution images, we have implemented analgorithm similar to full-scene anti-aliasing algorithms common in computer graphics(Woo et al., 1997). The basic approach is to render the point data (convert from points
to a raster image) several times using a slightly offset, or “jittered”, raster origin. Our
implementation uses eight iterations using origin offsets shown in Table 2 and Figure 6.
The offsets are multiplied by the raster cell size. In Figure 6, the black diamond in thecenter of the gray “cell” is the origin for the final image. The final image is produced bysampling the eight images at a location that corresponds to the center of the final image
pixels. The grayscale intensity for the final image is computed as the average of thevalid values (non-void) from the eight images. To help eliminate void pixels, we create
the images for the iterations using a slightly larger pixel size, 1.5 times the final pixel
size, and then create the final image using the user-specified pixel size. Final images
include geo-referencing information stored in a world file. Figure 7 shows the final
composite image produced from the same data used for the intermediate image shownin Figure 5. Notice that most of the void areas have been eliminated. The remaining
large, red areas are open water (swimming pools, river) and a glass-covered atrium inthe building in the lower-left corner of the image. For most applications, the remaining
void pixels do not detract from the overall appearance and utility of the image.
Table 2. Grid origin offsets used to “jitter” the image origin. Offsets are multiplied by the image
pixel width (X offset) and height (Y offset) to compute an image origin for each iteration.

Iteration
1
2
3
4
5
6
7
8

X offset
0.0625-0.4375-0.1875
0.18750.31250.4375-0.0626-0.3125

Y offset-0.06250.43750.18750.3125-0.3125
0.0625-0.4375-0.1875

Figure 6. Pattern used to offset image grid origins to implement spatial anti-aliasing. Each of the
red dots represents a grid origin used in one of eight point-to-raster conversions. The black
diamond represents the origin of the final image.

107

Figure 7. Final image produced using LIDAR intensity data for first returns. Red pixels in theimage indicate areas where there were no first returns within the pixel. This image is the result ofeight iterations using the grid origin offsets shown in figure 6. Image pixels are 0.30 by 0.30 m.
Image represents an area that is 434 m wide and 411 m high.

ExamplesThe following example creates an intensity image with 2.5- by 2.5-meter pixels using asingle data file:
IntensityImage 2.5 000035_intensity_2p5m.bmp 000035.las
The following command creates an intensity image with 2.5- by 2.5-meter pixels using
the lowest returns from a single data file:
IntensityImage /lowall 2.5 000035_intensity_low_2p5m.bmp 000035.las108

JoinDB
Overview
JoinDB merges merge two CSV files into a single file using a key field. This is a JOIN
operation in database programs.

Syntax
JoinDB [switches] BaseFile BaseField AddFile AddField StartField OutputFile
BaseFile
BaseField
AddFileAddFieldStartField
OutputFile

SwitchesnoheaderPrimary data file in CSV format.
Field in the primary data file that will be matched to records in thesecondary data file.
Secondary data file in CSV format.
Field in the secondary data file that will be matched to records in the
primary data file.
Starting field in the secondary data file. All fields (columns) starting with
the StartField will be added to records in the OutputFile.
Name for the new data file. The extension should be .csv. OutputFile
can be the same as BaseFile. OutputFile cannot be the same as
AddFile.

Treat the first line of the BaseFile and AddFile as data. Default behavior
assumes the first line of each file contains column names. Valid for CSV
format files only.

Technical Details
JoinDB performs a join operation using two data files. This is typically done in databasesystems but the capability was needed to implement object metrics for the output of
TreeSeg. Initially, I wanted this to work with CSV and DBF formats but there are some
limitations in DBF that may cause problems. Namely there is a limit of 255 fields. While
this seems like it would work for most cases, the output from CloudMetrics with the/strata option with 9 height breaks produces 213 columns. Additional height breaks add
11 columns per strata so the limit of 255 columns would be reached with 12 height
breaks.

ExamplesThe following command joins two CSV files, HighPoints.csv and SegmentMetrics.csv
matching the value in column 3 in HighPoints.csv to those in column 1 ofSegmentMetrics.csv. Columns starting with column 7 and beyond from
SegmentMetrics.csv will be added to the outputfile (TreeMetrics.csv):
JoinDB HighPoints.csv 3 SegmentMetrics.csv 1 7 TreeMetrics.csv

109

LDA2ASCII
Overview
LDA2ASCII converts LIDAR data files into ASCII text files. It provides simple conversion
capabilities for all LIDAR formats supported by FUSION. It was originally developed asa way to check the values being stored in LDA format files but still has utility as aconversion tool. It provides capabilities similar to the Tools…Data conversion…Export
data from LAS or LDA formats to other formats… menu option.

SyntaxLDA2ASCII inputFile outputFile format [identifier] [noheader]
inputFile
outputFile
formatidentifier
noheaderName of the input data file. Format must be LDA, LAS, or ASCII XYZ.
Name for the output ASCII text file.
Format identifier:0 X Y Elevation
1 Pulse Return X Y Elevation Nadir Intensity
2 FUSION-LTK CSV (X,Y,Elevation,Intensity,Pulse number,Returnnumber,Returns per pulse,Nadir angle)
Identifier for format 3 output, cannot include spaces (optional)
If zero, suppress the heading in the output file. Can only be used when[identifier] is used

Technical Details
LDA2ASCII does not recognize the standard FUSION-LTK command line switches andit does not write entries to the FUSION-LTK master log file.

ExamplesThe following command converts an LDA file into ASCII text with X, Y, and Elevation
values only:
LDA2ASCII 000263.lda 000263.txt 0
The following command converts an LAS file to the FUSION-LTK comma separated
value (CSV) format:
LDA2ASCII 000263.las 000263.csv 2110

LDA2LAS
Overview
LDA2LAS was originally developed to convert LIDAR data stored in FUSION’s LDA
format to LAS format. When used with LDA format input, LDA2LAS writes LAS files that,while they can be read by most other programs that read LAS format, are not complete.
Some of the fields for each return are not populated because the required information is
not available in the LDA file. Specifically, the field that details the number of returns for apulse is always set to 0. This information would allow you to easily determine that a
particular return is, for example, return 2 of 3 for the pulse. In addition, LDA2LAS willproduce LAS files for LIDAR data that are missing items such as the GPS time, scanangle, and intensity.
If you are producing LAS data to be used by other people, you should not use the LAS
files produced by LDA2LAS with LDA format files as input as this would lead people
to think that all required fields in the LAS format specification are included.
Command line programs were changed in FUSION release version 3.00 to output LAS
format files when using LAS format input files. The LAS files produced by all commandline programs (except LDA2LAS when using LDA format files for input) are complete
and contain the projection information and other variable length records present in thesource LAS format files. Output files will be written using the same LAS version as thefirst input LAS file and the variable length records from the first input LAS file will becopied to the output LAS file.
When support for compressed LAS files was added to FUSION (Version 3.40),
LDA2LAS provides the capability to act as a compression/decompression tool toconvert between LAS and LAZ formats. When used for this purpose, the output LAS
files are fully compliant with the LAS specification and should be readable by all
programs that read LAS and LAZ format files.

SyntaxLDA2LAS [switches] InputFile OutputFile
InputFile
OutputFile
Switches
cleanlasbylinesName of the input file. File must be in LDA, LAS or LAZ format.
Name for the output LAS format data file.

Only output points that adhere to the LAS format specification(valid GPS time, return # from 1 to 5, within header extent, points
not flagged as withheld. Valid for LAS format input.
Output a separate file for data from each flightline contained in the
input file. The line number will be appended to the outputfile name.
Files can contain data from a maximum of 256 flight lines. This
option is only valid when the input files are in LAS or LAZ format.

111

bytime:duration
bycount:#points
class:string

ignoreoverlap

Use the GPS time to divide the input file in to several new files witheach containing data covering the specified duration.
Divide the file into several new files with each containing #points(or less in the case of the last file).
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character of stringis “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).

Technical Details
ExamplesThe following example converts LIDAR data stored in LDA format into the LAS format:
LDA2LAS 000035.lda 000035.las
The following example compresses data stored in an LAS file into a file stored in the
LAZ format develop by Martin Isenburg:
LDA2LAS 42122-SW-AC.LAS 42122-SW-AC.LAZ
The following example decompresses data stored in the LAZ format into a standard
LAS format file:
LDA2LAS 42122-SW-AC.LAZ 42122-SW-AC.LAS

112

MergeData
Overview
MergeData combines several point cloud files into a single output file. The merge isaccomplished by sequentially reading each input file and writing the point data to the
output file.

SyntaxMergeData [switches] DataFile OutputFile
DataFile
OutputFile
Switchesldaclass:string

ignoreoverlap
index
precision:scaleX,
scaleY,scaleZ

LIDAR data file template or name of a text file containing a list of
file names (list file must have .txt extension).
Name for the output data file with extension.

Write output files using FUSION's LDA format when using LAS
input files. The default behavior after FUSION version 3.00 is towrite data in LAS format when the input data are in LAS format.
When using input data in a format other than LAS, sample files
are written in LDA format.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character ofstring is “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).
Create FUSION index files for the output file.
Control the scale factor used for X, Y, and Z values in output
LAS files. These values will override the values in the source
LAS files. There is rarely any need for the scale parameters tobe smaller than 0.001.

Technical Details
For small projects, data sampling in FUSION seems to be more efficient if all data for a
project are contained in one file. Testing on various computers shows that, for someconfigurations, samples are created faster when all point data are contained in one file.
However, merging data files is not recommended unless you are experiencing slow
performance when using FUSION.
Because MergeData simply reads point data from the input files and writes the data to
the output file, it cannot reassemble pulse data when the returns for the pulse wereseparated into different data files. This happens when point cloud data are divided into
“tiles” for processing and delivery to the client.

113

Examples
The following command merges all LDA format data files in the current directory into asingle file named alldata.lda and creates FUSION index files for the output file:
MergeData /index *.las alldata.las

114

MergeDTM
Overview
MergeDTM combines several PLANS format DTM files into a single output file.
MergeDTM can merge hundreds of DTM files and is not limited by the amount ofmemory available on the computer, only the amount of disk space on the output device.
MergeDTM provides the same capability as the Tools…Terrain model…Combine…
menu option in FUSION except MergeDTM does not automatically fill voids areas in the
final output model (FUSION provides an option to do this).

SyntaxMergeDTM [switches] OutputFile InputFile
OutputFile
InputFile

Switches
cellsize:size
overlap:operator

disk

precision:#

Name for the output DTM file. If no extension is specified .DTM
will be used.
DTM file template, name of a text file containing a list of DTM
file names (list file must have .txt extension), or a list of DTM filenames.

Resample the input DTM data to produce an output DTM withsize by size grid cells.
Specify how overlap areas (two or more input DTM files cover
the same grid points) should be treated. Supported operatorsare:• average: average the value from the input file being
processed with the value already present in the output file• min: use the minimum of the data from the input file being
processed and the value already present in the output file• max: use the maximum of the data from the input file
being processed and the value already present in the
output file
• add: add the data from the input file being processed to avalues already present in the output file
• new: use the data from the input file being processed topopulate the grid point
Merge the .DTM files to a disk file. The default behavior is to try
to hold the merged model in memory but there can be problems
when there is not quite enough memory for the model. Only use
this option when attempts to merge models using the default
method (without the /disk switch) fail.
Override the default precision for the merged output file. The
default behavior is to use the highest precision of the input
models to establish the precision of the output model. Validvalues for precision are:0 2-byte integer
115

exactextent

halfcell
nofill

1 4-byte integer
2 4-byte floating point (C type: float)
3 8-byte floating point (C type: double)
Preserve the exact extent of the input models in the output
model. The default behavior is to expand the extent to thenearest multiple of the output cell size.
Offset the origin and expand the width and height by 1/2 of theoutput cell size.
Do not fill holes in the merged DTM. This option should be used
when merging DTM files that contain raster data (as opposed tosurface data). The hole filling logic can end up adding data to
areas not covered by the original input DTM files.

Technical Details
MergeDTM was designed to merge very large surface models consisting of several
tiles. In operation, MergeDTM first scans the list of input models and determines theoverall extent of the coverage area. The coverage area is expanded so the origin of theoutput model is a multiple of the output cell size. Then it verifies that there is sufficientspace on the output storage device and creates an “empty” surface model file. The
empty model is populated with NODATA values. Finally MergeDTM begins scanning thelist of input models and uses them to populate portions of the output model. The value
for the output model is interpolated from the input models so you can merge models
with different cell sizes. In addition, the grids in the input models do not need to align.
The default behavior of MergeDTM is to populate a grid point in the output model using
the first input file that covers the point. Once a valid value has been stored for a grid
point in the output model, it will not be overwritten even if subsequent input models
cover the point. Use of the overlap area operator “new” changes this behavior. Whenthe “new” operator is specified, points in the output model are populated using the last
input model that covers the point. This operation allows you to “patch” a terrain modelwith new data by specifying the “patch” last in the list of input files.
MergeDTM will try to create the output model in memory. If there is insufficient memory,
it will create the model directly on the output device. Performance will be slower when
the output model cannot be held in memory. MergeDTM will try to load each input
model into memory as it is used to populate the output model. If the input model will not
fit in available memory, it will be accessed from the disk as needed. Performance will be
slower if the input models cannot be loaded into memory as they are needed. The worst
case scenario for MergeDTM is when the output model is too large for memory and allof the input files are also too large for memory, i.e., combining several very large
models. Performance in such situations may be very slow. Use of the /verbose option is
encouraged to provide status messages describing the progress of the merge
operation.
MergeDTM looks at the cell size, coordinate system, measurement units and datums forthe first input model and then compares all other input models to the first. MergeDTM
cannot combine models that use different coordinate systems, measurement units, or116datums. MergeDTM uses the cell size of the first input model as the cell size for the
output model. However, MergeDTM can merge models with different cell sizes. In suchcases, the cell size of the first model is used for the output model and new values areinterpolated from the input models. Use of the /cellsize:size switch forces MergeDTM to
use the specified cell size for the output model regardless of the cell sizes in the input
models.

ExamplesThe following example merges all of the DTM files in the current directory into a single
model named combined.dtm:
MergeDTM combined.dtm *.dtm
The following example uses the data contained in the model file improved.dtm to “patch”
the values in the model named original.dtm. The resulting “patched” model is stored in afile named patched.dtm:
MergeDTM patched.dtm original.dtm improved.dtm

117

MergeRaster
Overview
MergeRaster combines several ASCII Raster format files into a single output file.
MergeRaster can merge hundreds of ASCII Raster files but is limited by the amount ofmemory available on the computer.

SyntaxMergeRaster [switches] OutputFile InputFile
OutputFile
InputFile

Switches
overlap:operator

compareprecision:#
nodata:#Name for the output ASCII Raster file. If no extension is
specified .ASC will be used.
ASCII Raster file template, name of a text file containing a list of
ASCII Raster file names (list file must have .txt extension), or alist of ASCII Raster file names.

Specify how overlap areas (two or more input ASCII Raster files
contain values for the same cell) should be treated. Supported
operators are:• average: average the value from the input file being
processed with the value already present in the output file• min: use the minimum of the data from the input file being
processed and the value already present in the output file• max: use the maximum of the data from the input file
being processed and the value already present in the
output file
• add: add the data from the input file being processed to avalues already present in the output file
• new: use the data from the input file being processed topopulate the grid point
Reports if values in cells common to two or more input files aredifferent by more than 0.001.
Output value with # digits to the right of the decimal point.
Default precision is 4 digits.
Use value (#) to indicate no data in the output file. Default
NODATA value is -9999.

Technical Details
MergeRaster was designed to merge several ASCII Raster files into a single file. This
capability is very useful when merging the output from tools like GridMetrics as negativevalues are preserved when using ASCII Raster files (negative values are lost whenusing PLANS .DTM files). In operation, it first scans the list of input models anddetermines the overall extent of the coverage area. Then it verifies that all input rasters
use the same grid cell size and are aligned to the same grid. Finally, it checks to see118

that there is sufficient space on the output storage device and creates an “empty”
surface model file. The empty model is populated with NODATA values. Finally
MergeRaster begins scanning the list of input rasters and uses them to populate
portions of the output model. The default behavior of MergeRaster is to populate a cellin the output model using the first input file that covers the point. Once a valid value has
been stored for a grid cell in the output model, it will not be overwritten even if
subsequent input models cover the cell. Use of the overlap area operator “new”
changes this behavior. When the “new” operator is specified, cells in the output model
are populated using the last input model that covers the cell. This operation allows you
to “patch” a raster with new data by specifying the “patch” last in the list of input files.
MergeRaster looks at the cell size, and grid alignment for the first input raster and thencompares all other rasters to the first. MergeRaster cannot combine models that use
different grid cell sizes or that are not aligned to a common grid.

ExamplesThe following example merges all of the ASCII raster files with an extension of .ASC in
the current directory into a single model named combined.asc:
MergeRaster combined.asc *.asc
The following example uses the data contained in the raster file improved.asc to “patch”
the values in the raster named original.asc. The resulting “patched” model is stored in afile named patched.asc:
MergeRaster patched.asc original.asc improved.asc

119

PDQ
Overview
PDQ is a simple, fast data viewer for .LDA, .LAS, .DTM, and ASCII raster files. PDQ
supports drag-and-drop so you can drag data files onto an icon (shortcut) for PDQ or
you can drop data files onto a running instance of PDQ. For point cloud data, PDQ
automatically applies a color ramp to the data using the point elevations. The color ramp
runs from brown (lowest) to green (highest).

SyntaxPDQ datafle
Datafile

SwitchesmsName of the input data file. File must be in LDA, LAS, or PLANS
DTM format.

Allows multiple instances of PDQ. To use this option, you must
run PDQ from a DOS command line.
Synchronize multiple instances of PDQ so data manipulation in
one instance will be mirrored in all other instances. To use thisoption, you must run PDQ from a DOS command line.

Technical Details
PDQ is written using a programming model like that used for computer games. It
constantly redraws even if the user has not adjusted the view or changed display
settings. PDQ supports stereoscopic viewing using anaglyph, split-screen (parallel orcross-eyed viewing), or specialized stereo viewing hardware using OpenGL.
While the user is manipulating the view, PDQ attempts to maintain a refresh rate of 30
frames/second. To do this, point data is divided into 32 layers and PDQ only draws as
many layers as it can while maintaining the desired frame rate. For surface models,
PDQ creates a low-resolution version of the surface model and draws this version when
the user is manipulating the view. For both data types, the full-resolution data arerendered whenever the user stops manipulating the view.
To use stereo viewing hardware, the hardware must be capable of supporting OpenGL
quad-buffered stereo. When PDQ starts, it will look for stereo hardware and use it ifavailable. If you prefer that PDQ run in monoscopic mode, you will need to disable thestereo hardware using the display driver configuration utility provided by the hardware(graphics card) manufacturer.
PDQ is very useful for checking both point cloud data and surface model data. For
maximum convenience, the .LDA, .LAS, .DTM, and .ASC file extensions can beassociated with PDQ. Then users simply need to double-click a data file to have it
displayed in PDQ.

120

PDQ offers a scanning mode that can be used to examine large ground or canopy
surface models. This mode is initiated by pressing F5 when a .DTM file is loaded into
the viewer. The (+) and (-) keys move the surface model left and right and the Z andshift-Z keys move the model up and down. The zoom feature (mouse wheel) can beused to zoom into or away from the surface model.
PDQ can also provide specialize coloring for LAS point files. Colors are assigned toindividual points based on the classification field in the LAS data records. For the list ofcolors assigned to codes, see the Help…about dialog in PDQ.
PDQ can display different data sets in different windows and synchronize movement of
the windows. To launch a “clone” window while PDQ is running, use the Clone PDQ
menu option. You can then drag a data file into the new window for viewing. To run
multiple copies of PDQ from a command prompt, use the /m switch. To synchronize
movement in multiple copies, use the /s switch along with the /m switch.
The following keystroke commands are available in PDQ:
Keystroke/mouseactionUp arrow

Context

Description

Viewing

Down arrow

Viewing

Right arrow

Viewing

Left arrow

Viewing

Page upViewing

Page down
Home
Mouse wheel
EscapeA
B
C

Viewing
Viewing
Viewing
Viewing
Viewing
Viewing
ViewingE

Viewing

Shift-E

Stereo-viewing

Shift-Ctrl-E

Stereo-viewing

H
I

Viewing
Viewing

Rotate around screen X axis (away fromviewer)Rotate around screen X axis (towardviewer)Rotate around screen Y axis (away fromviewer)Rotate around screen Y axis (towardviewer)Rotate around screen Z axis (counterclockwise)
Rotate around screen Z axis (clockwise)
Reset rotation to original state
Zoom in/out
Stop data rotation
Toggle anaglyph modeSet background color to black
Color points using the RGB values in the
LAS file
Decrease eye separation in split-screen
stereo mode
Increase eye separation in split-screen
stereo mode
Reset eye separation in split-screen stereo
mode
Color points using the height/elevation
Toggle display of axes (wireframe cube)
121

Keystroke/mouseactionJ
L

Context

Description

Viewing
Viewing

M
N

Viewing
ViewingO
P
Q

Viewing
Viewing
Viewing

R
S
Ctrl-TV

Viewing
Viewing
Viewing
Viewing

W
X

Viewing
Stereo-viewing

Z
Shift-Z
Ctrl +
Ctrl F5

DTM-scanning
DTM-scanning
Viewing
Viewing
Viewing

Color points using the return number
Toggle coloring using LAS classification
values and flags
Toggle continuous rotation mode
Toggle coloring using intensity data from
LAS files (if available)
Reset orientation (overhead view)
Toggle points display on/iff
Toggle between the low- and high-resolution
surface representations (DTM only)
Begin/end recording to AVI fileToggle split-screen stereo mode
Capture screen image
Toggle between trackball and translation
motion control modes. Translation mode
allows you to roam through the data.
Set background color to white
Toggle x-eyed/parallel-eyed viewing in splitscreen mode
Lower DTM while in scanning mode
Raise DTM while in scanning mode
Increase symbol size
Decrease symbol size
Toggle scanning mode for DTM evaluation
use + and - to move model

ExamplesThe following command displays the data file named tile20023.las using PDQ:
PDQ tile0023.las122

PolyClipData
Overview
PolyClipData clips point data using polygons stored in ESRI shapefiles. The default
behavior of PolyClipData is to produce a single output file that contains all points thatare inside all of the polygons in the shapefile. Optional behaviors include including only
points outside the polygons, producing individual files containing the points within eachpolygon in the shapefile, and clipping points within a single polygon specified using afield from the shapefile database.

SyntaxPolyClipData [switches] PolyFile OutputFile DataFile
PolyFile
OutputFile

DataFile

Switcheslda

index
outsidemultifile

Name of the ESRI shapefile containing polygons. Only polygon
shapefiles can be used with PolyClipData.
Base name for output data files. Default behavior is to create
one output file named OutputFile that contains all of the points
within all of the polygons in PolyFile.
LIDAR data file template or name of a text file containing a list of
file names (list file must have .txt extension).

Write output files using FUSION's LDA format when using LAS
input files. The default behavior after FUSION version 3.00 is towrite data in LAS format when the input data are in LAS format.
When using input data in a format other than LAS, sample files
are written in LDA format.
Create FUSION index files for the output file.
Create output file containing all points outside of all polygons in
PolyFile. When used with /shape switch, output file will containall points outside the specified polygon.
Create separate output data files for each polygon in PolyFile.

123shape:field#,value

Use the feature in PolyFile identified by value in field field#.
Output file will contain all points within the specified polygon.
field# is a 1-based index that refers to fields in the DBASE fileassociated with the shapefile. The /shape switch is ignored forother formats.
If the polygon identifier contains a space, enclose the identifierin quotes.
Use a “*” for value to force indexing of the polygon file andparse polygon identifiers from field#.

class:string

ignoreoverlap
precision:scaleX,
scaleY,scaleZ

If you do not use the /shape switch in conjunction with the/multifile switch, output files will be identified using thesequential number associated with the polygon rather than avalue from a database field.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the output.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character ofstring is “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).
Control the scale factor used for X, Y, and Z values in output
LAS files. These values will override the values in the source
LAS files. There is rarely any need for the scale parameters tobe smaller than 0.001.

Technical Details
PolyClipData recognizes only ESRI shapefiles containing polygons. Polygons can be
simple, one-part shapes, multi-part polygons, or polygons with holes. To ensure
accurate clipping, the shapefile should be “cleaned” in ArcInfo to ensure that thearrangement of polygons and especially holes in polygons are correctly arranged andordered.
PolyClipData does not work correctly with overlapping polygons. Basically, when you
use the /multifile option, the first polygon encountered gets all the points in the area
overlapped by additional polygons. When overlapping polygons are detected, a warning
message is printed but processing proceeds. A work-around for this limitation when you
have polygon identifiers that are sequential numbers is to use a DOS FOR loop to clip
each polygon separately. You can also use GIS operations to split out polygons thatoverlap other polygons into separate shapefiles and then process each shapefile
separately. This limitation may be corrected in future versions.
When used with the /multifile switch, PolyClipData produces a separate point file foreach polygon. PolyClipData tries to minimize the number of times the point data are124

read during the clipping process. However, due to limitations related to theprogramming language used for PolyClipData and Windows, there is a limit to thenumber of polygons that can be clipped in each pass through the data. Prior to FUSION
V4.20 (PolyClipData V1.71), only 64 polygons could be clipped in each pass. This limit
was increased to 512 polygons in later versions. This means that PolyClipData mayneed to divide the polygons into groups and process each group using a separate passthrough the point data. This process is transparent to the user except for the status
messages indicating that only a portion of the polygons are being processed.

ExamplesThe following command clips all points in tile0023.las that are inside to polygons
contained in stand_polys.shp and saves them in a single file names
stand_pts_tile0023.las:
PolyClipData stand_polys.shp stand_pts_tile0023.las tile0023.las
The following command clips points from tile0023.las that are inside of polygons
identified by the value “plantation” in the fourth column of the shapefile database forstand_polys.shp and stores the point data in a file named plantations.las:
PolyClipData /shape:4,plantation stand_polys.shp plantations.las tile0023.las
The following command clips points from tile0023.las that are inside polygons stored instand_polys.shp creating a separate file for point inside each stand polygon. Output files
are labeled using the values in the third column of the shapefile database.
PolyClipData /shape:3,* stand_polys.shp stand.las tile0023.las125

RepairGridDTM
Overview
RepairGridDTM creates a new set of DTM tiles for datasets where the set of DTM tiles
do not provide full coverage for the area. This occurs most often when DTMs aredelivered in a raster format where the vendor has not considered the correct alignmentof the cells in adjacent tiles. Basically, the DTMs have been treated as raster data
where the entire cell is represented by the value for the cell instead of lattice data wherethe values represent points located at the center of each cell. When the individual files
are interpreted as surfaces, there is a 1 cell gap between adjacent tiles.

SyntaxRepairGridDTM [switches] groundfile extraspacegroundfile

extraspace

File specifier for ground surface models in PLANS DTM format.
May be wildcard or text list file (extension .txt only). Normallythis will specify all DTM files for a project area or acquistition.
Distance added around all sides of a DTM tile. Same units as
the source groundfiles.

Switches
The standard FUSION-LTK toolkit switches are supported,

Technical Details
Bare ground surface models delivered in ARC GRID format (or other raster formats)assume that the elevation represents the entire cell instead of a single point. In ArcInfo,the lattice structure is more appropriate. When converted to ASCII raster format, thelocation of the lower left corner of the lower left cell is reported in the ASCII rasterheader. When FUSION converts the ASCII raster file into the PLANS DTM format, it
understands that the elevation value is actually a point sample for the ground surface
and adjusts the origin of the model to the center of the lower left cell (Figure 8). Thisbehavior is fine for a single model. However for two adjacent models the result is a 1cell gap between the extents of the two models (Figure 9). If the two or more models are
merged, FUSION interpolates elevations to fill the gap. However, if the two models aremaintained as separate files for subsequent use, the gap will remain and any programthat tries to use the model will “see” the gap and report that there are no valid elevations
for the area covered by the gap. This is especially problematic when we want to use themodel to normalize the LIDAR return elevations relative to the ground elevation(produce a return height instead of return elevation). Programs like GridMetrics can
produce results with distinct stripes that correspond to the gaps between models.

126

Figure 8. Relationship between GRID and DTM cell arrangements.

Figure 9. When two models are combined, there is a gap in the coverage area (1 cell wide/high).

This “problem” is usually the result of improper processing by the data provider.
However, there are open-source tool chains available that can also create the problem.
In ArcInfo, the problem is addressed when splitting a large ground surface into smaller
tiles. The Split Raster tool allows you to specify overlap between adjacent tiles. The
correct overlap should be at least 1 cell to ensure that raster data interpreted as a lattice
will not produce any gaps between adjacent tiles.
When using RepairGridDTM, you would typically set extraspace to the cell size for the
DTM. It doesn’t hurt to make the value larger as any overlapping areas between
adjacent tiles will have the same values. Extraspace doesn’t have to be a multiple of thecell size. The origin, width, and height of the DTM will be adjusted so they are multiplesof the cell size. The files produced by RepairGridDTM will have the same name as theoriginal tiles but will have “_repaired” appended to the file name.

ExamplesThe following example expands the extent of individual DTM tiles by 2 units. In thiscase, the source DTM tiles have a cell size of 1 unit.

127ReturnDensity
Overview
ReturnDensity produces raster outputs containing the number of returns in each cell.
This type of output can also be produced using the Catalog utility but ReturnDensity ismore efficient and only produces the return count layer. Output from ReturnDensity isuseful in the LTKProcessor and AreaProcessor workflow tools to help subdivide large
acquisitions into manageable chunks for processing. ReturnDensity also produces
percentile values for first return intensity values. These are useful for establishingscaling values when creating intensity images or comparing intensity values for different
acquistitions.

SyntaxReturnDensity [switches] outputfile cellsize datafile1 datafile2...
outputfile
cellsizedatafile1

datafile2

Name for output raster file (stored in PLANS DTM format with.dtm extension).
Desired grid cell size in the same units as LIDAR data.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT
formats)...may be wildcard or name of text file listing the data
files. If a wildcard or text file is used, no other datafile#parameters will be recognized.
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on thelength of each file name. When using multiple data files, it isbest to use a wildcard for datafile1 or create a text filecontaining a list of the data files and specifying the list file asdatafile1.

Switches
first
last

only

ascii
nointpercentile

projection:filename

Use first returns when computing return counts (default is all
returns).
Use last returns when computing return counts (default is all
returns). Only valid for LAS or LAZ format files. Cannot be
combined with /first or /only.
Use last returns from pulses with only 1 return when computing
return counts (default is allreturns). Only valid for LAS or LAZ
format files. Cannot be combined with /first or /last.
Output raster data in ASCII raster format instead of PLANS
DTM format. Output file extension will be “.asc”.
Do not compute percentile values associated with first return
intensity and output to CSV file. These values are useful todetermine the range of values to scale intensity products.
Associate the specified projection file with ASCII rasterproducts.

128class:string

ignoreoverlap
grid:X,Y,W,H

gridxy:X1,Y1,X2,Y2

align:filename
extent:filename

datacoverage

LAS files only: Specifies that only points with classification
values listed are to be included in the subsample. Classification
values should be separated by a comma, e.g., (2,3,4,5) and
can range from 0 to 31. If the first character of string is “~”, allclasses except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).
Force the origin of the output grid to be (X,Y) instead ofcomputing an origin from the data extents and force the grid tobe W units wide and H units high...W and H will be rounded up
to a multiple of CellSize.
Force the origin of the output grid to be (X1,Y1) instead ofcomputing an origin from the data extents and force the grid touse (X2,Y2) as the upper right corner of the coverage area. The
actual upper right corner will be adjusted to be a multiple of
CellSize.
Force the origin and extent of the output grid to match the lower
left corner and extent of the specified PLANS format DTM file.
Force the origin and extent of the output grid to match the lower
left corner and extent of the specified PLANS format DTM file
but adjust the origin to be an even multiple of the cell size andthe width and height to be multiples of the cell size.
Check for points within each cell in the output grid. Output avalue of 1 if there are points covering the cell and a value of 0 if
not.

Technical Details
ReturnDensity is typically used to produce a raster layer containing point density
information and a csv file containing percentile values for first-return intensity. It
produces the same output as produced by the Catalog utility when the /rawcounts and/density options are used. The output from ReturnDensity can be used along with
LTKProcessor to develop an arrangement of processing tiles that contain a specificnumber of returns. By default, the output contains the total number of returns in eachcell. Using the /first switch outputs only the number of first returns in each cell.
ReturnDensity displays some of the intensity percentile values on the command line andproduces a CSV file containing all percentile values.

ExamplesThe following example produces a raster file (stored in .DTM format) containing thenumber of first returns in each 5 by 5-unit cell:
ReturnDensity /first pulsedensity.dtm 5 *.las
The following example produces a raster file (stored in .DTM format) containing thenumber of returns (all returns) in each 5- by 5-unit cell:
ReturnDensity pulsedensity.dtm 5 *.las

129

SplitDTM
Overview
SplitDTM divides a .DTM file into smaller tiles. It is most often used when bare-groundsurface models are delivered in large tiles that cannot be managed efficiently. The
command-line tools in FUSION all provide the ability to work with multiple groundsurface files. In operation, the tools either build new, temporary grids covering the areaof interest or access the ground models from disk. When creating workflows forprocessing data covering large areas, LTKProcessor allows users to specify the
maximum number of returns in a processing tile. For datasets where the ground modeltiles are large, some tools have problems loading the large models while trying to build
a temporary model to support the analysis tasks. The result is that the programs start topage data in and out of memory and performance suffers by several orders ofmagnitude. By subdividing large ground tiles into smaller tiles, memory is used more
efficiently and the paging behavior is avoided. SplitDTM offers two ways to specify thearrangement of the new tiles. In the first, the user specifies the number of rows andcolumns of new tiles and for the second the user specifies the maximum number of cells
in a new tile. SplitDTM provides a default maximum number of cells (25 million) that
produces tiles that are about 100Kb and cover an area that is 5000 by 5000 cells. Thissize seems to work well with all processing tools and improves the overall processing
efficiency.

SyntaxSplitDTM [switches] inputDTM outputDTM columns rows
inputDTM
outputDTM
columns
rows
Switches
maxcells:[#]Name of the existing PLANS format DTM file to be subdivided.
Base name for the new PLANS format DTM tiles. The actual tile namewill have the column and row appended to it.
Number of columns of tiles.
Number of rows of tiles.

Maximum number of cells in the output tiles. When this option is used,the column and row parameters are ignored but values for them areneeded on the command line. The number of columns and rows will becalculated to produce tiles that contain fewer that the specified numberof cells. The default maximum number of cells is 25,000,000.

Technical Details
SplitDTM is a simple program that was designed to help improve processing efficiency
for large areas. When the user specifies the number of columns and rows of output tiles,
the program simply cuts the large inputDTM into the needed number of tiles. It does notevaluate the tiles to see if they contain valid data so it is possible, when the coveragearea within a large tile does not cover the full extent of the tile, to produce tiles that arefilled with NODATA values. If the user uses the /maxcells option, the logic in SplitDTM
tries to produce reasonably square tiles that do not exceed the size constraint. The logic
130

that calculates the number of columns and rows is not perfect. In some cases, SplitDTM
will produce more tiles that it needs to but all tiles will contain valid data and have fewerthat the maximum number of cells. For example, it might split an area into 24 tiles whenit could have split it into 22 tiles and still met the size constraint. In all cases, the tiles
created by SplitDTM can be merged together to create a model that is identical to theoriginal (except the model description will be changed to reflect the use of the SplitDTM
and MergeDTM tools) using the MergeDTM tool.
The inputDTM and outputDTM names can be the same since SplitDTM appends thecolumn and row numbers to the tiles it creates.

ExamplesThe following example splits a large surface model into 20 smaller tiles:
SplitDTM q557432.dtm q5574232_tiles.dtm 4 5
The following example splits a large model into smaller tiles based on the default
maximum number of cells in the output tiles (note that you must still include the columnnd row parameters on the command line when using the /maxcells option):
SplitDTM /maxcells q557432.dtm q557432.dtm 1 1
The following example splits a large model into smaller tiles based on a specifc
maximum number of cells in the output tiles:
SplitDTM /maxcells:40000000 q557432.dtm q557432.dtm 1 1

131

SurfaceSample
Overview
SurfaceSample produces a comma separated values (CSV) file that contains a valueinterpolated from the surface at a specific XY location. Input is a file containing a list of
XY coordinate pairs, one pair per line of the file. Output is a CSV file containing theoriginal XY location and the surface value. Optionally SurfaceSample can generate a
network of radial profiles given center point, the number of radial lines, length of eachline and the desired point spacing. SurfaceSample can also generate a series of evenly
spaced sample points along a line specified by two endpoints. The formats of the input
and output files vary depending on the options used.

SyntaxSurfaceSample [switches] surfacefile inputfile outputfile
surfacefile
inputfile

outputfile

Switches
pattern:type,p1,p2,p3

Name for surface model (PLANS DTM with .dtm extension).
Name of the ASCII text file containing the XY sample locations. This
file can be in CSV format including a header line to identify data
columns. If a header is included, column names should not start withnumbers. The XY values can be separated by spaces, commas, ortabs.
If the /pattern option is used with type 3, the inputfile should containtwo coordinate pairs that specify the endpoint of the line. If the /id
option is used, the inputfile should contain a point identifier in the firstcolumn.
Name for the output data file. Output is stored in CSV format. The
format and arrangement of the output data varies depending on theuse of the /id and /pattern options.

Generate a test pattern of sample points centered on the XY locationfrom the inputfile.
Pattern type 1 is a radial network of p1 lines that are p2 long withsample points every p3 units. The first radial is at 3 o’clock and radials
are generated in counter-clockwise order.
Pattern type 2 is a radial network of p1 lines that are p2 long withsample points every p3 units ON AVERAGE. The sample point spacing
decreases as the distance from the XY location increases to provide
sample point locations that represent a uniform area. The first radial islocated at 3 o’clock and radials are generated in counter-clockwiseorder.

132

topo:dist,latnoheadernovoidid

Pattern type 3 expects two coordinate pairs in the input data. The pairs
specify the endpoints of a line. Lines with points spaced p1 units apartare created and written to the output.
Compute and output a solar radiation index (SRI) based on Keating etal. (2007). The algorithm for SRI uses a three- by three-cell grid where
each grid cell is dist by dist units to compute topographic attributes.
Then the slope and aspect are combined with the input latitude (lat) tocompute SRI. When /topo:dist,lat is specified, output includes theslope, aspect, profile curvature (along the slope), plan curvature(across the slope), and SRI. Latitude values are positive for thenorthern hemisphere and negative for the southern.
Suppress the header line in the outputfile. This option is useful when
you want to use PDQ to view the outputfile.
Suppress output for XY sample points outside the surface extent or for
points with invalid surface elevations.
Read a point identifier from the first field of each line from the inputfile
and output it as the first field of the outputfile. If id is used with pattern,a separate output file is created for each point in the inputfile. Output
files are named using outputfile as the base name with the point
identifier appended to the filename. Even when inputfile contains asingle point, the outputfile name is modified to reflect the point
identifier.

Technical Details
SurfaceSample interpolates a value from a surface for each input XY location. If the XY
location is outside the extent of the grid file, the value is set to -1.0 and output to the
outputfile.
The input file can be a single XY coordinate, a simple list of XY coordinates, or a list ofidentifiers and XY coordinates. If the input file contains a header in the first line of thefile, the column labels cannot start with numbers. If they do, they first line of data in the
output file will contain erroneous data.
The output CSV file reports the surface value with 6 decimal digits for surface files that
contain floating point values and with 0 decimal digits for surface files that containinteger values.
When SurfaceSample is used with the /topo:dist,lat switch, a solar radiation index (SRI)
and other topographic indices are computed for each input point. SRI combines
information about the aspect, slope, and latitude into a single index that describes theamount of solar radiation theoretically striking an arbitrarily oriented surface during thehour surrounding noon on the equinox (Keating et al. 2007). The parameters for the
topo switch define the size of the surface cell and the latitude for the study area. In
operation, elevations are interpolated for points defining a three- by three-cell gridwhere each grid cell is dist by dist units. These elevations are then used to compute theslope, aspect, and curvature for the surface patch (Zevenbergen and Thorne 1987). For

133

most applications, the distance (or cell size) should not be small. The overall goal is todescribe the terrain shape and not to capture every micro-topographic detail. SRI as
defined by Keating et al. (2007) ranges from -1.0 to 1.0 but the full range is not possible
at every location due to the effect of latitude on the index. For SurfaceSample, thisrange has been adjusted to range from 0.0 to 2.0. SRI does not consider the change in
the amount of solar radiation that occurs over the course of a day or year or changes
that result from topographic shading. However distills information about slope, aspect,
and latitude into a single linear value useful for comparing locations. When topo is
specified, output includes the slope, aspect, profile curvature (along the slope), plancurvature (across the slope), and SRI all reported with 6 decimal digits regardless of thestorage type for the elevations in the surface model. The formula used to compute SRI(adapted from Keating et al. 2007) is:
𝑆𝑅𝐼 = 1.0 + cos(𝑙𝑎𝑡𝑖𝑡𝑢𝑑𝑒) ∗ cos(𝑠𝑙𝑜𝑝𝑒) + sin(𝑙𝑎𝑡𝑖𝑡𝑢𝑑𝑒) ∗ sin(𝑠𝑙𝑜𝑝𝑒) ∗ cos (𝑎𝑠𝑝𝑒𝑐𝑡)
where:
latitude is the latitude in degrees with north latitudes positive and south latitudes
negative
slope is the inclination of the surface from the horizontal position in degrees
aspect is the surface azimuth angle in degrees relative to south (180.0 – calculated
aspect)When SurfaceSample is used with the pattern switch and pattern types 1 and 2, eachradial line contains the surface value for the XY location from the inputfile (i.e. the center
point) followed by sample points for the first line of the radial pattern. Radial lines startat 3 o’clock and proceed in counter-clockwise order. The length of each radial line is atleast p2 units long (length is rounded up to be an even multiple of the point spacing(p3)). If the /id option is used, separate files are created for each center point and theidentifier for each point includes the identifier read from the inputfile and an identifier forthe radial line.
When SurfaceSample is used with the pattern switch and pattern type 3, the inputfile
should consist of two coordinate pairs. The output contains evenly-spaced points(spacing specified using p1) starting with the first coordinate pair and ending with thesecond pair. Point spacing between the last and next to last points may not match thevalue specified by p1.

ExamplesThe following example reads locations from the file named plotsSE.txt and outputs
surface values interpolated the surface bare_ground.dtm into the outputfile named
plot_elevations.csv.
SurfaceSample bare_ground.dtm plotsSE.txt plot_elevations.csv
The inputfile, plotsSE.txt contains the following records:
524750.0,5200000.0

134524750.0,5200250.0
524750.0,5200500.0524750.0,5200750.0524750.0,5201000.0
525000.0,5200000.0
525000.0,5200250.0
525000.0,5200500.0
525000.0,5200750.0
525000.0,5201000.0
The outputfile, plot_ elevations.csv contains the following values (values were truncatedto one decimal place for this example):
X,Y,Value
524750.0,5200000.0,156.2
524750.0,5200250.0,162.5
524750.0,5200500.0,-1.0
524750.0,5200750.0,-1.0
524750.0,5201000.0,-1.0
525000.0,5200000.0,146.9
525000.0,5200250.0,143.9
525000.0,5200500.0,-1.0
525000.0,5200750.0,-1.0
525000.0,5201000.0,-1.0
The following examples generate a sample of points along radial lines around a single
XY location (stored in single_plot.csv). There are 8 lines that are 85 meters long. The
first command line creates evenly-spaced sample points every 1 meter and the second
creates points spaced to represent equal areas:
SurfaceSample /pattern:1,8,85,1 bare_ground.dtm plotsSE.txt single_plot.csv
SurfaceSample /pattern:2,8,85,1 bare_ground.dtm plotsSE.txt single_plot.csv
Output as displayed in PDQ is shown below (uniformly spaced on the left and equalarea on the right).

135SurfaceStats
Overview
SurfaceStats computes surface area and volume under the surface (or between thesurface and the ground) for an entire surface. Output is a single set of values stored in a
CSV format file.

SyntaxSurfaceStats [switches] inputfile outputfile
inputfile
outputfile
Switches
ground:fileName for the input DTM surface file including the .dtm extension.
Name for the output CSV file containing the surface statistics.

Use the specified surface model to represent the ground surface file
may be wildcard or text list file (extension .txt only). A valueinterpolated from the file will be subtracted from every grid point in the
inputfile.

Technical Details
SurfaceStats is useful for computing measures of canopy surface roughness andvolume for small areas such as sample plots. It computes a single set of values for theentire area covered by the inputfile. Surface area and volume are computed by dividing
each grid cell in the surface into two triangles from the lower left to the upper rightcorner. Then the area of each triangle is computed using the 3D coordinates of thetriangle vertices. Area is the magnitude of the cross product of the three vertices.
Volume under the surface for each triangle is computed by multiplying the flat triangle
area (1/2 of the grid cell area) by the average elevation (or height) of the three vertices.
Totals for the entire surface are simply the sum of the values for each triangle. Area andvolume are only computed when all four corners of a cell in the inputfile have valid data.
If any vertex has an invalid elevation (or height), the area and volume for the entire cellis 0.0.

136

SurfaceStats computes and outputs the following values:
Value
Upper surface (canopy)
Lower surface (ground)
Min X
Min Y
Min Elev
Max Elev
Columns
Rows
Cell Width
Cell Height
Overall Planimetric Area
Planimetric Area (Data
only)
Upper Surface Area
Volume Under Upper
Surface

Description
Name of the input surface file
Name of the ground file specified with the /groundswitchMinimum X in the input surface
Maximum X in the input surface
Minimum Y in the input surface
Maximum Y in the input surface
Number of columns in the input surface
Number of rows in the input surface
Width of each cell in input surface
Height of each cell in input surface
Total horizontal area covered by the surface(includes areas with invalid elevations (or heights)
Total horizontal area covered by cells with valid
elevations (or heights).
Total area of the surface
Total volume under the surface

ExamplesThe following example computes the surface area and volume for the canopy model
stored in PLOT1139.DTM and writes the values to the CSV file named
PLOTSUMM.CSV:
SurfaceStats PLOT1139.DTM PLOTSUMM.CSV

137

ThinData
Overview
ThinData allows you to thin LIDAR data to specific pulse densities. This capability isuseful when comparing analysis results from several LIDAR acquisitions that werecollected using different pulse densities. ThinData is also useful when the density within
a single LIDAR data set is not uniform. This is often the case with data collected from aslow-flying helicopter or when flightline overlap was not closely monitored. ThinData
has also been used in simulation experiments to assess the effect of LIDAR pulse
density on the accuracy of estimated forest inventory metrics such as overall treeheight.

SyntaxThinData [switches] OutputFile Density CellSize DataFile
OutputFile
Density
CellSizedatafile1

datafile2

The name of the output LIDAR data file containing the newdataset thinned to the desired density.
Desired pulse density per square unit.
The cell size used to compute data density specified in square
units.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT
formats)...may be wildcard or name of text file listing the data
files. If wildcard or text file is used, no other datafile# parameters
will be recognized.
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).
Several data files can be specified. The limit depends on thelength of each file name. When using multiple data files, it isbest to use a wildcard for datafile1 or create a text file containing
a list of the data files and specifying the list file as datafile1.

Switches
rseed:#
index
class:string

ignoreoverlap
lda

Use random number stream #. ThinData provides 100 different
streams of random numbers so # can range from 0 to 99.
Create FUSION index files for the thinned data file.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character ofstring is “~”, all classes except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).
Write output files using FUSION's LDA format when using LAS
input files. The default behavior after FUSION version 3.00 is towrite data in LAS format when the input data are in LAS format.

138

precision:scaleX,
scaleY,scaleZ

When using input data in a format other than LAS, sample files
are written in LDA format.
Control the scale factor used for X, Y, and Z values in output
LAS files. These values will override the values in the source
LAS files. There is rarely any need for the scale parameters tobe smaller than 0.001.

Technical Details
ThinData is designed to produce output data sets that have uniform pulse densities
throughout the coverage area. To accomplish this, ThinData first scans the entire
dataset specified by DataFile and computes pulse density using the specified CellSize.
For each cell, the proportion of pulses that will be retained is computed using the
calculated pulse density and the desired pulse density. Logic within ThinData identifies
a new pulse whenever it encounters a new first return or when it encounters a 2nd, 3rd,
4th, .etc. return without a corresponding 1st, 2nd, 3rd, etc. return. ThinData does not use
the FUSION index files to read data as this could lead to separation of returns from thesame pulse when the returns occur in different tiles within the indexing grid.
In general it is best to use a large CellSize to compute the pulse densities (25 m2 orlarger). Smaller cells can be used but it will be harder to obtain specific pulse densities if
only a few pulses are contained in each cell. Experience using ThinData has shown thatit algorithm will generally produce output datasets with pulse densities within 1 to 3
percent of the specified Density.
When using the /class:string switch, ThinData uses all returns to determine the pulse
structure and then thins the pulses. However, only returns from a pulse included in thethinned data with classification values that match those specified in the /class:string
switch are written to the output file.

ExamplesThe following command thins and indexes a dataset consisting of all .las files in thecurrent directory to 5 pulses/meter2 computed using a 25 meter2 cell (5- by 5-meter):
ThinData /index newdata.las 5 25 *.las139

TiledImageMap
Overview
TiledImageMap creates a web page consisting of a single image map that corresponds
to a mosaic of image tiles. The image map is linked to individual tile images allowing theuser of the page to browse the coverage area switching between the larger overview
image and the higher-resolution individual image tiles. For colored overview images, alegend image that describes the image can be included. TiledImageMap is most often
used to organize intensity images created from LIDAR data but it can be used toprovide web-ready display of any spatial information that is organized into tiles.
TiledImageMap is particularly useful when LIDAR data have been delivered in “tiles”
and subsequent data products have been produced using files representing individual“tiles”. Creating web pages with TiledImageMap makes it easy to browse analysis
results and facilitates access to analysis products without using GIS.

SyntaxTileImageMap [Switches] OutputHTML IndexImage TileTemplate
OutputHTML
IndexImage

TileTemplate

Switcheslegend:fileName for the output HTML page (extension is not needed).
Name of the large image used to create the image map. The image
must have a corresponding world file to provide coordinate system
information.
File template for image tiles or the name of a text file containing a listof image tiles.

Add a legend image to the HTML page to the left of the image map.
file is the name of the image to use for the legend.

Technical Details
TiledImageMap uses the world files for the IndexImage and the individual tile images tolocate the tile images within the area represented in the IndexImage. All images musthave world files. The web page created by TiledImageMap allows you to click on thearea of the IndexImage and display the corresponding tile image. The IndexImage isshown at the top of the page with the legend (if specified) located below theIndexImage.

ExamplesThe following example creates a web page that contains the results of canopy coveranalyses done using Cover:TiledImageMap CoverSummary.html MergedCover.jpg cover*.jpg

140

TINSurfaceCreate
Overview
TINSurfaceCreate creates a gridded surface model from point data. The algorithm used
in TINSurfaceCreate first creates a TIN surface model using all of the points and theninterpolates a gridded model from the TIN surface. TINSurfaceCreate works well when
all points in a dataset are to be used as surface points. For example, after filtering a
LIDAR point cloud to identify bare-ground points, TINSurfaceCreate can be used tocreate a gridded surface model. However, if any non-ground points remain in thedataset, they will be incorporated into the TIN ground surface model and will, most
likely, affect the resulting gridded surface model. In general, TINSurfaceCreate should
be used only when you know all points in the dataset are surface points. If this is not thecase, use GridSurfaceCreate to create the gridded surface model.

SyntaxTINSurfaceCreate [switches] surfacefile cellsize xyunits zunits coordsys zone
horizdatum vertdatum datafile1 datafile2...
surfacefile
cellsize
xyunits

zunitscoordsyszone
horizdatumvertdatum

datafile1

datafile2

Name for output surface file (stored in PLANS DTM format with .dtm
extension).
Grid cell size for the surface in the same units as the LIDAR data.
Units for LIDAR data XY:
M for meters,
F for feet.
Units for LIDAR data elevations:
M for meters,
F for feet.
Coordinate system for the surface:
0 for unknown,
1 for UTM,
2 for state plane.
Coordinate system zone for the surface (0 for unknown).
Horizontal datum for the surface:
0 for unknown,
1 for NAD27,
2 for NAD83.
Vertical datum for the surface:
0 for unknown,
1 for NGVD29,
2 for NAVD88,
3 for GRS80.
First LIDAR data file (LDA, LAS, ASCII LIDARDAT formats)...may be
wildcard or name of text file listing the data files. If wildcard or text fileis used, no other datafile# parameters will be recognized.
Second LIDAR data file (LDA, LAS, ASCII LIDARDAT formats).

141

Several data files can be specified. The limit depends on the length ofeach file name. When using multiple data files, it is best to use awildcard for datafile1 or create a text file containing a list of the data
files and specifying the list file as datafile1.
Switches
return:stringclass:string

ingoreoverlap

Specifies the returns to be included in the sample. String can include
A,1,2,3,4,5,6,7,8,9,F,L. A includes all returns. For LAS files only: F
indicates first and only returns, L indicates last of many returns. F and
L will not work with non-LAS files.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g. (2,3,4,5)
and can range from 0 to 31. If the first character of string is “~”, allclasses except those listed will be used.
Ignore points with the overlap flag set (LAS V1.4+ format).

Technical Details
TINSurfaceCreate uses triangulation algorithms developed by Jonathan Richard
Shewchuk at the University of California at Berkeley1. These algorithms comprise are
one of the fastest, most robust triangulation applications available and were well suited
for use with millions of data points.
When creating a gridded surface model from the TIN, TINSurfaceCreate uses special
logic near the edges of the TIN surface to prevent interpolation anomalies in the output
grid. For data that is processed in tiles, most edge-matching problems are minimized
using this approach. If your data is stored in tiles, you can process each tile to produce
a gridded surface model and then combine the models using the Tools menu in
FUSION or the MergeDTM utility. As tiles are combined, edge areas will contain voids if
the TIN surface did not extend fully to the data extent. After combining tiles, the logic in
FUSION, scans the final model looking for void areas and fills these areas byinterpolating from surrounding grid values.
As stated in the overview, non-ground points included in the input data will have aneffect on the final gridded surface. The magnitude of the effect will depend on thenumber of non-ground points and their distribution. Single non-ground points will likely
influence the final surface only slightly. However, groups of non-ground points will causesignificant “bumps” in the final surface.

ExamplesThe following example creates a gridded surface model with a 2.5- by 2.5-meter cellusing the point data stored in tile0023_groundpts.las:
TinSurfaceCreate tile0023_ground.dtm 2.5 m m 1 10 2 2 tile0023_groundpts.las
1 http://www.cs.cmu.edu/~quake/triangle.html last visited September 9, 2009.

142

TopoMetrics
Overview
TopoMetrics computes topographic metrics using surface models. The logic it uses isexactly the same as that used in GridMetrics except TopoMetrics computes a
topographic position index (TPI) based on methods described by Weiss (2001) and
Jenness (2006).

SyntaxTopoMetrics [switches] SurfaceFile CellSize TopoPointSpacing Latitude
TPIWindowSize OutputFile
SurfaceFile
CellSize
TopoPointSpacing
Latitude

TPIWindowSize

OutputFile

Switches
grid:X,Y,W,H

gridxy:X1,Y1,X2,Y2

align:filename
extent:filename

squareName for the input surface file (PLANS DTM format).
SurfaceFile may be wildcard or text list file (extension .txt).
Size of the cell used to report topographic metrics
The spacing for the 3 by 3 array of points used to compute thebasic topographic metrics.
Latitude for the center of the data area. North latitude ispositive, South is negative. Latitude is used to compute thesolar radiation index.
The size of the window used to compute the topographic
position index. When the /square option is used, the TPI
window will be TPIWindowSize by TPIWindowSize. For roundwindows, the diameter will be TPIWindowSize.
Base name for the output metrics (CSV format).
"_topo_metrics" will be appended to the name provided on thecommand line.
Force the origin of the output grid to be (X,Y) instead ofcomputing an origin from the data extents and force the grid tobe W units wide and H units high...W and H will be rounded up
to a multiple of CellSize.
Force the origin of the output grid to be (X1,Y1) instead ofcomputing an origin from the data extents and force the grid touse (X2,Y2) as the upper right corner of the coverage area. The
actual upper right corner will be adjusted to be a multiple of
CellSize.
Force the origin and extent of the output grid to match the lower
left corner and extent of the specified PLANS format DTM file.
Force the origin and extent of the output grid to match the lower
left corner and extent of the specified PLANS format DTM file
but adjust the origin to be an even multiple of the cell size andthe width and height to be multiples of the cell size.
Use a square-shaped mask when computing the topographic
position index. The default mask shape is a circle.

143

annulusinnerdia:dia

annuluswidth:width

diskgroundnointernalground

lockdtmcellsize

Use a donut-shaped mask when computing the topographic
position index. The outer diameter is TopoDistance and theinner diameter is dia. When using this option to define a narrow
ring, use the /verbose option to display the computed mask toensure it meets your expectations.
Use a donut-shaped mask when computing the topographic
position index. The outer diameter is TPIWindowSize and theinner diameter is TPIWindowSize-(width*2). When using thisoption to define a narrow ring, use the /verbose option todisplay the computed mask to ensure it meets yourexpectations.
Do not load ground surface models into memory or create a
temporary surface in memory. When this option is specified,larger areas can be processed but processing will be very muchslower.
Do not create a temporary surface in memory. When this option
is specified, larger areas can be processed but processing will
be much slower. This option has no effect when used with/diskground.
Force the cell size used when creating an internal ground model
to be the same as the highest resolution input ground surface
model. The default behavior will increase the cell size until theinternal model will fit in the available memory.

Technical Details
TopoMetrics uses the same logic as GridMetrics to compute topographic metrics. The
additional output: topographic position index (TPI) is calculated using a moving window
centered on the grid-cell center. The size of the window is controlled by the
TPIWindowSize parameter. The default window is circular so TPIWindowSize specifies
the window diameter. You can use the /square switch to use a square moving window.
The two annulus options allow you to do a “donut” shape. The /annulusdia:dia option
lets you specify the inner diameter and the /annulus:width option allows you to specify
the thickness of the “donut.” These options should never be used together.
Topographic Position Index (TPI) is a method that compares the elevation of each cellin a surface to the mean elevation of a specified neighborhood around that cell. Local
mean elevation of the n cell values within the window (Zi) is subtracted from theelevation value at center of the local window (Z0).
𝑇𝑃𝐼 = 𝑖𝑛𝑡 (((𝑍0 −∑𝑛1 𝑍𝑖) ∗ 100) + 0.5)𝑛

The multiplication by 100 scales the values into a more easily visualized range. The
addition of 0.5 and truncation to an integer effectively rounds the index to the next larger
integer value.

144

When run using small windows (5-150m), TPI captures local topographic variations
down to the micro-site level. As the window size is increased the index begins to giveinformation describing landform position but still captures watershed-scale features. For
even larger windows, the TPI values related to major landform features and smallerfeatures become less obvious. For information describing the use of TIP to classify
landform features refer to Weiss (2001).

ExamplesThe following command will calculate topographic metrics using all of the .DTM files in
the BE_models folder. The area is centered on a latitude of 44.375 degrees. All metrics
will be reported for 30 unit cells. The basic topographic metrics will be computed using a
3 by 3 array of elevation values spaced 30 units apart. TPI will use the default circular
window with a diameter of 150 units. The output will be stored in CSV format in a file
named topo_metrics_30m.csv:
TopoMetrics BE_models\*.dtm 30 30 44.375 150 topo_metrics_30m.csv
This command will compute the same topographic metrics but will use an annulusshaped window with a thickness of 5 units instead of a circular window:
TopoMetrics /annuluswidth:5 BE_models\*.dtm 30 30 44.375 150 topo_metrics_30m.csv

145

TreeSeg
Overview
The TreeSeg program applies a watershed segmentation algorithm to a canopy heightmodel to produce “basins” that correspond to dominate clumps of tree foliage andbranches. In some cases, the segments represent individual trees but it is common forsegments to encompass several tree crowns. The resulting segments also represent
dominant and co-dominant trees better that mid-story and under-story/suppressed
trees. Output can consist of several products:• Basin list in CSV format containing the basin number (first basin is 2), thelocation of the high point, number of canopy height model cells within the basin,
maximum surface height for the basin, and the row and column within the canopy
height model for the basin high point.
• Basin map in ASCII raster format: Each basin is assigned a unique number
starting with 2. Areas not part of any basin are given a value of 1.
• Maximum basin height map in ASCII raster format. Each basin is assigned avalue corresponding to the maximum height for the basin.
• High point list in shapefile format with the same fields as the basin list.
• Basin/crown perimeter polygons in shapefile format. Polygon attributes include
the location of the highest point (from the basin), the actual area of the polygon,
and the maximum height of the basin.

SyntaxTreeSeg [switches] CHM ht_threshold outputfile
CHM
Name for canopy height model (PLANS DTM with .dtm
extension). May be wildcard or text list file (extension .txt only)This can be a canopy surface model if the /ground option isused to specify a ground surface for normalization.
ht_threshold
Minimum height for object segmentation. Portions of the CHM
below this height are not considered in the segmentation.
outputfile
Base name for output file. Metrics are stored in CSV format with
.csv extension. Other outputs are stored in files named using
the base name and additional descriptive information.
SwitchesheightNormalize height model(s) using ground model(s) specified withthe /ground option.
ptheight
Normalize point heights using ground model(s) specified withthe /ground option.
maxht:height
Force the maximum height for the segmentation. This will
override the actual maximum value in the CHM. Use this option
to force equal vertical resolution across areas with varying
maximum canopy heights.
grid:X,Y,W,H
Force the origin of the analysis area to be (X,Y) instead ofcomputing an origin from the CHM extent and force the widthand height to be W and H.

146

gridxy:X1,Y1,X2,Y2

align:filename

buffer:width

ground:filename

points:filename

class:string

segmentpts

clipfolder:pathshapecleantile
htmultiplier:#
projection:filename

Force the origin of the analysis area to be (X1,Y1) instead ofcomputing an origin from the CHM extent and force the area touse (X2,Y2) as the upper right corner.
Force the origin and extent of the analysis area to match thelower left corner and extent of the specified PLANS format DTM
file.
Add a buffer to the data extent specified by /grid, /gridxy or/align when segmenting but only output data for the segments
located within the extent.
Use a surface file to normalize the canopy surface and point
data. (PLANS DTM with .dtm extension). May be wildcard or
text list file (extension .txt only).
LIDAR point data file(s) in LDA or LAS format. May be wildcard
or text list file (extension .txt only). Points are assigned toindividual basins or crown polygons and a separate file (in LDA
format only) is output for each basin or polygon.
Used with LAS format files only. Specifies that only points withclassification values listed are to be included in the subsample.
Classification values should be separated by a comma e.g.
(2,3,4,5) and can range from 0 to 31. If the first character ofstring is “~”, all classes except those listed will be used.
Output points for the raster segments. Default is to output points
for crown polygons when the /shape option is used and for
raster segments when /shape is not used. Used only with the/points option.
Folder name where point files for individual clips are stored.
Used only with the /points option. If not specified, point files are
stored in the same folder with other outputs The folder namemust end with a trailing backslash and must already exist.
Create a shapefile containing the high points and basin metrics
and another shapefile containing basin/crown outline.
Output an ASCII raster map that only includes basins within thereporting extent defined by the /grid, /gridxy, and /align options.
Multiply the high point heights by # for output products.
Associate the specified projection file with shapefile and rasterdata products.

Technical Details
The current version of TreeSeg does not use the points data files specified using the/points option. A future version will likely compute and output metrics using all points
within each basin.
It is important to recognize that TreeSeg does not necessarily produce outputs that
represent individual trees. In open stand conditions, the basins may correspond well toindividual trees but as canopy density increases, the algorithm is more likely to produce147basins that represent more than one tree. In addition, as the upper canopy structure
becomes more complex (rough), individual trees may be represented as several basins.
TreeSeg is also sensitive to the resolution and amount of smoothing used to produce
the input canopy height surface. There is a “sweet spot” that balances the point density,
canopy surface resolution and amount of smoothing to produce outputs that do the best
job of capturing individual trees. Unfortunately, this combination can vary across anacquisition area or between acquisitions making it difficult to produce outputs over large
areas where there are a variety of forest types and ages with consistent accuracy orlevel of detail.
TreeSeg implements a generalized watershed segmentation algorithm as described inVincent and Soille, 1991. In concept, the canopy height model is inverted making tree
crowns or clumps of vegetation appear as “basins”. The model is then immersed inwater and the filling process is simulated using an efficient queue of pixels. As water fills
the basins fill and joins with water from adjacent basins, watershed edges are
established. The final product is a raster map where every pixel in a basin has been
assigned the same numeric code. Pixels at basin edges, designated as edges in thefilling process, are assigned to an adjacent basin using a simple majority algorithm andthe eight adjacent pixels. Basins that are located along the edge of the surface are
eliminated. Basin numbers start with 2. A value of 1 in the output basin map indicatesthat the pixel was below the height threshold. When the /shape option is used, asecondary algorithm in invoked using the input canopy height surface. For each basin,
the highpoint is used as the central point for 18 evenly-spaced radial profiles that areevaluated to find the edge of the actual basin/crown on the surface. Three criteria aretested for each point along the profile to find the edge: the point is a local minima, thepoint and the adjacent points are all lower than 0.66 * maximum height for the basin, thechange in height before the point is more than 4 times the change in height after the
point. This set of rules produces basin/crown polygons that seem to represent objects
visible on the canopy surface. The resulting polygons can overlap and they will not
usually fully encompass the basin. Output when using the /shape option is a shapefile
with the crown polygons where the attributes for each polygon include polygon identifier(matches the number if basins in the basin map), the location of the highest point (fromthe basin), the actual area of the polygon, and the maximum height of the basin.
The internal logic in TreeSeg converts the input canopy height surface into a raster ofvalues ranging from 0-255. To do this scaling, TreeSeg uses the maximum height value
in the entire surface by default. This behavior works for small areas but can result invarying results over large areas where processing is done in tiles and the maximum
height for each tile is different. If you use the /maxht option and provide a reasonable
height, results will be consistent from tile to tile.
If you are processing data using several tiles and you want consistent segment outputs
with no duplicates, you must use the /grid or /gridxy option to specify the extent of thearea, the /buffer option to include a buffer around the desired extent, and the /cleantile
option to output only segments that have their high point within the desired extent. In
addition, you must use care if you are smoothing canopy surface models as the148

alignment of the smoothing window may not be the same in adjacent tiles. TreeSeg will
use the buffered extent to perform the segmentation but will only output the segmentsthat have their high point within the unbuffered extent. For raster outputs, the extent of
the raster will included the buffer. The size of the buffer should be larger than the largest
expected tree crown. If the /shape option is used, only features associated withsegments that have their high point within the specified extent will be written to shapefile
outputs. Using this set of options and switches over a set of tiles will produce outputs
that do not include duplicate segments, high points, and crown polygons.
TreeSeg uses the same starting number for basins each time it runs so it can be hard tocombine outputs developed for adjacent areas since basin numbers will be duplicated.
This is somewhat a limitation of GIS where raster data can only have a single attributefor each cell and the absolute number of objects (basins) is finite as defined by thelargest number that can be represented given the data type used for the raster layer.
The /cleantile option is provided so you can use a buffer (at least as wide as the largest
expected tree crown) around the area of interest to produce a complete set of basins.
Only the basins that have their high point within the area of interest (defined by the /gridor /gridxy options) are labeled in the raster output and included in the CSV andshapefile outputs.
If you are using the /points option in TreeSeg, the points will be assigned to individual
segments (either using the objects in the object shapefile or the raster segments) and aseparate file in LDA format will be created for each object. Points that fall withinseveral objects are duplicated. This can produce many files so processing workflowsneed to manage these files and potentially delete them as they are further processed.

ExamplesThe following command will perform the watershed segmentation using all areas in the
TreeTop_CHM.dtm surface higher than 2m and output a raster map and CSV file of thebasins. Output file names will start with “Segments” and will have additional information
appended to identify specific products. For the raster output, a project file will be createdbased on the information contained in UTM10.prj:
TreeSeg /projection:UTM10.prj TreeTop_CHM.dtm 2 Segments.csv
The following command will produce a segment map and shapefile outputs for the areafrom (420000,7165000) to (425000,7170000) (/gridxy: 420000, 7165000, 425000,
7170000) using a set of canopy height surfaces that cover a larger area. The area will
be expanded by 120 units on each side (/buffer:120) but only segments that have theirhigh point within the extent will be included in the output (/cleantile). Outputs will include
a raster map of the segments, a csv format file and shapefile containing the highpoints,
and a shapefile containing the segments outlines:
TreeSeg /projection:UTM10.prj /gridxy:420000,7165000,425000,7170000 /buffer:120/cleantile /shape *.dtm 2 segments.csv

149

UpdateIndexChecksum/RefreshIndexChecksum
Overview
The UpdateIndexChecksum program was renamed to RefreshIndexChecksum in
FUSION version 3.60 and later to allow the program to run without administrator rights.
A “feature” in Windows prevents any executable with the word “update” in the program
name from running without administrator rights.
UpdateIndexChecksum modifies the index file checksum used to help detect when adata file has been changed and needs to be re-indexed. It is not needed for index files
created after May 2006. Versions of FUSION prior to May 2006 computed thechecksum using the time and date the data file was last modified. For external hard
drives formatted using FAT16 or FAT32, the time changes depending on whether
daylight savings time is in effect. The new checksum does not rely on the time and isstable across different drive types. When FUSION accesses a data file, it verifies thechecksum before using the index information. If a change is detected, the data file is reindexed. UpdateIndexChecksum does not re-index the data file making it much faster.
In operation, you run UpdateIndexChecksum from the directory containing your dataand it will quickly update the index file information without re-indexing the data files.
Once updated, the data files and associated index files will function properly in FUSION.

SyntaxUpdateIndexChecksum [FileSpecifier]
FileSpecifier

Name of the data file for which the index should be updated. If omitted,
UpdateIndexChecksum will check and update index files as necessary
for all LDA and LAS files in the directory.

Technical Details
UpdateIndexChecksum does not recognize any of the standard FUSION-LTK switches
and it does not write entries into the FUSION-LTK master log file.
The checksum is computed using the minutes and seconds of the last write timereported by Windows and the file size. The checksum should be the same regardless ofdrive type and format and the status of daylight savings time.

ExamplesThe following command will check and update index files for all recognized LIDAR data
files in the current directory:
UpdateIndexChecksum
The following command will check and update the index for the data file named
000263.las:
UpdateIndexChecksum 000263.las150ViewPic
Overview
ViewPic is a simple image viewer that displays BMP, JPEG, PCX, and portable bitmap
format images. It can view individual images or all images in a folder. It supports dragand-drop so you can drop images or folders onto it shortcut to display the images.

SyntaxViewPic file
file

Name of an image file of folder containing image files.

Technical Details
ViewPic doesn’t support any command line switches and does not write output to the
LTK log files.
ViewPic includes preferences to control its resizing behavior, window background color,delay between images in slideshows, and number of directories to recurse when display
images in a folder.
ViewPic can read lists of images stored in ASCII text files and display the files in the listin the same manner as files in a folder.

ExamplesThe following command displays the image named watershed.bmp:
ViewPic watershed.bmp
The following command displays all image files in supported formats within the folder
named Images:
ViewPic Images

151

XYZ2DTM
Overview
XYZ2DTM converts surface models stored as ACSII XYZ point files into the PLANS
DTM format. Input point files include one record for each grid point with the X, Y, andelevation values separated by commas, spaces, or tabs. In general, this utility is onlyused when surface models are delivered in this format. FUSION provides the ability toexport a PLANS DTM model in XYZ point format but this format is not the most efficientin terms of storage space. In addition, most GIS packages cannot directly convert thisformat into a surface model. They often use the XYZ points as if they were random XYZdata and interpolate a new grid using the point data. XYZ2DTM offers an optional switch
to fill void areas by interpolating from surrounding grid elevations.

SyntaxXYZ2DTM [switches] surfacefile xyunits zunits coordsys zone horizdatum vertdatum
datafile1 [datafile2…datafileN]
surfacefile
xyunits

zunitscoordsyszone
horizdatumvertdatum

datafile1
datafile2

Name for output surface file (stored in PLANS DTM format with .dtm
extension).
Units for LIDAR data XY:
M for meters,
F for feet.
Units for LIDAR data elevations:
M for meters,
F for feet.
Coordinate system for the surface:
0 for unknown,
1 for UTM,
2 for state plane.
Coordinate system zone for the surface (0 for unknown).
Horizontal datum for the surface:
0 for unknown,
1 for NAD27,
2 for NAD83.
Vertical datum for the surface:
0 for unknown,
1 for NGVD29,
2 for NAVD88,
3 for GRS80.
First XYZ point file...may be wildcard or text list file (extension .txt
only)...omit other datafile# parameters.
Second XYZ point file.
Several point files can be specified. The limit depends on the length ofeach file name. When using multiple data files, it is best to use a152

wildcard for datafile1 or create a text file containing a list of the data files
and specifying the list file as datafile1.
Switches
csv
fillholes:#Input files are in CSV format, skip first line when reading.
Fill holes (NODATA areas) in the final surface model that are up to # by
# cells. Larger holes will not be filled.

Technical Details
XYZ2DTM scans all data files to determine the extent of the final surface model and thegrid cell size. XYZ data files should be ordered in either rows or columns for the cell size
detection logic to work correctly. XYZ2DTM will not work with random XYZ point data.
Prior to populating the surface with grid elevations, all grid points are initialized toindicate NODATA (value of -1.0). As XYZ point files are read and processed, grid cell
elevations are inserted into the appropriate row/column location. After all XYZ point files
have been processed, the model is written using the PLANS DTM file format withfloating point elevation values.
When the /fillholes:# switch is specified. Void areas in the final surface are filled byinterpolating values from adjacent grid cells. The parameter, #, specifies the largest
distance that will be searched for valid point elevations. In operation, the void filling logic
searches in eight directions to find valid grid point elevations to use in the interpolation.
If four or more of the directional searches find a valid elevation, the hole is filled using
the average of all the values.

ExamplesThe following command will create a surface model named test.dtm using the XYZ point
files listed in the file named list.txt. The surface model will be labeled to identify the XY
units as meters and the elevation units as meters. The surface will be referenced to the
UTM coordinates system in zone 5, NAD83, with elevations referenced to NAVD88.
Holes (void or NODATA areas) in the final surface will be filled if they are smaller than 9
by 9 cells.
xyz2dtm /fillholes:5 test.dtm m m 1 5 2 2 list.txt

153

XYZConvert
Overview
XYZConvert converts LIDAR return data stored in specific ASCII text formats into binary
LDA files. The formats recognized by XYZConvert include formats provided by several
vendors and for several projects. For the most part, XYZConvert will not be needed bymost users. Its functionality has been superseded by FUSION’s tools to import generic
ASCII point data.

SyntaxXYZConvert inputfile outputfile pulse return angle intensity readangle positiveonly
formatinputfile
Name for the input ASCII text file containing LIDAR return data.
outputfile
Name of the output binary LDA data file. Using “NULL” for the nameforces XYZConvert to create a file name using the inputfile (changes
the extension to .lda).
pulse
Pulse number to be assigned to every XYZ point in inputfile. This value
is usually ignored (use 0).
returnReturn number to be assigned to every XYZ point in inputfile. Thisvalue is usually ignored (use 0).
angle
Scan or nadir angle to be assigned to every XYZ point in inputfile. Thisvalue is usually ignored (use 0).
intensity
Intensity value to be assigned to every XYZ point in inputfile. Thisvalue is usually ignored (use 0).
readangle
Flag to control reading of the scan or nadir angle from the fourthcolumn of simple ASCII XYZ data files (format = 0). A value of 1 results
in reading the fourth column.
positiveonly Flag to control conversion of points with positive elevations only. A
value of 1 results in conversion of only points with positive elevations.
formatFormat indicator. Valid values for format are:0 = Simple ASCII XYZ
1 = Terrapoint data
2 = AeroTec 1999 ASCII
3 = AeroTec 1998 ASCII
4 = Aeromap CXYZI
5 = Aeromap XYZI
6 = Cyrax XYZI
7 = Aeromap Kenai project
8 = Aeromap Kenai final ALL RETURNS
9 = Aeromap Kenai final GROUND POINTS ONLY
10 = Aeromap Kenai final FIRST RETURNS ONLY
11 = Aeromap Kenai final LAST RETURNS ONLY
12 = Aeromap UW campus project ALL RETURNS
13 = Aeromap UW campus project GROUND RETURNS ONLY
14 = PSLC 2003 data from Terrapoint
15 = LAST RETURNS ONLY...PSLC 2003 data from Terrapoint154

16 = Terrapoint data for Fort Lewis, WA
17 = Spectrum Mapping data for King County
18 = PSLC 2004 data for Pierce County, WA
19 = PSLC 2000 data for Tiger Mountain area, WA
Formats are described in the Appendices.

Technical Details
XYZConvert is simply a format conversion tool to help use data stored in a variety of
project-specific file formats in FUSION. Data acquired early in FUSION’s development
was delivered in ASCII text format and each vendor used a slightly different format for
their data products. After the LAS format specification was developed (version 1.0 in
2003 and version 1.1 in 2005), FUSION was modified to read LAS files directly with noconversion required. LAS versions 1.1, 1.2, and 1.3 are the preferred formats for LIDAR
data used with FUSION.
Many of the ASCII formats include “extra” information not useful for most LIDAR
analyses. XYZConvert only transfers the following information to the LDA files:
Pulse number,
Return number,
Easting (X),
Northing (Y),Elevation,
Nadir angle (or scan angle if not adjusted for aircraft attitude),
Intensity.
Any other information in the ASCII file will not be stored in the LDA file.

ExamplesThe following command will convert an ASCII text file containing LIDAR return datastored as RXYZI (Return number, X, Y, Elevation , and Intensity) separated by commas:
XYZConvert scan001.txt scan001.lda 1 0 0 0 0 0 4
Notice in this example that the format code of 4 indicates the Aeromap CXYZI format.
This format is in fact a “generic” data format that expects the Return number, X, Y,
Elevation, and Intensity values separated by commas or spaces.

155

Copyright Notifications
FUSION and the related command line utilities and processing programs use a variety
of software developed by other programmers. The following table describes thesoftware and copyright information for the included components:
PurposeRestrictions Developer and copyright informationas used in
FUSIONLAZ file I/O
None
Copyright 2007-2015, martin isenburg,
rapidlasso
JPEG image format
NoneThis software (FUSION and related programs)
reading and writing
is based in part on the work of the
Independent JPEG Group.
Copyright 1991-2009, Thomas G. Lane,
Guido Vollbeding.
TIFF image format
None
Copyright 1988-1996 Sam Leffler
reading and writing
Copyright 1991-1996 Silicon Graphics, Inc.
Libgeotiff
None
Copyright 1999, Frank Warmerdam andcopyright 1995, Niles D. Ritter
OpenGL window
None
Copyright W.J. Heitler and Alessandro
management
Falappa
Coordinate
None
General Cartographic Transformationtransformation
Package (GCTP) developed by USGS.
SDTS reading
None
SDTS++ C++ toolkit developed by USGS.
Serial port
None
Copyright 1998 - 2007 by PJ Naughter.
communications
TIN surface
None
Copyright 1993, 1995, 1997, 1998, 2002,
construction
2004 Jonathan Richard Shewchuk.
General matrix library None
Copyright R.B. Davis
Code to redirect
None
Copyright 1999 Matt Brunkoutput from DOS
commands to a text
controlSupport for dialog
None
Copyright 2000 Stephan Keilresizing
Support for colored
None
Copyright 1998 Bob Ryan
buttons on dialogs
Zip compression used None
Copyright 1995-1998 Jean-loup Gailly andin image files
Mark Adler
Folder dialog control
None
Copyright(C) Armen Hakobyan, 2002 – 20052
USGS DEM import
None: used
Copyright 1992, Carto Instruments
withpermission
Windows process
None
Copyright (c) 1998-1999, Jaekil Lee
enumeration
2 http://www.codeproject.com/Articles/2024/CFolderDialog-Selecting-Folders

156

Command line
parsing logic

Unknown

Copyright 1999-2003 Santronics Software,Inc.

Acknowledgements
The FUSION software has been used by many people around the world. Some use thesoftware in complete anonymity but others provide feedback and ask questions. In
almost all cases, this feedback results in improvements or modifications to the software.
I would like to personally thank fellow Forest Service researchers Steve Reutebuch andHans-Erik Andersen for the endless hours of discussion and suggestions regarding theprocessing LIDAR data to produce useful information. Graduate students at the
University of Washington, all of whom have moved on in their own careers, Yuzhen Li,
Sooyoung Kim, Tobey Clarkin, and Jacob Strunk served as unofficial testers and helped
to uncover lots of bugs during FUSION’s early development. Dr. Van Kane, also at the
University of Washington, has processed more LIDAR data than most and his
observations and suggestions have greatly improved the software and documentation.
His focus on deriving ecologically important information from LIDAR point clouds andthe subsequent enhancements and additions to FUSION will benefit all users of thesoftware.
I also want to thank Gordon W. Frazer, post-doctoral fellow in the Forest Geomatics
Group at the Pacific Forestry Centre, Canadian Forest Service, in Victoria, British
Columbia for suggesting the addition of L-moments and L-moment ratios to the suite of
metrics computed by CloudMetrics and GridMetrics. These metrics have proved usefulfor a variety of applications.
FUSION would not be successful without the training materials and first-line support
provided by the Forest Service’s Geospatial Technology and Applications Center.
(GTAC) (formally the Remote Sensing Application Center (RSAC)). The folks at GTAC
provide support for anyone wanting to use FUSION or LiDAR. In particular, Denise Laes
and Brent Mitchell developed the original tutorials. While Denise has moved on toanother job, her diligence and organization while testing and developing workflows
made FUSION a better product. Brent has taught FUSION and general LiDAR analysis
to over 1800 people including groups in Mexico, Brazil, and the Philippines. The
FUSION/LiDAR helpdesk maintained by GTAC answers questions from all over theWorld.
Finally I want to thank Martin Isenburg for all the work he has done to promote LIDAR
data standards and develop the LAStools package. His efforts have benefitted all who
work with both airborne and terrestrial scanner data. FUSION relies on his LASzip.dll to
support the compressed point data files stored in his LAZ format. In addition, LAStools
provides many capabilities that are not available in FUSION. Martin’s tools allow users
to directly manipulate LAS data and his ground filtering and surface generation tools
help users without ground surface models fully realize the potential of their data.

157

References
Andersen, H.-E., R.J. McGaughey, and S.E. Reutebuch. 2005. Estimating forest canopy
fuel parameters using LIDAR data. Remote Sensing of Environment 94(4):441-449.
Baltsavias, E. P. 1999. Airborne laser scanning: basic relations and formulas. ISPRS
Journal of Photogrammetry and Remote Sensing, 54(2-3): 199–214.
Brandtberg, T. 2007. Classifying individual tree species under leaf-off and leaf-on
conditions using airborne lidar. ISPRS Journal of Photogrammetry and Remote
Sensing, 61(5): 325–340.
Brennan, R. and Webster, T.L. 2006. Object-oriented land cover classification of lidarderived surfaces. Canadian Journal of Remote Sensing, 32(2):162-172.
Charaniya, A.P., Manduchi, R., and Lodha, S.K. 2004. Supervised parametricclassification of aerial LIDAR data. In, CVPRW’04, Proceedings of the IEEE 2004
Conference on Computer Vision and Pattern Recognition Workshop, June 27 – July 2,
2004, Baltimore, Md. Vol. 3, pp. 1-8.
Flood, M. 2001. LIDAR activities and research priorities in the commercial sector.
International Archives of Photogrammerty and Remote Sensing, Vol. XXXIV Part 3/W4,
Annapolis, MD, pp. 3-7.
Hasegawa, H. 2006. Evaluations of LIDAR reflectance amplitude sensitivity towards
land cover conditions. Bulletin of the Geographical Survey Institute, 53:43-50.
Hosking, J.R.M. 1990. L-moments: analysis and estimation of distributions using linear
combinations of order statistics. Journal of the Royal Statistical Society. Series B(Methodological). 52(1):105-124.
Hu, Tianyu, Qin Ma, Yanjun Su, John J. Battles, Brandon M. Collins, Scott L. Stephens,
Maggi Kelly, Qinghua Guo. 2019. A simple and integrated approach for fire severity
assessment using bi-temporal airborne LiDAR data. Int J. Appl Earth Obs
Geoinformation, 78 (2019): 25-38.
Hug, C. and Wehr, A. 1997. Detecting and identifying topographic objects in imaging
laser altimeter data. International Archives of Photogrammetry and Remote Sensing,Vol. XXXII Part 3-4/W2, Stuttgart, Germany, pp. 19-26.
Hyyppä, J., Hyyppä, H., Litkey, P., Yu, X., Haggrén, X. H., Ronnholm, P., Pyysalo, U.,
Pitkänen, J., Maltamo, M. 2004. Algorithms and methods of airborne laser scanning forforest measurements. International Archives of Photogrammetry and Remote Sensing,Vol. XXXVI Part 8/W2, Freiburg, Germany, pp. 82-89.
Jenness, J. 2006. Topographic Position Index (tpi_jen.avx) extension for ArcView 3.x, v.
1.2. Jenness Enterprises. Available at: http://www.jennessent.com/arcview/tpi.htm.

158

Keating, Kim A.; Gogan, Peter J.P.; Vore, John M.; Irby, Lynn R. 2007. A simple solar
radiation index for wildlife habitat studies. Journal of wildlife management 71(4):13441348.
Kini, A.U.; Popescu, S.C. 2004. TreeVaw: A versatile tool for analyzing forest canopy
Lidar data – a preview with an eye towards future. Kansas City, MO: SPRS Images to
Decision: Remote Sensing Foundation for GIS Applications.
Kraus, K., and N. Pfeifer. 1998. Determination of terrain models in wooded areas withairborne laser scanner data. ISPRS Journal of Photogrammetry and Remote Sensing.
53: 193-203.
McGaughey, R.J., Reutebuch, S.E., Andersen, H.-E. 2007. Creation and use of lidar
intensity images for natural resource applications. In: 21st Biennial Workshop on Aerial
Photography, Videography, and High Resolution Digital Imagery for Resource
Assessment, May 15-17, 2007, Terre Haute, Indiana. ASPRS, Bethesda, MD.
Unpaginated CD-ROM.
Popescu, S.C., R.H. Wynne, and R.F. Nelson, 2002. Estimating plot-level tree heights
with lidar: local filtering with a canopy-height based variable window size, Computers
and Electronics in Agriculture, 37(1-3):71-95
Popescu, S.C., and R.H. Wynne, 2004. Seeing the trees in the Forest: Using Lidar andMultispectral Data Fusion with Local Filtering and Variable Window Size for Estimating
Tree Height, Photogrammteric Engineering & Remote Sensing, Vol. 70, No. 5, May
2004, pp. 589-604.
Silverman, B. W. 1986. Density Estimation. London: Chapman and Hall.
Song, J.-H., Han, S.-H., Yu, K., and Kim, Y.-I. 2002. Assessing the possibility of landcover classification using LIDAR intensity data, International Archives of
Photogrammetry and Remote Sensing, Graz, Austria, 2002, Vol. XXXIV, Part 3B, pp.
259-262.
Vincent, L and Soille, P. 1991. Watersheds in digital spaces: an efficient algorithm
based on immersion simulations, IEEE Transactions on Pattern Analysis and MachineIntelligence, Vol. 13, No. 6, pp. 583-598.
Weiss, A.D. 2001. Topographic position and landforms analysis. Poster Presentation,
ESRI Users Conference, San Diego, CA (2001).
Wang, O.J. 1996. Direct sample estimators of L moments. Water Resources Research.
32(12):3617-3619.

159

Wehr, A. and Lohr, U. 1999. Airborne laser scanning—an introduction and overview.
ISPRS Journal of Photogrammetry and Remote Sensing, 54:68–82.
Woo, M., Neider, J, Davis, T. 1997. OpenGL programming guide: the official guide tolearning OpenGL, version 1.1. Addison-Wesley.
Zevenbergen, Lyle W.; Thorne, Colin R. 1987. Quantitative analysis of land surface
topography. Earth surface processes and landforms, 12:47-56.

160

Appendix A: File Formats

161

PLANS Surface Models (.DTM)
The Preliminary Logging Analysis System (PLANS) is a cable logging analysis systemdeveloped by the US Forest Service, Pacific Northwest Research Station in the early
1990’s. PLANS uses a binary format for its digital terrain models (DTM). The binary
format offers several advantages over an ASCII format used in the early releases of
PLANS:
1. A model stored in binary format, using two-byte Z-values, requires approximately
60 percent less storage space than the ASCII equivalent.
2. The binary format can be read faster than the ASCII format. Tests conducted in
1992 indicated the time required to read an entire model was about 50 percent
less using the binary format.
3. Using the binary format it is possible to consistently calculate the byte position of
the elevation for a specific grid point in the model file. Using the ASCII format,
which is flexible in the position of elevation values within the model file, it can bedifficult (if not impossible) to consistently calculate the byte position of a given
elevation. This allows PLANS programs to utilize the model without actuallyloading the entire model into memory. This final advantage becomes importantwhen working with larger models that cannot be loaded into memory. Using thebinary format, programs can use any size model as only small portions of themodel are loaded into memory at any given time.
The binary format is relatively simple and contains the same information as the ASCII
format. Additional descriptive parameters are included to facilitate DTM file
management and future enhancements to PLANS, e.g., the ability to use non-integer
elevations and the use of metric units (implemented 7/2002).
When reading a PLANS DTM, it is tempting to define a structure for the header
variables and then read the header as a block. Unfortunately, this approach often fails
due to packing of structures by many compilers. To ensure a successful read, read thevariables in the header one at a time.
Byte Offset
0-20

Type
String *21

21-81

String *61

82-85

Real*4

Description
ASCIIZ terminated (chr$(0)) file signature for a PLANS
DTM…must be "PLANS-PC BINARY .DTM" (20characters long plus chr$(0)).
ASCIIZ terminated DTM name...entered by user tofacilitate DTM file management. The DTM name will
always be expanded with spaces to be 60 bytes long thenthe chr$(0) will be added.
DTM file format version identifier:Original binary format (version 1.0): 3/7/90
Extended format (version 2.0): 1998
Modified to support all elevation storage types

162

86-9394-101
102-109110-117118-125

Real*8
Real*8
Real*8
Real*8
Real*8126-133
134-141
142-145
146-149
150-151

Real*8
Real*8Integer * 4
Integer * 4
Integer * 2

152-153154-155

Integer * 2

156-157

Integer * 2

158-159

Integer * 2(version 3.0): 7/2002
Added horizontal and vertical datum to header(version 3.1): 6/1/2005
Lower left corner X-coordinate of the DTM area.
Lower left corner Y-coordinate of the DTM area.
Minimum Z-coordinate in the DTM.
Maximum Z-coordinate in the DTM.
Rotation of the DTM area within the coordinate system inradians.
All versions: NO ROTATION IS ALLOWED.
Spacing between columns in the DTM.
Spacing between points along a column in the DTM.
Number of columns in the DTM.
Number of points in each column of the DTM.
Flag indicating the units used for the DTM's lower left
corner and the row and column spacing.
0 Feet1 Meters
2 Other
Flag indicating the units used for the DTM's Zcoordinates.
0 Feet1 Meters
2 Other
Flag indicating the variable type used for Z-coordinate
storage in the DTM file.
0 2-byte integer
1 4-byte integer
2 4-byte real number
3 8-byte real number
3/30/1990 ONLY TYPE 0 IS ALLOWED IN VERSION 1.0
and 2.0 FILES.
7/2002 Version 3.0 and newer supports all variable
types
Flag indicating the coordinate system for planimetricvalues.
0 Unknown (for compatibility with format 1.0 models)
1 UTM
2 State plane
3 Unknown
3+ Undefined…do not use values greater than 3
Format 2.0 and newer.
Coordinate zone.

163160-161

Integer * 2

162-163

Integer * 2

200...

Format 2.0 and newer.
Horizontal datum
0 Unknown
1 1927-NAD 27
2 1983-NAD 83(86)Format 3.1 and newer
Vertical datum
0 None or unknown
1 1929-NGVD 29
2 1988-NAVD 88
3 1980-GRS 80
Format 3.1 and newer
Z-coordinate values...Bytes per value depends on thevalue in byte offset 154-155. Negative values indicate
areas with missing data.

Bytes 156-199 (bytes 160-199 in format 2.0 models, bytes 164-199 in format 3.1
models) are "empty”. Potentially these bytes could contain values in futures revisions of
the binary DTM format. Therefore, it is recommended that these bytes remain "empty"
in any DTM used with PLANS.

164

LIDAR Data Files (.LDA)
The LDA format was developed as an alternative to ASCII text files commonly deliveredby LIDAR providers. LDA files are binary and provide a moderately compact storage
format. The advantage of the LDA format when compared to ASCII text files is that
return data can be read randomly rather than serially (sequentially). When combinedwith the FUSION indexing scheme, the format allows efficient extraction of data
samples. As of version 3.00 of FUSION, most utility programs write data in LAS format
when input data are also in LAS format. This allows you to mix FUSION tools with othertools to analyze your data. After version 3.00, the LDA format will continue to berecognized by all programs.
LDA files consist of a header and data records. The header is always 16 bytes long andcontains the following items:
Byte Offset
0-8

Type
char *8

9-12
13-16

int * 4int * 4

Description
File signature used to identify the format. This field must
contain the string “LIDARBIN”.
Major version identifier.
Minor version identifier.

The file version is formed using the following formula (C code):
Version = (float) major + (float) minor / 10.0f
Each point record is 36 bytes long and contains the following items:
Byte Offset Type
Description
0-3
int * 4
Pulse number.
4-7
int * 4Return number.
8-15
real * 8
Easting (X).
16-23
real * 8
Northing (Y).
24-27
real * 4Elevation.
28-31
real * 4
Nadir angle (or scan angle if not adjusted for aircraft
attitude).
32-35
real * 4
Intensity.
When reading or writing LDA files from either C or C++, you must instruct the compiler
to align structures on 4-byte boundaries if you want to read an entire point record into a
structure.

165

Data Index Files (.LDX and .LDI)
The indexing scheme used by FUSION is simple and can be applied to all data files
recognized by FUSION including the LDA format, LAS format, and ASCII text files.
Indexing does not require modifications to the original data files. The indexing
procedure first scans a LIDAR data file to determine the extent of the data coverage.
The area is then overlaid with a 256 by 256 grid. A new file, called the index, is createdcontaining one record for each LIDAR return in the source file. The record contains thecolumn and row for the cell containing the data point and an offset into the raw data fileto the start of the point record. After completing the index, it is sorted using the column
and row values and a second file, called the first point file, is created listing the offset
into the index file to the start of the first index entry for each cell in the index grid. Using
the index and first point file, we can quickly locate and read all data points contained ina specific cell in the index grid. When extracting a data sample, FUSION determines thegrid cells that potentially contain points in the sample and only reads data from thesecells.
The index file and the first point file use the same header record format. The header
contains a checksum value that is computed from the data file modification time to help
identify situations where a data file has been changed since it was indexed and, thus,
should be re-indexed before use. The header contains the following items:
Byte Offset
0-11

Type
char * 12

12-15
16-19

real * 4
int * 420-23

int * 4

23-30
31-38
39-46
47-54
55-62
63-70
70-73

real * 8real * 8real * 8real * 8real * 8real * 8
int * 474-77

int * 478-81

int * 4

Description
File signature used to identify the format. This field must
contain the string “LDAindex”.
Version identifier.
Checksum that will be compared to a checksum
computed from the data file modification data and time tosee if the data file has changed since the index was
created.
Format identifier for the data file. Format values are:
1 ASCII data
2 Binary LDA data
3 LAS data
Minimum X value for the data.
Minimum Y value for the data.
Minimum Z (elevation) value for the data.
Maximum X value for the data.
Maximum Y value for the data.
Maximum Z (elevation) value for the data.
Number of grid cells in the X direction for the index grid.
This value is usually 256.
Number of grid cells in the Y direction for the index grid.
This value is usually 256.
Total number of points in the data file.

16682-127

char * 46

Empty space. These byte locations can contain any value
in index file versions 1.1 and older. Future version of theindex files may use these bytes for additional data.

When reading or writing index files from either C or C++, you must instruct the compiler
to align structures on 2-byte boundaries if you want to read an entire header record intoa structure.
For index files, the remainder of the file contains one record for each data point in thedata file. The records contain the following items:
Byte Offset
0-1
2-3
3-7

Type
char * 1char * 1
int * 4

Description
Grid row containing the point.
Grid column containing the point.
Offset, in bytes, from the beginning of the data file to thestart for the data for the point.

The records are stored in sorted order based on the column and row values(ascending). The origin of the column/row numbering scheme uses (0, 0) for the lower
left corner.
For the first point files the remainder of the file contains one value for each grid cell inthe data index. The value represents the offset (int * 4) from the beginning of the index
file to the first point in each cell. Offsets are stored by columns starting with the leftmost
column and by row starting at the bottom of the column. The first value is the offset tofirst point in the lower left cell. The second value is the offset to the first point in thesecond row (from the bottom) of the leftmost column.

167

LAS LIDAR Data Files (.LAS)
The following description was taken from https://www.asprs.org/divisionscommittees/lidar-division/laser-las-file-format-exchange-activities (last accessed
8/2019):The LAS file format is a public file format for the interchange of 3dimensional point cloud data between data users. Although developed
primarily for exchange of lidar point cloud data, this format supports theexchange of any 3-dimensional x,y,z tuplet. This binary file format is analternative to proprietary systems or a generic ASCII file interchangesystem used by many companies. The problem with proprietary systems
is obvious in that data cannot be easily taken from one system to another.
There are two major problems with the ASCII file interchange. The firstproblem is performance because the reading and interpretation of ASCII
elevation data can be very slow and the file size can be extremely large
even for small amounts of data. The second problem is that all information
specific to the lidar data is lost. The LAS file format is a binary file format
that maintains information specific to the lidar nature of the data while notbeing overly complex.
FUSION reads version 1.0, 1.1, 1.2, 1.3, and 1.4 LAS files as defined in the LAS format
specification maintained on the web site listed above.
When working with data stored in LAS format, FUSION writes LAS files that are fullycompliant with the LAS specification. FUSION attempts to output data in the sameversion of the LAS format as the input data files. In cases where input data are stored in
multiple LAS formats, FUSION will produce LAS outputs in the format that matches thelowest input LAS format version. When working with input data stored in ASCII text
format, FUSION will produce LAS output files that, while they can be read by most otherprograms that read LAS format, are not complete. Some of the fields for each return are
not populated. Specifically the field that details the number of returns for a pulse isalways set to 0. This information would allow you to determine that a particular return is,for example, return 2 of 3 for the pulse. In addition, FUSION will produce LAS files fordata that is missing items such as the GPS time, scan angle, and intensity.

168

XYZ Point Files
Simple ASCII text files containing point data can be used in FUSION as POI files. XYZ
point files contain one line for each point with the X, Y, and Z (elevation) values
separated by space, comma, or tab characters. Comments can be included in the files
by using “;” in the first character of a line.

ExampleThe following is an example XYZ point file:; forest inventory plot locations UTM, zone 10, NAD83
486930.94,5189046.01,338.45
487398.87,5189534.49,357.9
488543.71,5189792.5,315.16
488460.45,5189794.49,333.54
488368.48,5189794.5,338.36
488461.84,5189884.5,317.66
488524.72,5189953.01,307.03
487018.71,5189235.51,370.15
486838.6,5189235.5,349.91
486822.21,5189190.99,348.29
486951.84,5189138,344.36

169

Hotspot Files
Hotspots are used to define specific locations that are linked to some action. Possible
actions include loading a pre-defined data set, displaying an image file, running an
external program, or just about anything else. Hotspot implementation in FUSION issimilar to a link on a web page. You move the mouse over the hotspot, the cursor
changes to a hand, and the information about the hotspot is displayed in the status
display at the bottom of the FUSION window.
Hotspot files are ASCII text files. They usually have an .HST extension. Each record(line) of the file defines a single hotspot. Lines starting with “#” or “;” in the first character
position are treated as comments.
The fields that define the hotspot are listed below in the order they should appear in the
hotspot file.
Field nameMinimum X

Data type
Number

Minimum Y

NumberMaximum X

NumberMaximum Y

NumberShape code

Integer

Description
Minimum X value that defines the hotspot
area. For icon hotspots, the minimum X
and maximum X can be the same.
Minimum Y value that defines the hotspot
area. For icon hotspots, the minimum Y
and maximum Y can be the same.
Maximum X value that defines the
hotspot area.
Maximum Y value that defines the
hotspot area.
Code identifying the shape or type for the
hotspot.
Valid codes are:4
rectangle
5
circle

170

100

icon:

101

icon:

102

icon:

103

icon:

104

icon:

105

icon:

106

icon:

107

icon:

108
Action code

Integer

Descriptive
message

Quote-delimited
stringCommand target

Quote-delimited
stringicon:

109 icon:
The action that FUSION should takewhen the user selects a hotspot.
Valid action codes are:0
open the target object forviewing using the Windows
application associated with theobject type1
display the target object using
the old Scatter3D 3Dvisualization program2
display the target object using
the prototype 3DV visualization
program3
display the target object using
the LDV 3D visualization
program99
treat the target object as avalid windows/DOS commandline and execute the commandusing the WinExec function
Message that will be displayed on thestatus line along the bottom of the
FUSION window. The actual message
will be formed by concatenating thedescriptive message and the commandtarget.
The target object for the action code. In
the case of Windows/DOS commands,
the command target is use as-is with theWinExec function.

ExamplesThe following is a hotspot file that defines two types of hotspots. The first display thebullseye icon (type 101) and link to a pre-defined data set for LDV. The second set
displays the information icon (type 100) and use a DOS command line to display an
image file using the VIEWPIC program (VIEWPIC is distributed with FUSION and candisplay many image formats). For both types of hotspots, the same point could havebeen used for the minimum and maximum XY because icons do not rely on the hotspot
area specified in the hotspot file but rather use a 32-pixel square area centered on the
average of the minimum and maximum X and Y values to define the selection area.

171; pre-defined LDV data files
976079.8661 567461.4061 976288.5761 567670.1161 101 3 "Display 1-acre data file containing blowdown using LDV: " "blowdown.set"
975383.5783 567601.0277 975800.9983 568018.4477 101 3 "Display 4-acre block from control unit using LDV: " "control4.set"
977367.9156 567913.5081 977733.9946 568279.5871 101 3 "Display 3-acre block for layer display using LDV: " "layers.set"
974776.5375 566912.6891 976503.1621 566942.6891 101 3 "Display 1727 by 30 ft corridor using LDV: " "corridor.set"; treatment area images
975400 568100 975500 568200 100 99 "Display image showing conditions in control unit: " "viewpic control.jpg";975400 568100 975500 568200 100 99 "Display image showing conditions in control unit: " "viewpic images.lst"
976700 567100 976800 567200 100 99 "Display image showing conditions in 2-age unit: " "viewpic 2a.jpg"
976800 568200 976900 568300 100 99 "Display image showing conditions in clearcut unit: " "viewpic cc.jpg"974300 566400 974400 566500 100 99 "Display image showing conditions in lightly thinned unit: " "viewpic lt.jpg"

172

Tree Files
Tree data files contain data representing the size and location of individual trees. Suchdata are usually measured in the field but analysis tools in the LIDAR Data Viewer(LDV) can output files of individual tree parameters extracted from LIDAR data.
In FUSION, tree data are displayed like other point data except that the size of the point
marker (except single pixels) is scaled to match the average width of the tree crown.
When extracting samples, tree data can optionally be included in the sample. Tree data
are used in LDV to display wire frame tree models consisting of a stem and a crown.
Optional data specifying the color used when drawing the tree crown can be specified
for each tree. This allows you to differentiate between species or condition classes
when viewing the trees in LDV.
Tree data are stored in CSV (comma separated values) format for compatibility withspreadsheet and database programs. The first line of the file contains column headings
and subsequent lines contain the parameters for each tree. The first line of the file isignored when reading trees even if it contains a valid tree record.
Data for the tree measurements should use the same units as you LIDAR data. All
heights and crown diameters should use the same units.
FUSION version 4.5 introduces additional optional fields in the tree files. These fields
are used in conjunction with the new features designed to allow users to adjust plot andindividual tree locations. The new fields are optional as indicated in the list below. In
addition to the new fields, version 4.5 recognizes a tree record with the identifier set to
PLOT_CENTER as the plot location. This object is drawn using a special symbol andthe tree movement dialog has a control allowing you to snap the measurement marker
the plot location. The marker is moved along with the trees but cannot be selected formovement by itself. For the “PLOT_CENTER” record, the size of the marker iscontrolled using the DBH parameter for the tree and the color of the marker is set to thecrown color. Other size parameters (tree height, height to crown base and crowndimensions) are ignored.
The following values are needed for each tree:
Field nameTree identifier

Data type
Number or
character

X
Y

NumberNumberDescription
Identifier for the tree. The identifier can be a numberof a label. If the tree identifier is a number andnegative, the tree crown is drawn in LDV using acylinder with a rounded top. If the tree identifier is anumber and positive, the tree crown is drawn using aparaboloid (rounded cone). All trees with character
identifiers are drawn using a paraboloid.
X coordinate for the tree.
Y coordinate for the tree.

173

Elevation

NumberHeightHeight to crownbase

NumberNumberMaximum crowndiameter

Number

Minimum crowndiameter

NumberCrown rotation

NumberRed (optional)

NumberGreen (optional)

NumberBlue (optional)

Number

DBH (optional)

Number

Lean angle(optional)
LeanAzimuth(optional)
Status code
(optional)

NumberNumberNumberElevation at the tree base. If this is 0.0, the elevation
will be adjusted in FUSION using the current terrain
model.
Total tree height.
Height to the crown base. Definition of the crownbase varies depending on the application and field
protocols.
Maximum crown diameter. If the maximum andminimum crown diameters are 0.0, crown diameter
will be estimated as 16% if the total tree height.
Minimum crown diameter. If the maximum andminimum crown diameters are 0.0, crown diameter
will be estimated as 16% if the total tree height.
Rotation of the crown (degrees azimuth) used toproperly orient elliptical crowns. If crowns are
circular, the rotation should be 0.0.
Red color component for the color used to represent
the tree crown in LDV.
Green color component for the color used torepresent the tree crown in LDV.
Blue color component for the color used to represent
the tree crown in LDV.
Stem diameter in the same horizontal units as yourlidar data.
Lean angle in degrees form the ground to the top of
the tree.
Direction of lean (degrees azimuth).
Status code. This can be used in any way you want.
The individual tree adjustment dialog provides for
assigning values from 0-4 but other values can be
used.

ExampleThe following is an example tree file without color data for individual trees:
ID,X,Y,Elev,Height,Ht To Crown Base,Max Crown Dia,Min Crown Dia,Crown Rotation
1,976311.380200,566629.267600,0.000000,174.016312,0.000000,55.883287,55.883287,0.000000
2,976347.328300,566651.065800,0.000000,172.034225,83.689568,41.537985,41.537985,0.000000-3,977218.112900,567075.240000,0.000000,172.856262,102.127383,46.984066,46.984066,0.000000
4,976410.159500,567050.810000,0.000000,165.341171,74.987727,45.400783,45.400783,0.000000
5,976255.164700,566605.805300,0.000000,170.129089,0.000000,49.816029,49.816029,0.000000

Notice that negative identifier in the third record will cause the crown for this tree to be
draw using a rounded-top cylinder. All other tree crowns will be drawn as paraboloids.
The following is an example tree file with color information for each tree:
ID,X,Y,Elev,Height,Ht To Crown Base,Max Crown Dia,Min Crown Dia,Crown Rotation,Red,Green,Blue174

1,976311.380200,566629.267600,0.000000,174.016312,0.000000,55.883287,55.883287,0.0,0,255,0
2,976347.328300,566651.065800,0.000000,172.034225,83.689568,41.537985,41.537985,0.0,0,255,0
3,977218.112900,567075.240000,0.000000,172.856262,102.127383,46.984066,46.984066,0.0,255,0,0
4,976410.159500,567050.810000,0.000000,165.341171,74.987727,45.400783,45.400783,0.0,0,255,0
5,976255.164700,566605.805300,0.000000,170.129089,0.000000,49.816029,49.816029,0.0,0,255,0

In this example, the tree represented by the third record will be drawn with a red crown
and all other trees will be drawn with green crowns.
The following is an example tree file with all recognized fields and a record for the plot
location:
Tree ID,X,Y,Elevation,Total Height,Height To Crown Base,Max Crown Diameter,Min Crown
Diameter,Crown Rotation,Red,Green,Blue,DBH,Lean Angle,Lean Azimuth,Status
13_1_TSHE,418622.0591,5276669.7,0,39.127245,15.650898,6.260359,6.260359,0,0,192,0,0.498,0,0,0
13_2_TSHE,418631.1518,5276663.804,0,36.323401,14.52936,5.811744,5.811744,0,0,192,0,0.442,0,0,0
13_3_TSHE,418630.5203,5276660.029,0,30.068348,12.027339,4.810936,4.810936,0,0,192,0,0.333,0,0,0
13_4_PSME,418625.654,5276651.298,0,41.938412,16.775365,6.710146,6.710146,0,0,192,0,0.607,0,0,1
13_5_PSME,418626.9323,5276646.113,0,35.911324,14.36453,5.745812,5.745812,0,0,192,0,0.483,0,0,0
13_6_TSHE,418622.2937,5276637.798,0,38.643853,15.457541,6.183016,6.183016,0,0,192,0,0.488,0,0,0
13_7_TSHE,418615.2421,5276643.007,0,38.838069,15.535228,6.214091,6.214091,0,0,192,0,0.492,0,0,0
13_8_TSHE,418607.9874,5276645.378,0,36.42778,14.571112,5.828445,5.828445,0,0,192,0,0.444,0,0,0
13_9_TSHE,418608.157,5276654.089,0,35.955442,14.382177,5.752871,5.752871,0,0,192,0,0.435,0,0,0
13_10_TSHE,418609.761,5276659.748,0,42.454269,16.981707,6.792683,6.792683,0,0,192,0,0.571,0,0,1
13_11_TSHE,418605.1795,5276660.045,0,17.608087,7.043235,2.817294,2.817294,0,0,192,0,0.168,0,0,0
13_12_TSHE,418605.2787,5276660.296,0,29.042144,11.616858,4.646743,4.646743,0,0,192,0,0.317,0,0,0
13_13_TSHE,418609.8553,5276664.633,0,23.533674,9.41347,3.765388,3.765388,0,0,192,0,0.239,0,0,0
13_14_TSHE,418612.5483,5276665.019,0,41.082741,16.433096,6.573239,6.573239,0,0,192,0,0.54,0,0,1
13_15_TSHE,418621.6667,5276663.978,0,39.366285,15.746514,6.298606,6.298606,0,0,192,0,0.503,0,0,1
13_16_TSHE,418625.584,5276656.887,0,42.280518,16.912207,6.764883,6.764883,0,0,192,0,0.567,0,0,1
13_17_TSHE,418624.5325,5276645.307,0,38.103734,15.241493,6.096597,6.096597,0,0,192,0,0.477,0,0,0
13_18_PSME,418617.059,5276645.454,0,33.672104,13.468841,5.387537,5.387537,0,0,192,0,0.441,0,0,0
13_19_TSHE,418612.2483,5276652.368,0,41.531526,16.61261,6.645044,6.645044,0,0,192,0,0.55,0,0,1
13_20_TSHE,418614.2225,5276657.881,0,33.543298,13.417319,5.366928,5.366928,0,0,192,0,0.391,0,0,0
13_21_TSHE,418619.2184,5276654.907,0,9.21649,3.686596,1.474638,1.474638,0,0,192,0,0.085,0,0,0
13_22_TSHE,418619.65,5276654.49,0,42.062013,16.824805,6.729922,6.729922,0,0,192,0,0.562,0,0,1
PLOT_CENTER,418619.65,5276654.49,0,1,1,0.5,0.5,0,0,0,0,2,0,0,0

Note that the line with column labels should be a single line in the tree file. The line has
been split into two lines for use in the manual. All trees in this file will be drawn in green.
These records use status codes of 0 and 1. The tree marker (ball at the top of the tree)
will be colored according to the status code values. For this example, the plot center
corresponds to the tree labeled 13_22_TSHE so the coordinate for the PLOT_CENTER
record is the same as the location for this tree.

175

ASCII LIDAR Data File Formats
FUSION can process a variety of ASCII file formats to convert them to its own LDA
format and create the index files to allow rapid random access. In addition, theXYZConvert command line utility also converts data in specific formats to FUSION’s
LDA format. The formats listed below are formats that we have encountered in data setsfrom several vendors. Additional formats may be added in the future. FUSION alsooffers a generic ASCII data parser that allows you to define the format on the fly andsave the format definition for later use both within FUSION and using the ASCIIImportutility. Use of the generic ASCII data parser is preferred over one of the fixed format
conversion options. However, some formats cannot be parsed correctly by the genericparser. Namely, formats that included duplication of returns with one return coded as
return # of # and the duplicate coded to indicate that the return was also identified as abare-earth return.
ASCII file conversion functions are accessed using the “Utilities” button and the“Convert ASCII file to binary LDA” button.
All ASCII formats consist of one record per return with data fields separated bycommas, spaces, or tabs. In general, the separator doesn’t matter even if the format
description indicates that a specific character is used to separate data values. All lines
in a data file that start with “#” or “;” are considered comments and ignored.

Simple ASCII XYZ (format 0)
Each record contains X, Y, elevation, [scan angle]. The scan angle is optional (see the“Convert and index XYZ files” dialog, “Read scan/nadir angle from fourth column”
checkbox).

Terrapoint data (format 1)
Each record contains GPS time, return number, Y, X, elevation, aircraft X, aircraft Y,
aircraft elevation, and intensity.

AeroTec 1999 ASCII (format 2)
Each record contains pulse number, return number, X, Y, elevation, scan angle, andintensity separated by spaces

AeroTec 1998 ASCII (format 3)
Each record contains pulse number, Y, X, and elevation separated by spaces.

Aeromap CXYZI (format 4)
Each record contains return number, X, Y, elevation, and intensity separated bycommas.

Aeromap XYZI (format 5) and Cyrax XYZI (format 6)
Each record contains X, Y, elevation, and intensity separated by commas.

176

Aeromap Kenai project (format 7)
Each record contains GPS time, X, Y, elevation, return number, intensity, nadir angle,
and roll angle separated by commas.

Aeromap Kenai final ALL RETURNS (format 8)
Each record contains the GPS time, X, Y, Z, planeX, planeY, planeZ, class (return),
intensity, scan angle, and a bare earth flag separated by commas. This format also
includes a 14 line header that is ignored during the conversion process.

Aeromap Kenai final GROUND POINTS ONLY (format 9)Each record contains the GPS time, X, Y, Z, planeX, planeY, planeZ, class (return),
intensity, scan angle, and a bare earth flag separated by commas. Only points with thebare earth flag set to 1 are converted. This format also includes a 14 line header that is
ignored during the conversion process.

Aeromap Kenai final FIRST RETURNS ONLY (format 10)
Each record contains the GPS time, X, Y, Z, planeX, planeY, planeZ, class (return),
intensity, scan angle, and a bare earth flag separated by commas. Only points withclass set to 1 are converted. This format also includes a 14 line header that is ignored
during the conversion process.

Aeromap Kenai final LAST RETURNS ONLY (format 11)
Each record contains the GPS time, X, Y, Z, planeX, planeY, planeZ, class (return),
intensity, scan angle, and a bare earth flag separated by commas. Only points that are
the last return for the pulse are converted. Special logic is used to compare GPS times
for returns and the class value to determine which return is the last return. This format
also includes a 14 line header that is ignored during the conversion process.

Aeromap UW campus (format 12)
Each record contains the GPS time, X, Y, Z, return number, and intensity separated bycommas. For these data, only returns 1 through 3 are valid returns. Return number 4
indicates that the return is a last return and it may or may be a duplicate of one of theother returns for the pulse. Return number 5 indicates that the return is a bare-earth
point and is always a duplicate of one of the other returns.

Aeromap UW campus GROUND RETURNS ONLY3 (format 13)
Each record contains the GPS time, X, Y, Z, return number, and intensity separated bycommas. Using this format in XYZConvert produces files that contain only the returns
classified as bare-earth returns. For these data, only returns 1 through 3 are valid
returns. Return number 4 indicates that the return is a last return and it may or may be a
duplicate of one of the other returns for the pulse. Return number 5 indicates that thereturn is a bare-earth point and is always a duplicate of one of the other returns.

3 These format are only available in XYZConvert.

177

Puget Sound LIDAR Consortium 2003 data from Terrapoint3 (format 14)
Each record contains the GPS week, GPS second, X, Y, Z, # returns for pulse, Return#, Off-nadir angle, Intensity, and Return classification separated by commas.
Interpretation of the Return number is as follows:
Return number
in data
1-4
5

6
7
8

Interpretation
The return is return 1, 2, 3, or 4.
The return was a first return and also thelast return for the pulse (only one return
was recorded for the pulse).
The return was the second return andalso the last return for the pulse.
The return was the third return and also
the last return for the pulse.
The return was the fourth return and also
the last return for the pulse.

Return classification values are as follows:
ReturnInterpretation
classification
B
Blunder (the returns should be ignored formust processing).
G
The return is a bare-earth return.
V
The return represents vegetation.
S
The return represents a structure.

Puget Sound LIDAR Consortium 2003 data from Terrapoint LAST RETURNSONLY3 (format 15)
Each record contains the GPS week, GPS second, X, Y, Z, # returns for pulse, Return#, Off-nadir angle, Intensity, and Return classification separated by commas. Using thisformat in XYZConvert produces files that contain only the last returns recorded for eachpulse. Interpretation of the Return number and Return classification are the same as forthe previous format.

Terrapoint data for Fort Lewis, WA3 (format 16)
Each record contains the Return name, X, Y, Elevation, and Intensity separated bycommas.

Spectrum Mapping data for King County, WA3 (format 17)
Each record contains the X, Y, Z, Return number, and Number of returns for the pulse
separated by commas.

178

PSLC 2004 data for Pierce County, WA (format 18)
Each record contains the GPS week, GPS second, X, Y, Z, Ellipsoid Ht, Nadir angle,
and Return number separated by spaces.

PSLC 2000 data for Tiger Mountain area, WA (format 19)
Each record contains the X, Y, Z, Ell ipsoid ht, GPStime, Return #, Scan angle, ABS
scan angle, and GPS week separated by commas.

179

Appendix B: DOS Batch Programming and the FUSION
LIDAR Toolkit

180Batch Programming Overview
In MS-DOS and Windows, a batch file is a text file containing a series of commands
intended to be executed by the command interpreter. When a batch file is run, the shell
program (usually COMMAND.COM or cmd.exe) reads the file and executes its
commands, normally line-by-line. A batch file is analogous to a shell script in Unix-like
operating systems.
Batch files are useful for running a series of executables automatically. Many systemadministrators use them to automate tedious processes. Although batch files support
elementary program flow commands such as IF and GOTO, they are not well-suited forgeneral-purpose programming.
DOS batch files have the filename extension .BAT and are normally executed from acommand prompt window. To launch a command prompt window in windows 7, go to“Start”, “Programs”, “Accessories” and select “Command Prompt”. In windows 10, click“Start”, “Windows system” and select “Command prompt”. For windows 10, you canalso right-click on “Start”, select Run…” and type “CMD” followed by [Enter]. Finally, you
can navigate to the \windows\system32 folder and double click cmd.exe to launch acommand window.
Once the command prompt window is running, you can use DOS commands tomanually accomplish various tasks. Use the HELP command to get help for DOS
commands. To run a batch file from a command prompt, simply type the name of thebatch file (with or without the .BAT extension).

Getting help with batch programming commands
All versions of Windows
Open a command prompt window and type “help” followed by pressing [Enter]. This will
display a list of all available batch file commands. You can also get information for
specific commands by typing “help” followed by the command name.

Windows XP
Go to "Start", then "Help and Support", then under the Pick a Task" section, select the"Tools" link. At the very bottom of the Tools list, you'll find three entries that will help youwith your command-line batch questions. The best thing there is the "Command-linereference A-Z".
If you have an OEM version of Windows (Like Dell, where they replaced the Help
section with something else), you may need to read the XP Command-line reference AZ on the web.

Windows 2000
Go to "Start", then "Help", then click the “Contents” tab, then "Reference", then "MSDOS Commands".

181

Windows 7, 8, and 10
It seems that Microsoft has removed most references for DOS commands so you will
have to search on the web to find information.

Using the FUSION Command Line Tools
The FUSION command line tools are used from a command prompt. The commandprompt provides a low-level interface to your computer system. The command prompt inWindows 2000 and newer versions is similar to a DOS prompt. FUSION commands canbe run from any folder by typing the full path to the program. This means you have toknow the install directory for FUSION and type its folder name before the command
name. For example to run the FUSION Catalog program, you would type the following:
c:\fusion_install\catalog
If the FUSION install folder name includes spaces, you need to enclose the folder andprogram name in quotation marks like this:“c:\Program files\fusion\catalog”
Command line options go outside the quotation marks. Anytime you use a folder namethat includes spaces as part of a file specification on a command line, you need to
enclose the folder and file name in quotation marks.
Typing the full path is acceptable for a few commands but it is much easier to add the
FUSION install directory to the search path for your computer. Then you can type
FUSION commands from any folder on your computer without the install folder name.
This can be accomplished in a command prompt window or by modifying the systemproperties. From a command prompt, the following command adds the FUSION install
directory “C:\Program Files\FUSION” to the search path:
Path %PATH%;C:\Program Files\FUSION
This will only affect the open command prompt window so it needs to be repeated eachtime a command prompt window is opened. For a system wide change that will be ineffect whenever a command prompt is opened, you can modify the system properties
as described on the following web site (the exact steps will vary depending on youroperating system):https://helpdeskgeek.com/windows-10/add-windows-path-environment-variable/(last accessed August 2019)
You will need to edit the system variable named “path” and append a semi-colon andthe full folder name for the FUSION install directory (without the final “\”).

Automating Processing Tasks
Perhaps the easiest way to automate batch processing is through the use of the DOS
FOR statement to queue processing on a series of data files. To do this, you need tocreate two batch files and one list of files to process. The first batch file processes a

182

single data file and the second queues the processing of a series of data files by callingthe first batch file with different data file names. Development of the first batch file isrelatively straight forward in that it is just like the commands you type at the commandprompt. The only difference is that instead of typing a data file name, you use thecommand line substitution parameter, %1, to call the batch file to run with a file namepassed from the second batch file. The second batch file uses the DOS FOR command
and a separate text file that lists all of the data files to process.
To illustrate, let’s try an example where we want to filter ground points from a series ofdata files and create gridded surface models using the ground points. The list of files toprocess contains the names of each data file. Such a list can be generated using the
DOS DIR command as follows:
DIR /b *.las > filelist.txt
This command will produce a file named filelist.txt that contains all LAS data files in thecurrent folder. For more information on the DIR command, type HELP DIR at thecommand prompt. The list file will also contain the extension for each file. In somecases, you want to use only the data file name to construct the name of output files.
This can be accomplished two ways. First, you can edit the file list and delete theextensions from the file name. Second, you can use parameters in the DOS FOR
command to read the filename but omit the extension. This example uses the second
method. The list file should look something like this:DA75_LI080204.las
DA76E1_LI080204.las
DB72E1_LI080204.lasDB73_LI080204.lasDB76_LI080204.las
DC71A5_LI080204.lasDC71_LI080204.las
The first batch file, named process_tile.bat, processes an individual data file. Notice thatthe substitution variable, %1, has been used instead of explicit file names. This allows
us to pass the data file name from the second batch file to the first. Also notice that wehave to provide the extension for the data file (.las) as it will not be read from the list of
file names. Process_tile.bat contains the following commands:
groundfilter %1_ground_pts.las 3.5 %1.lasgridsurfacecreate %1_ground.dtm 1 m m 1 10 2 2 %1_ground_pts.las

The second batch file, named process.bat, reads the list of file names and calls the firstbatch file for each data file. Process.bat contains the following commands:

183

for /F "eol=; tokens=1* delims=,. " %%i in (filelist.txt) do call process_tile %%iIn the command above, notice that there is a space before the second quotation mark(after the first period). If the file names listed in filelist.txt contain spaces, the names will
not be parsed correctly and the process_tile.bat file will not function as expected.
To start the processing, make the directory containing the data files the current directoryand simply type process at the command prompt. All of the files listed in filelist.txt will beprocessed and the outputs stored in the current directory. If you want to use different
folders to better organize outputs, include the folder names in the file names specified
for outputs in process_tile.bat.

Mixing FUSION processing with other software packages
FUSION tools can be called from a variety of analysis tools including Python, R, andPERL. FUSION tools can even be called from within GIS environments allowing you to
conduct analyses and view outputs in a common environment. Such applications can bevery powerful but there are some cautions when calling tools from within GIS
environments. The biggest issue is that most GIS platforms, and tools like Excel, lock
files for read and write access when they are displayed on screen or included in aworkspace. This behavior will prevent other software, including FUSION tools, from
opening the files and can lead to errors or behaviors that are hard to track down. If you
are working in these environments, be sure that files you are using for your analyses
are not open in any other software package.

184

Appendix C: Using LTKProcessor to Process Data for Large
Acquisitions

185

Note: LTKProcessor is not the recommended method for processing
data covering large areas. Refer to the next appendix covering
AreaProcessor for the recommended method.
Overview
LTKProcessor is designed to facilitate the application of FUSION-LTK tools to large
data acquisitions. It uses multiple data files to create seamless data products covering
the entire acquisition area. In operation, LTKProcessor allows you to process data tiles
individually, clip new data tiles that optionally include a buffer around the tile, or overlay
an analysis grid over the entire acquisition extent. LTKProcessor does not actuallyprocess data. Instead, it creates a batch file that directs the processing. This batch filecan be run from within LTKProcessor or from a command prompt. While the batch file isrunning, additional programs (LTKStatusMessenger4 and LTKStatusMonitor) graphicallyshow the status of the processing job. The batch file produced by LTKProcessor ismodular and can be used to accomplish several processing tasks by simply replacing
the commands used to process each data tile or analysis grid cell. In addition, the batch
file includes simple error checking logic that can alert users when errors areencountered while processing specific data tiles. Users of LTKProcessor still have towrite batch files to process a single tile of data but they do not have to worry about thedetails of subdividing the point cloud into manageable data tiles or developing the batch
logic to direct the processing flow.
When processing data using batch files generated by LTKProcessor, LTKStatusMonitor
displays the status of all data tiles (Figure 10). Tiles are gray if they have not beenprocessed, yellow if they are currently being processed, green if processing ended
without errors, and red if processing ended with errors. You can click on a tile to display
its name at the bottom of the LTKStatusMonitor window. Once a tile is selected, you can
use the “Show tile status” button to display the processing log for the individual tile
(provided the option in LTKProcessor was checked to maintain log files for individual
tiles). In addition, the tile status dialog (Figure 11) shows the commands needed toreprocess a single tile or to restart the processing job beginning with the selected tile.
When an individual tile fails, you can reprocess the individual tile and then run the postprocessing commands.

Considerations for Processing Data from Large Acquisitions
LIDAR systems produce large quantities of data—even for relatively small project areas.
The sheer volume of the data makes it difficult to copy data sets and can lead toproblems when processing data to provide information products from the point clouds.
Limitations of computer operating systems can further complicate processing. The
following sections discuss some of the issues that should be considered when planningthe processing of data from LIDAR acquisitions. These discussions are based on
experience processing data from several acquisitions ranging in size from 30,000 to
250,000 acres and containing up to 20 billion points. For the most part, FUSION and the
4 The LTKStatusMessenger program was called LTKStatusUpdate in FUSION versions prior to 3.60. The

name was changed to allow the use of the program without administrator rights.

186

LTK toolkit are designed to operate with large data sets. However, careful planning canensure that processing is accomplished efficiently and reduce the chance for errors
related to file sizes or computer memory limitations.

Figure 10. The LTKStatusMonitor displays the status for large processing jobs.

Figure 11. The tile status dialog provides information for a specific tile and shows the commands
needed to reprocess a tile or restart a processing job that has been stopped.

Computer software and hardware conflicts
Some software con cause problems when processing data from large acquisitions.
Virus scanners typically prevent other programs from accessing files while they arescanning a file or folder. If you attempt to run a virus scan while processing data tiles,

187

some tiles may fail because they could not be read while the virus scan was active. If
you use a managed computer, you should schedule large processing jobs to avoid
times when your virus scanner is active.
If you have LIDAR data stored on network attached storage devices and other people orcomputers are working on the same files, access to a tile may be blocked. Most LTK
programs open files in read-only modes. However, other software may completely lockthe files so no other applications can access the files. For output files in CSV format,
you cannot have the file open in MS Excel while you are trying to read or write the file inany LTK program. This is a common problem when using CloudMetrics to compute
metrics for a series of files. The typical scenario is that you are experimenting with
options for CloudMetrics and then viewing the output (a CSV file) in Excel. You forget toclose the file in Excel and then run CloudMetrics and find that the file was not updated
and you get an error in CloudMetrics. The solution is to make sure that you don’t have
the CSV file open in Excel before running a tool that will write to the open file. This is not
a problem if you are using Notepad or Wordpad to view a file.

Pulse density and tile size
Pulse density (and therefore return density) is relatively uniform during a LIDAR
acquisition. The flight pattern, aircraft speed, and scanner setting are all adjusted toobtain a desired pulse density. However, when the final data are assembled, it is notuncommon to have areas with pulse densities higher or lower than planned. As data arepackaged for delivery, a tiling scheme is used to organize the data into blocks thatprovide a compromise between the size of each file and the number of files that must be
managed. For areas covered by “extra” flight lines, the pulse density within a single tile
may be double that of other tiles. Such areas result when a flight line is re-flown or whenlines perpendicular to the bulk of the lines are flown to assist in relative error
assessment and minimization. Processing workflows that are designed with the“normal” pulse density as an input may run into problems when they encounter a tile
with twice as many pulses.
FUSION and the LTK toolkit were designed using a simple philosophy. It was assumed
that all the points contained in a single file and needed for any analyses could be held inmemory for processing. While this basic assumption greatly simplified development
efforts, it does not necessarily result in the most efficient processing. In general, all of
the LTK tools can process at least 30 million data points in a single block on a computerwith 1Gb of available memory (available when the program is invoked not simply theamount of memory installed in the computer). However, some tools can handle morepoints. As a general rule, processing is much more efficient when the data for an
acquisition can be divided into as few tiles as possible. This is especially true when data
are read from external hard drives where the time required to read the data is asignificant portion of the overall processing time. Internal hard drives (or possibly
external drives using the eSATA interface) tend to be much faster when reading large
files. LTKProcessor provides several options to help “re-tile” data to make processing
more efficient. These options are discussed in Subdividing large datasets.

188

Tile buffering
The ideal processing situation is when all data for a project can be loaded into memory
and processed in a single step. However, almost all LIDAR acquisitions are simply toolarge to process in such a manner. Data are delivered in “tiles”. The size of each tile isusually a function of the point density but many projects simply subdivide standard 7.5minute quadrangles into a manageable number of tiles. While this approach produces
individual files that are generally smaller than 1 Gb, it presents special problems when
deriving information products that must span several tiles. Processing workflows thatprocess each tile independently often result in discontinuities along tile edges that
become problematic when adjacent tiles are combined. To overcome these problems
and produce information that is not affected by tiling arrangements, it is possible to add
a buffer around each tile, process the data, and then clip the resulting products using
the original tile boundary. In general the buffer is one or two “cells” wide and requiresthat return data from the eight tiles adjacent to each tile being processed are read.
Many of the LTK tools offer the option to use a buffer around the analysis area to makeprocessing results more consistent. LTKProcessor provides options to specify the buffer
size and to ensure that the tiling grid and buffer size is arranged to produce tiles that areexact multiples of the analysis cell size

Acquisition area arrangement (single area or multiple areas in 1 delivery)
When LIDAR acquisition contracts include more than one project area, special caremust be taken to make sure processing occurs for each of the areas independently. A
single data delivery may include data for multiple geographic areas separate by large
distances. Attempts to process all the data in one “pass” will result in output productsthat have large areas with invalid results since the outputs will be sized to an area
defined by the overall data extent. The easiest way to organize the data is to arrange
point files using a separate folder for each distinct project area. In addition,
LTKProcessor provides an option to view the input data tile arrangement. This option
allows you to make sure the data is geographically “connected”.

Available drive space
There is no denying that LIDAR acquisitions produce large data sets. Delivered data
totaling over 200 Gb are not uncommon. Most LIDAR data are delivered on external
hard drives as it is too time consuming to burn data to DVD or other media. As data areprocessed, additional storage space is required for intermediate and final products. As ageneral rule, you will need free storage space totally at least 25 percent of the spaceneeded for the point data alone.

Directory structure for processing and LTK outputs
Everyone has their own system for organizing files on their computer. FUSION and the
LTK toolkit do not expect or impose a directory (folder) structure. However, it is useful toconsider the organization before you start processing a data set. I have found that it
works well to have all of the data and processing outputs for a project stored in a single
folder at the root level of the storage drive. This folder should contain sub-folders to helporganize the data and outputs. This makes copying the data much easier and helps
ensure that batch files will work when the data are copied to a different drive. In
189

addition, I keep all batch files used for processing in a separate folder and all data
products in a separate folder with sub-folders as needed to keep things organized.
When developing batch files (scripts), I include as little of the directory path for input andoutput files in commands as possible and never include the drive letter in any
commands. For batch files, I assume that their execution will start in the folder
containing all of the batch files. If the current folder needs to be changed, the change ishandled by the batch files and the current folder is always set back to the folder that
contains all the batch files when processing is complete. The overall goal for the filearrangement is to have the data and processing relationships be independent of thedrive letter and the structure above the project folder.

Data storage device (internal versus external hard drive)
LIDAR data are typically delivered on external hard drives. While this media is very
convenient and low cost, it is usually not the best choice for processing. External drives
fail!! You should not rely on the drive delivered by the data provider as the only copy ofyour data. One simple strategy is to copy the data onto a second drive as soon as you
receive it and put the original drive in a safe place. Then copy the data onto a fast drive(either a fast external drive, network drive, or an internal drive) for processing. For tasks
that involve processing of all point data files, simply copying the data to an internal drive
and then processing from the internal drive can reduce processing times significantly.
As you develop batch files for processing data, you will find that a similar sequence ofcommands is used for each data acquisition—maybe even the same sequence. If you
are careful when developing your batch files, they can be used for different projects witha minimum of changes. I find it useful to make backup copies of all batch files (on adifferent drive than the data). This way if something happens to the drive containing thedata, I can quickly recover the data from the original hard drive (stored in a safe place),
copy the processing batch files, and start reprocessing the data. Ideally, backup copies
of derived layers should be made on a regular basis. At a minimum, creating backup
copies of the batch files allows you to easily (not necessarily quickly) recreate derived
layers.

Error detection and recovery
LTKProcessor and LTKStatusMonitor provide limited error detection. It is likely that thiscapability will be enhanced in future versions of LTKProcessor.
The master batch file created by LTKProcessor includes logic to detect errors while
processing individual tiles and LTKStatusMonitor will show the tiles affected by the error
in red. However, this logic will detect errors from the last process run for each tile. If you
include multiple commands in the tile batch file, only the return status from the lastcommand will be used to detect an error. To overcome this limitation, the LTKERROR
environment variable can be set to any non-zero value to indicate an error whenprocessing an individual tile. Upon return from the tile batch file, this variable is checkedin addition to the DOS ERRORLEVEL to see if any errors occurred. If multiplecommands are used in the tile batch file, you should set the LTKERROR variable toindicate an error using the following code fragment:190

rem command to do something
IF ERRORLEVEL set LTKERROR=1
rem command to do something
IF ERRORLEVEL set LTKERROR=1
For example, suppose we want to use GroundFilter to identify bare-ground returns in adata tile and then use GridSurfaceCreate to produce a gridded terrain model using thebare-ground points. The simple commands added to the tile batch file would look likethis:
GroundFilter parameters…
GridSurfaceCreate parameters…
If this sequence of commands were added to the tile processing batch file, the masterbatch file would only detect errors that occurred in GridSurfaceCreate. If GroundFilter
failed, the data tile would still be reported in LTKStatusMonitor as complete. To remedy
this problem we could insert use the following command sequence:
GroundFilter parameters…
IF ERRORLEVEL set LTKERROR=1
GridSurfaceCreate parameters…
IF ERRORLEVEL set LTKERROR=1
This would allow the master batch file to detect errors in both programs. However, it islikely that we don’t want to run GridSurfaceCreate if GroundFilter fails so the bestcommand sequence to use would look like this:GroundFilter parameters…
IF NOT ERRORLEVEL (GridSurfaceCreate parameters…
IF ERRORLEVEL set LTKERROR=1)
ELSE (
set LTKERROR=1)
This command sequence only runs GridSurfaceCreate if GroundFilter is successful andstill sets the LTKERROR variable to indicate that an error occurred just in case the tile
batch file contains other statements.

191

Subdividing large datasets
Point data from LIDAR acquisitions are typically delivered in several files. Files may beorganized by flight lines or using a rectangular grid that corresponds to some coordinate
system. For some projects, the arrangement of data files delivered by the LIDAR
provider is such that processing can use the original data files. However, when data aredelivered by flight line, data in portions of the swath that overlap are often in separate
files. Such an arrangement makes it difficult to carry out some processing tasks. For
example computing descriptive statistics for specific subsets of the point cloud may
require examination of the entire dataset to identify all files that contain points within thesubset area. This approach, while possible, is not computationally efficient. When data
area delivered in somewhat arbitrary tiles, the number of points in each tile will varydepending on the vegetation cover and the resulting returns per pulse. Some tiles may
be small enough to process in their entirety while other may have too many points toprocess using a single LTK command. At the other extreme, tiles may contain far fewer
points than can be processed using a single LTK command so several files must be
examined and combined, either into a new file or virtually in computer memory, toaccomplish the processing task. Additional complications arise when developing rasterlayers containing descriptive statistics. The tile edges may not correspond to the gridcells so an individual tile contains only a portion of the points for the cells around its
border. An obvious solution for this problem is to read data from the adjacent data tiles
to fill in the grid. However, when working with data stored on external hard drives, thetime to read a tile may be long enough that it would be preferable to read the data tiles
as few times as possible. Experience gleaned from processing data for large
acquisitions has revealed that processing times are the shortest when data areprocessed in large chunks. A second problem that arises when producing raster layers
from LIDAR point data is that attributes computed from the point cloud near the edge ofa tile may not match the attributes compute near the adjacent edge in a different tile.
This frequently happens when the tile dimensions are not an even multiple of the gridcell size. To eliminate the potential for edge effects in the final data layers, either thegrid cell size must be carefully selected so that there are no partial cells at the edge of adata tile or the data must be retiled using an arrangement that provides blocks of data
whose dimensions are even multiples of the grid cell size.
LTKProcessor provides several options for working with large datasets. In addition, it
can use a user-specified buffer around each tile to make sure adjacent tiles match along
their common edges. The processing arrangement options in LTKProcessor are:
• Process the data tiles as they were delivered from the data provider,• Overlay the area with an analysis grid made up of equal-size tiles and process
the data for each new tile in the analysis grid,• Use a raster data layer containing the number of returns per cell to compute a tile
size and arrangement and process the data for each new tile in the analysis grid,• Clip new data tiles using a specified tile size,• Clip new data tiles using a computed tile size based on the maximum number ofreturns and the nominal return density.

192

Each of the above options provides advantages and disadvantages but the option thatcomputes the processing tile size based on the return density usually results in the
shortest processing times and the fewest intermediate files.

Batch File for Pre-processing
The batch file for preprocessing is called just before individual tiles are processed. The
current directory is set the working directory and no parameters are passed to thepreprocessing batch file. At the time when the preprocessing batch file is called not datatiles have been clipped or processed. Typically this batch file is used to prepare for theoverall processing task. This may include creating output folders or clearing old files.
When the tile batch file is called, explicit path names are used for the parameters.
However, if the current directory is changed from the working directory in the
preprocessing batch file, some processing tasks may fail. If you need to work in a
directory other than the working directory, you should change back to the working
directory at the end of the preprocessing batch file.

Batch File for Processing Individual Data Tiles or Analysis Grid Cells
The batch file used to process each data tile does the work for LTKProcessor. This
batch file is used with each tile or analysis grid cell to do all processing for the tile. The
following parameters are passed to this batch file:Parameter
position
1
2
3
4
5
6
7
8
9
10
11
12
13

Description
Name of the buffered tile containing LIDAR data
Minimum X value for the unbuffered tile
Minimum Y value for the unbuffered tile
Maximum X value for the unbuffered tile
Maximum Y value for the unbuffered tile
Minimum X value for the buffered tile
Minimum Y value for the buffered tile
Maximum X value for the buffered tile
Maximum Y value for the buffered tile
Name of the text file containing a list of all data files
Buffer size
Width of the unbuffered analysis tile
Height of the unbuffered analysis tile

Batch files can only access the first 9 parameters directly so the tile batch file is divided
into two sections by a series of SHIFT commands. Prior to the SHIFT commands,
parameters 6, 7, 8, and 9 refer to the values described above. After the SHIFT
commands, they refer to the values originally in parameters 10, 11, 12, and 13. As you
edit the batch file for an individual tile, any commands that need to use the corners of
the buffered tile should be placed before the set of SHIFT commands. After the SHIFT
commands are executed, these corners will not be available in the batch file.

193

The file name passed to the batch (parameter 1) file looks like this:TILE_C00001_R00002_S00001. The row and column numbers specify the tile locationand the subtile designation identifies the tile within an analysis grid cell when tile sizes
have been optimized. The origin of the row and column coordinate system is the lower
left corner of the data extent.
When developing this batch file, only commands that are needed for each data tile
should be included. This batch file will be called for each data tile so any extra
commands will slow the overall processing.

Batch File for Final Processing
The batch file for final processing is called after all tiles have been processed. If new
data tiles were clipped and saved, they will be available to this batch file. Outputs
created in the preprocessing batch file and the tile processing batch file will also be
available. This batch file is typically used to combine outputs produced for each data tileand to convert the combined output into formats more useful to non-LTK applications.
The final processing batch file can change the current directory if needed and does notneed to change it back to the working directory.

Example Batch Files
The FUSION distribution includes example batch files for pre-processing, tile
processing, and final processing. The examples present one way to approachprocessing for large acquisitions and are intended to help users get started using
LTKProcessor. Use of LTKProcessor is required to create the over-arching runstreamthat calls the example batch files. Output from the example processing batch files
includes a set of raster data layers containing elevation, intensity, and topographic
metrics for point data. Additional outputs can include canopy surface and height models,
metrics computed from the canopy height model, and metrics computed for various
height strata. The example processing requires a bare-earth surface model in FUSION’s
DTM format, point files, and a return density raster layer (created by the
RUNQAQC.BAT batch file). It is possible to modify the TILE.BAT file to create a bareearth surface model for each processing tile but this is not the ideal processing flow
since processing tiles can vary in size and the resulting bare-earth surface model may
not work well for all processing tasks.
The pre-processing batch file is named SETUP.BAT. It includes environment variable
definitions that specify parameters to control most processing tasks and commands tocreate a directory structure for FUSION outputs. Variables are included that control
creation of canopy surface and canopy height models and whether or not metrics arecomputed for elevation/height strata. Typical modifications to SETUP.BAT to customize
it for a specific situation include changing the HOMEFOLDER, DTMSPEC, UNITS,CELLSIZE, LATITUDE, HTCUTOFF, COVERCUTOFF, COORDINFO, and OUTLIER
variables. You can control computation of the canopy surface and strata metrics bychanging the DOCANOPY and DOSTRATA variables. The
CANOPYSTATSFILEIDENTIFIER variable must be changed to reflect the cell size forthe canopy surface metrics.
194

The tile processing batch file, named TILE.BAT, creates canopy height and surface
models for each analysis tile and computes metrics for the point data. It uses the
CanopyModel, GridSurfaceStats, ClipDtm, and GridMetrics programs with parametersspecified in SETUP.BAT. The example file assumes that bare-earth surface models
already exist and have been converted in to FUSION’s DTM format. If this is not thecase, you can use a call to GroundFilter to identify bare-earth points and then call
GridSurfaceCreate to create a surface file. You will also need to change commands that
use the bare-earth surface model (CanopyModel and GridMetrics).
The post-processing batch file, named BUILDLAYERS.BAT, extracts individual pointcloud metrics from the GridMetrics outputs and merges the results for all analysis tiles
into a single raster layer for each metric. In addition, this batch file merges canopy
height and surface models and canopy metrics into individual raster layers. The
example BUILDLAYERS.BAT extracts all of the metrics computed by GridMetrics and
GridSurfaceStats. If you do not require all of the metrics, make changes to
BUILDLAYERS.BAT to extract only the metrics you require.
The RUNQAQC.BAT batch file is designed to be run before any LTKProcessor activity.
It creates a basic QA report for the data acquisition and, most importantly, creates areturn density raster layer that is used in LTKProcessor to compute the layout ofanalysis tiles for subsequent processing.

195

Appendix D: Building multi-processor workflows using
AreaProcessor

196

Overview
AreaProcessor, like LTKProcessor, is a tool that helps you create processing workflows
for your data. It does not necessarily replace LTKProcessor but it does offer better logic
to subdivide and area into processing tiles, more control over the arrangement of output
products, and support for multi-core processing. A companion tool,
LTKStatusMonitorMDI provides status monitoring for the workflows created by
AreaProcessor.
You should read the appendix covering LTKProcessor before you start using
AreaProcessor as most of the discussion applies to AreaProcessor.
AreaProcessor relies on a set of batch files to perform the actual configuration andprocessing for files containing point data (referred to as processing tiles). The basic
steps in a typical workflow include clipping and normalizing point data, computing
products for the processing tile, and checking for errors. Once all processing tiles havebeen completed, outputs are merged and converted into GIS-ready formats. The
example set of batch files included in the FUSION distribution produces the following
products:• First-return metrics (elevation and intensity)• All-return metrics (elevation and intensity)• Metrics by height strata (all returns)• Metrics by height strata (first returns)• Canopy height models• Intensity images• Bare-ground surface models (optional)• Topographic metrics
While I generally use AreaProcesor to produce product sets similar to those listed
above, the tool is extremely flexible and can be used to create workflows that
accomplish a wide variety of processing tasks.
The AreaProcessor dialog, shown in Figure 12, includes options to specify information
required for a run and information that may or may not be required depending on theprocessing options and tools used. The dialog also shows information summarizing thepoint data and the processing layout. All parameters used to configure a processing run
can be saved and recalled for later use. AreaProcessor provides extensive error
checking for all input parameters and the option to create the actual workflow (batch
files) are not enabled until the inputs are free of errors or inconsistencies.

197

Figure 12. The AreaProcessor main dialog.

Most of the discussion in this appendix assumes you are using the example processing
scripts included in the FUSION distribution. This will provide an introduction to thecapabilities of the tool and hopefully encourage users to explore the capabilities of thetool and adapt it to their specific needs by modifying or creating their own processing
scripts.

Configuring AreaProcessor on your computer
AreaProcessor relies on a set of batch files to do the actual processing. In a normal
installation of FUSION these batch files are located in the APScripts folder in the main
FUSION install folder. However, these batch files can be relocated to any folder of yourchoosing. The only constraint is that you should keep all of the batch files together, i.e.,
don’t split them between several folders.
The scripts distributed with FUSION use parts of the Geospatial Data Abstraction
Library5 (GDAL). Specifically, GDAL_translate is used by the AreaProcessor scripts toconvert outputs to Erdas Imagine format. If you are not using the example scripts, you
may be able to skip this configuration. However, if you use any of the accessory scripts
to convert files from one format to another, you should make the changes to reflect thecorrect location for GDAL. Because there are different ways to install GDAL, you must
modify a batch file to point to GDAL_translate. This batch file, named GDALconfig.bat,is in the APScripts\ComputerSpecific folder. You will need to change the path to the
GDAL_translate utility and the GDAL-data folder to match your GDAL installation. The
5 http://www.gdal.org (last accessed August 2019)198

following lines from the GDALconfig.bat file show the path for a typical stand-alone
installation of GDAL.:
set GDAL_TRANSLATE_LOCATION=C:\Program Files\GDAL\gdal_translate
set GDAL_DATA=C:\Program Files\GDAL\gdal-data
If you update your installation of FUSION you should turn off the option to installcomputer-specific configuration information in the installer to preserve your changes to
the GDALconfig.bat file.

Preparing data for AreaProcessor
As with other FUSION tools, there is some preparation needed before you can processdata using AreaProcessor. If ground surface models were provided as part of theacquisition, they will need to be converted into FUSION’s DTM format. If you areplanning to create the ground surfaces as part of the processing this task is not needed.
Depending on the options used in AreaProcessor to develop the processing tile layout,
you may need to create a return density raster layer. This can be done using theCatalog utility with the /density option or with the ReturnDensity tool. In general,
ReturnDensity is faster but if you are using Catalog to do a quality check of your data,
the added time to create the return density layer is minimal. Refer to Appendix F: Using
AreaProcessor to produce return density raster layers for example that builds return
density layers using a workflow generated by AreaProcessor. If you use another, nonFUSION tool to create the return density layer, you may need to convert it into
FUSION’s DTM format.
The sample processing batch files include the calculation of several topographic metrics
using ground surfaces. Some of these metrics (e.g. topographic position index) lookbeyond the edges of the acquisition to compute values for areas within the acquisition.
You can provide a secondary, or “background”, ground surface model that coves thearea outside the acquisition boundary. Such a surface will generally be lower resolution
compared to the LIDAR-derived surfaces but will still provide surface data to make themetrics reasonably valid within the acquisition boundary. The logic in all of the FUSION
tools will use elevations from the highest-resolution source provided and will only use
the “background” surface values when there are no other elevation sources covering apoint location.
Point data delivered in either LAS or LAZ format is generally ready for processing. If you
have data delivered in individual flight lines, you may want to retile the data to makeprocessing more efficient. Data for entire flight lines typically has a very large extent but
only a small area within the extent actually contains data. As the workflow clips data forprocessing, the large extent results in testing of every point in the flight line to see if it iswithin the new processing tile extent. By retiling the data, only points within the tiles thatoverlap the processing tile extent need to be considered. Refer to Appendix E: Retilingpoint data using AreaProcessor for a sample retiling procedure.

199

For large acquisitions with several thousand delivery tiles, you can increase processing
efficiency for multi-core runs by separating the delivery tiles onto different physicaldrives. This helps prevent disk I/O from being the bottleneck in processing especially if
drives are connected to different USB ports (instead of sharing the same port through a
USB hub. If you have a solid state drive on your computer, you can also move thedelivery data onto this drive to further increase processing efficiency. Finally, you canhelp balance the I/O load on your computer if you specify a different drive for outputs
than the drive containing your data,
If you are using vendor-supplied ground surfaces, you may want to subdivide the files
into smaller pieces. Processing efficiency can be increased substantially by splitting
large ground surfaces into smaller, more manageable tiles. FUSION provides theSplitDTM tool to do the splitting. Smaller tiles allow all of the FUSION tools to better
manage loading of ground surface used when normalizing point elevations. IN general,ground tiles with 125,000 cells or less provide a good balance between the number oftiles and the overall processing efficiency.

Processing tile and block strategies
The basic strategy when deciding on tile and block sizes is that you want the number ofreturns in each tile to be such that all of the FUSION tools that you are using forprocessing will operate on the tile. In addition, you want block outputs to be smallenough to work in other, non-FUSION analysis tools. Most FUSION tools will work withat least 60,000,000 returns. The IntensityImage program is the most restrictive but itshould still work with 60,000,000 returns unless you are producing very high resolution(pixels less than 1m) images. If you need to produce such images, drop the target
number of returns to 40,000,000. For blocks, you want the output raster data layers
sized so they will work in other analysis tools. In general, I find that raster outputs
smaller than 30,000 by 30,000 cells will work in most other tools. When considering theblock sizes you also want to have enough blocks to take advantage of the computing
capability of your computer. You want to have at least as many blocks as you havecores that you want to allocate to processing. In general, I find it convenient to use thesame size blocks across different acquisitions (and to force the block origin to be amultiple of the block size). This way data products from adjacent acquisitions will align.
The logic used to determine the processing order for blocks looks at the size of theindividual blocks (actual area within the block extent that contains point data) andqueues the largest blocks first. The starting order for “complete” blocks, i.e. thosecompletely covered by return data, is randomized in an attempt to prevent having blocks
that share the same delivery tiles from running concurrently. After the “complete” blocks,
the remaining blocks are ordered by the amount of area within the block covered bypoint data. In general, processing will seem to go slower at the beginning of a run andthen speed up as the “complete” blocks are finished.
If you specify a block size that is a multiple of the desired tile size, the processing layout
will be slightly more efficient because there will be fewer “slivers” near the edges of theblocks. In general, processing will be faster for layouts with fewer tiles so it is often

200

worthwhile to try different combinations of tile and block sizes (without changing thedesired maximum number of returns per tile) to see if you can find a combination that
produces the fewest tiles. The logic used to compute the tile layout includes anoptimization component but it is based on the specified tile size so trying different tile
sizes might lead to a better solution.

Processing batch files
The set of batch files provided as part of the FUSION installation provide an example ofwhat you can do with AreaProcessor. The batch files generated by AreaProcessor callthe batch files that the user specifies to do most of the actual work involved inprocessing. While these processing batch files are somewhat complicated, you can
modify them to further customize processing options or add new products. Figure 13
shows the processing script dialog with the batch files for a typical processing run.

Figure 13. Processing script dialog showing the batch files used for a typical processing run
using AreaProcessor.

The basic structure of the processing flow is that you have batch files to accomplish thefollowing tasks:• Provide basic configuration information (basic_setup.bat)• Perform any actions needed before block processing is started (preblock.bat)• Process a single block of return data (tile.bat)• Deal with results for each processing block (merge tile outputs, convert formats,
move products to the final output folders) (posttile.bat)• Perform any actions needed after all blocks have been processed (final merging
of outputs, convert format, move products to the final output folders)(postblock.bat)
201

If you just want to produce the “standard” set of FUSION metrics using 30 m cells, youreally don’t need to change any of the batch files. If you want to add or remove some ofthe outputs, you can do this at the beginning of the basic_setup.bat file in the section
labeled “Overall options to compute metrics”. In this section you turn options on (besetting them to TRUE) or off (by setting them to FALSE) to control the outputs produced
during a run. These changes are easy to make. However, if you want to change the cell
sizes, you will need to make several changes in the basic_setup.bat file. The cell size
specified in AreaProcessor is used to align all of the processing tiles and blocks. It
should always be the same as the cell size specified in the basic_setup.bat file.
Normally, this is the cell size used for GridMetrics. The cell sizes for all other products(canopy surfaces, intensity images, ground surfaces and topographic metrics) should
divide evenly into the cell size specified in AreaProcessor. Failure to do this will result inproblems when the posttile.bat and postblock.bat files attempt to merge outputs.
For data using imperial units, I have used the conversion of 1 meter = 3.2808 feet when
computing cell sizes. I realize that this isn’t an exact conversion and it makes it hard towork between U.S. survey feet and international feet but this conversion provides alevel of precision that is “computer friendly” when you are storing data in ASCII text
format with limited decimal precision. You can do more precise conversions and include
more decimal digits but doing so will likely result in alignment problems when adjacent
blocks of data are merged.

Configuring the run for multiple processors
The most significant feature of AreaProcessor is its ability to generate workflows thatrun on several processors/cores. To accomplish this, AreaProcessor takes advantage offeatures in the Windows operating system that attempt to balance the load on the cores.
AreaProcessor creates separate batch files for each processing block and then queues
these batch files in a way that allows Windows to assign them to the least busy
processor. The net effect is that block processing occurs in parallel thereby making
processing much more efficient.
Users can control the number of cores used for a job by specifying the number ofprocessing streams in the processing options. Blocks are assigned to processing
streams based on the area within the block that actually contains data in an attempt tobalance the time needed to complete each processing stream. In addition, allprocessing streams contain logic that monitors the status of the entire processing job sothey can launch post-processing tasks after all block processing is complete.
Specifying too many cores can effectively swamp the computer making it unusable forany other tasks while the AreaProcessor scripts are running. In general, I have foundthat leaving 2-3 cores for the other tasks produces reasonably efficient processing whilestill allowing the computer to be used for other tasks. When determining the number ofprocessing streams, you also should consider the amount of memory on your computerand specify a number of processing streams so each stream has at least 2 Gb ofmemory available for use.

202

What to do when something goes wrong
The logic used to check for errors is written into the batch files created by
AreaProcessor. This logic is identical to the logic inserted by LTKProcessor so you canrefer to Appendix C: Using LTKProcessor to Process Data for Large Acquisitions fordetails. When an error is detected, the processing tile is highlighted in red on the
LTKStatusMonitorMDI display. You can view the processing log and determine thecause of the error. To do this simply click on the tile shown in red and then select the
button labeled “Show tile status” in the lower right corner of the status display. This
brings up the dialog shown in Figure 14. At the bottom of the dialog you can view theprocessing log for the tile. If you scroll to the end of the log, you might be able todetermine the cause of the error. If the error is related to a DOS command or nonFUSION software, it may be harder to find the cause of the error.

Figure 14. Status information for a processing tile displayed in LTKStatusMonitorMDI.

The most common error during a processing run occurs when a processing tile doesn’t
contain any point data. This happens most often around the edges of the data coveragewhen the return density layer used to compute the processing tile layout is of low
resolution. Basically, the cells in the return density layer indicate that there are points
within the tile extent but, in reality, there are no points in the cell that are within theextent. These error can be ignored and they will not affect the final outputs. The second
most common error, and the most difficult to recover from, occurs when your computeris restarted during a processing run. When this happens, you can manually run the
LTKStatusMonitorMDI program and load the primary batch file. This should show you
the status of the processing job when the computer was restarted. It is possible torestart all of the processing steams but things get complicated when there were203

processing tiles being clipped when the computer restarted. This leaves behind corrupt
point files that will need to be deleted manually before restarting any processing. Thesefiles will be located in the same folder as the primary batch file. Given the difficulty andcomplexity of restarting a job that was interrupted by a system restart, it is often betterto just restart the entire job by running the primary batch file again.
The dialog shown in Figure 14 also provides command lines that can be used to correcta tile that had errors of restart a processing job. Each of these command lines should be
run in the folder containing the master batch file for the processing run. If you find thesource of an error associated with an individual tile and can correct the error, you canreprocess the tile using the command at the top of the dialog. You can copy thiscommand from the dialog and paste it into a command prompt window to start theprocessing. You would use this first command if there are several tile that had errors
running (run the reprocessing command for each tile). The second command in the
dialog restarts processing with a specific tile and then runs all post-tile and post-block
scripts. You would use this command to restart the processing if you only had one tile
with an error. The third command runs to post-tile processing script for the processing
block. The fourth command runs the post-processing for the processing stream. The
fifth command runs the post-block processing script for the entire area.
When errors occur but processing ran to completion, you need to reprocess each of thetiles that had errors using the first command. Then run the post-processing (thirdcommand) for each of the blocks that had tiles with error. Once all block postprocessing is complete, you can use the fourth command to run post-processing for theprocessing stream. Finally, once all post-processing is done for the streams you can
use the fifth command to run the final post-processing for the entire area.
If you are monitoring the processing and notice that an error occurred in a single block,you can stop the associated processing stream and use the second command to restart
the processing for the block. In this case, all of the post-processing tasks will be
automatically run as blocks and processing streams finish.

204

Appendix E: Retiling point data using AreaProcessor

205

Using AreaProcessor to retile point files
There are situations where it is desirable to retile point data. For cases where points aredelivered in very large files, processing can be slow because clipping operations needto read the entire file. Point file indexing can be used to speed up clipping operations
but this results in a different point order data (at least this is true for FUSION but it may
be possible to sort the outputs back into the original order in LAStools). For cases
where points are delivered in separate files for each flight line, the rectangular extent for
the tile can make it appear that there is data covering a much larger area so tiles areread unnecessarily when performing clipping operations.
The options available in AreaProcessor allow you to create a tile layout where you havecontrol over the tile size and the tile origin. You can use the multi-processor capability insome situations to improve the performance when retiling. You can also clip tiles withbuffers (although a better approach is to clip tiles without buffers and then use thesetiles with AreaProcessor and specify a buffer around the temporary tiles it creates forprocessing). The only real “trick” when building a run stream to retile data is that the tile
processing batch file has nothing to do because the commands to clip new data tiles are
written into the batch files created by AreaProcessor. This does mean that you need touse a special tile processing batch file that doesn’t do any processing. In addition, thecell size doesn’t really matter so long as the tile size is a multiple of the cell size.
If you have data in large files or flight lines, the best strategy is to clip a new set of tiles
that are still fairly large and then use these tiles to clip a final set of smaller tiles. The
reason for the two-step process is that the time to clip a tile from large files is almost
independent of the new tile size. This means that clipping a small tile from a few verylarge files will take just as long as clipping a large tile. If you do the initial clip to create
set of new (still large) tiles and then use these tiles to clip small tiles, the small tile
clipping will go faster. In most circumstances, the total time to produce the small tiles
will be shorter compared to clipping the small tiles in a single pass.
For clipping tiles when you have a few very large files you generally want to use a single
run stream to avoid having multiple processes trying to simultaneously read from thesame file. For the processing scripts you need to specify the output folder, primarybatch file name, folder with secondary batch files, and the tile processing batch file (theone that doesn’t do anything). None of the other batch files are needed. Figure 15
shows an example of the processing scripts needed when retiling data when you havereturn density layer(s) available. If you don’t have return density layers, you would use
option 2 to compute the processing tile layout.

206

Figure 15. Example set of processing scripts used to retile point data.

For the processing options use values and options similar to those in Figure 16. You
can use either option 2 or 5 to create the tile layout. Use option 5 if you have return
density information and be sure to adjust the number of points to a large number(400,000,000 in this example) so tiles are not likely to be sub-divided. The advantage ofusing option 5 is that tiles that don’t contain any data will be eliminated. With option 2,
tiles will only be eliminated if they are not overlapped by a delivery tile. For manyacquisitions, you won’t see much difference between the tile arrangements using either
option. However, if you have point data organized into flight lines, the layout generatedusing option 2 may result in several tiles that are overlapped by the extent of a delivery
tile (flight line) but don’t actually contain any data points. The logic used when clipping
will still need to read all the points in any delivery tiles that overlap the tile being clipped.
The maximum number of returns in the tile is not used with tile option 2. With either
option, make sure you turn off the option to delete the newly clipped tiles after
processing. If you don’t do this, the newly clipped tiles will be deleted soon after they
are created. You can use a tile base name to help identify the newly clipped tiles. New
tile names will have the form BLOCK###_C#####_R#####.las. The “###” fields will be
replaced with values indicating arrangement of blocks and the columns and rows within
the blocks. If you use a tile base name, it will be prepended to the standard tile name.

207

Figure 16. Processing options used to clip an intermediate set of large tiles from point data.

You don’t need ground surfaces or a projection file when retiling point data. For theprocessing blocks, use a single block if you have only a few very large files or if yourfiles contain data for single flight lines. If you have several large files that do not overlap(at least they don’t have overlapping extents), you can use several processing streams.
Once you have run the job to clip the large tiles, you should move the large tiles out ofthe primary output folder or they will be overwritten and the clipping of smaller tiles will
fail. Alternatively, you can change the primary output folder for the run to clip the smaller
tiles or specify different tile base names for the large and small tiles.
For clipping the smaller tiles, the same processing scripts and output folder can be used(provided you have moved the larger tiles you just clipped to another folder). You will
want to change the processing options to change the tile size and number of processing
streams (see Figure 17 for an example). You will load the new large tiles clipped in theprevious run as the input return data for the newly clipped smaller tiles. You can use
multiple processing streams for the second clipping operation since the original large
point tiles have been split into tiles where the extent better represents the area
containing return data.

208

Figure 17. Processing options use to clip the final tiles from point data.

When creating the processing blocks for the final tiling operation, subdivide the area
using a block width and height that are multiples of the tile size. Once you havecomputed the tile arrangement, check the processing layout to verify that you are
getting tiles that make sense. If you are using return density layers, you shouldn’t havetiles outside the area covered by point data. If you are not using return density layers,
you may have new tiles that end up with no data. For these tiles, the status monitor willshow a red tile indicating that an error occurred. You can ignore these errors as they
simply indicate that there were no points clipped in the new tile.
Once you have run the job to clip the smaller tiles, you can move the smaller tiles totheir final location. The tile naming will again reflect the arrangement of processing
blocks. Unfortunately, there is no good strategy for renaming the tiles to reflect anoverall row/column reference grid for the entire data set.

209

Appendix F: Using AreaProcessor to produce return density
raster layers

210

To develop the most efficient layout of processing tiles, AreaProcessor uses a rasterdata layer describing the total number of returns in each cell. This layer can begenerated using the Catalog tool but, for large data sets, you must use a very large cellsize. This coarse resolution limits the algorithm used to computer the tile layout. The
following describes the steps and configuration needed to use AreaProcessor to createa workflow that builds return density layers. The workflow produces a set of highresolution tiles that can then be used to develop a processing workflow.
The basic strategy is to build a processing layout so that the return density layers are
created for each processing block without clipping new point tiles. To do this, theprocessing tiles and blocks will be the same size and you will use a tiling option that
simply overlays a grid on the data extent. The basic steps to create the workflow are:• Set the cell size on AreaProcessor’s main dialog (set to 50 m for this example)• Load all the point data files into the Return data
• Set the processing options as shown in Figure 18 (tile size may vary depending
on units and cell size). For this example, the final tiles will only be 500 by 500
cells. For a “real” configuration, try to specify a combination of the cell size andtile size to produce outputs smaller than 2500 by 2500 cells. Be sure to uncheckthe option to clip data tiles before processing.

Figure 18. Processing options used to create return density raster layers.

211

•

Set up the processing scripts as shown in Figure 19 (you don’t need a post-tile,
pre-block, or post-block script). A set of sample scripts to create return density
layers is included with the FUSION distribution. The sample scripts produce
outputs in FUSION’s DTM format for use with AreaProcessor. If you would prefer
outputs in Erdas IMAGINE format, edit the ReturnDensity_setup.bat file andchange “SET CONVERTTOIMG=FALSE” to “SET CONVERTTOIMG=TRUE”.
This change will add the /ascii option when calling the ReturnDensity program toproduce outputs in ASCII raster format and cause the outputs to be converted to
IMAGINE format. If you want the ASCII raster format outputs a well, change“SET KEEPASCIIFILES=FALSE” to “SET KEEPASCIIFILES=TRUE”.

Figure 19. Processing scripts used to create return density layers.

•

•
•

•

Go into Processing blocks and click the button labeled “Subdivide extent: block
width/height” and set the block width and height to be the same as the tile size
specified in the processing options. This will force an arrangement where eachblock has a single tile.
Create the processing tile layout and create the master script.
View the processing tile layout to make sure that each processing block has asingle processing tile. You can also verify that the values shown on the main
dialog for “Blocks” and “Processing tiles” are the same.
Run the primary batch file from a command prompt where the current folder isthe folder where the primary batch file is located.

212

Appendix G: Converting ESRI GRID data to ASCII raster
format using GDAL

213

Overview
Surface data, including bare-ground and canopy surface models, are often provided in
ESRI’s GRID format. While this format is common to users of ESRI’s products, it is a
proprietary format that is not used by many applications. The Geospatial Data
Abstraction Library (GDAL) is an open-source library and collection of applications(http://www.gdal.org/) that can read surface data stored GRID format and convert it toother formats. The most useful conversion for FUSION users is that from GRID to ASCII
raster format used by the ASCII2DTM program. In general, conversion from GRID to
ASCII raster format using GDAL is faster than the same conversion using theRasterToASCII command in ArcMap. In addition, conversion of several GRID files canfiles can be accomplished using a batch file containing a simple FOR loop that process
all folders (GRID layers) in an acquisition.

Converting data from GRID to ASCII raster format
GDAL provides the gdal_translate utility to convert raster data between different
formats. This utility is useful and allows this conversion without any need for ESRI’s GIS
products. Complete documentation for gdal_translate can be found here:
http://www.gdal.org/gdal_translate.html. While gdal_translate provides a number of
useful features, the most important options when converting GRID data for use by
ASCII2DTM are:-co FORCE_CELLSIZE=YES-co DECIMAL_PRECISION=4 (# of decimal digits in ASCII raster output)
The first option forces grid cells to be square and the second specifies the number ofdecimal digits “printed” to the ASCII raster files. The DECIMAL_PRECISION option candramatically affect the size of the output files so you should not specify excessive
precision. Three or four decimal digits are usually sufficient for airborne LIDAR data.
When converting GRID data, the input “file” is simply the folder name used to store all of
the files associated with the GRID layer. Gdal_translate will find the file in this folder that
contains the actual grid values and convert these to the ASCII raster format.
Syntax for the command line to convert data stored in GRID format into ASCII raster
format is:
gdal_translate –co FORCE_CELLSIZE=YES –co DECIMAL_PRECISION=4 –of AAIGrid
folder_name output_file.asc
The –co options are described above. The –of AAIGrid option specifies that the output is
to be ASCII raster format. folder_name specifies the name of the folder containing the
GRID layer and output_file.asc specifies the desired name for the output data. The “.asc”
extension is not mandatory but this is the extension expected by the ASCII2DTM utility.

214

Appendix H: Using FUSION/LDV to adjust plot and individual
tree locations

215

Overview
Version 4.5 added capabilities to FUSION and LDV that facilitate movement of plot andindividual tree locations (including tree lean). These capabilities allow you to better alignfield data with lidar point data thus improving downstream modeling and analyses.
Earlier modifications enabled this capability in an experimental version of FUSION /LDV
that was used to adjust the location of 720 field plots. The most recent changes were
tested with a smaller dataset (27 plots) but this test also included the adjustment of
individual tree locations and orientations to characterize tree lean. The first test resulted
in better model predictions for inventory attributes and the second helped produce aclassification model to identify species using high-density (>1200 points/m2) lidar
collected from a UAV.
Using the plot adjustment capability requires creation and manipulation of tree files and,optionally ground files and point data. While the tree files can be created manually, theprocess works best when you can automate or script the needed tasks. I use R to
produce the tree files and clip ground models for individual plots but any scripting or
programming language can be used. The capabilities can be used with wall-to-wall point
data but perform the best when you clip point data for individual plot locations to create
separate LAS files for each plot. When working with lidar data and plots, I usually
produce clips covering an area substantially larger than the plot and another set of clips
covering only the plot area. When adjusting plot locations, I also clip an area that buffers
the plot by the maximum location error that I expect. For example, if I am working with
1/10 ha circular plots (17.84 m radius), I will use ClipData to clip data for the following
areas:• 1 ha square centered on the plot location,• 60m square centered on the plot location (using the 1 ha square as input),• Circle (17.84 m radius) covering the plot (using either the 1 ha or 60 m square as
input).
Save all these files in LAS format (not LAZ). FUSION performance suffers with LAZ
format files to the point where it is nearly unusable.
Use the 60m (or whatever size is appropriate for your plots) clips in FUSION when
adjusting tree/plot locations. After adjustment, I clip a new circular area (17.84 m) using
the adjusted plot location and use these data for computing metrics for further analyses.
For 1/10 ha circular plots, the 60m square allows for errors in plot location of up to~12m. If you expect larger location errors, use the 1 ha square clip when adjusting
locations. However, as the potential error in plot locations increases, it become harder
to “find” the correct plot location especially in dense forests with uniform tree heights.
There are two ways to approach plot adjustment in FUSION/LDV. The first (with the
Adjust plots checkbox off) is to manually configure FUSION with the data for each plot
(point data, tree list, and optional ground and canopy surfaces). You adjust plot and treelocations for the plot then load new files for the next plot. The second (with the Adjust
plots checkbox on) is to have a set of tree and ground files for your plots along with apoint shapefile with plot locations and an attribute for each plot that provides the base216

name for tree and ground files. As you clip samples for individual plots, thecorresponding tree and ground files are provided to LDV along with the point sample.
Using the second option, you can have point data for several plots loaded into FUSION
and simply click near a plot to load all the data needed for the adjustment process (turnon the “Snap sample point to nearest POI point” option in the sample options). For boththe manual and automated options, you can only use a single tree file.
The adjustment process in LDV allows you to move the trees as a group (essentiallyadjusting the plot location) or individually. Coordinates in the tree file are updated when
you click the “Save tree(s)” button. While there is no separate plot center location that isprovided to or maintained by the adjustment process, tree files can contain a special
record with the identifier “PLOT_CENTER”. Such records are drawn using a special
symbol and the tree movement dialog in LDV allows you to snap the measurement
marker to the plot center. This record allows you to track changes in the plot location
during the adjustment process. This record is especially useful when your plot center
does not correspond to a tree location. For the “PLOT_CENTER” record, the size of themarker is controlled using the DBH parameter for the tree and the color of the marker is
set to the crown color. Other size parameters (tree height, height to crown base andcrown dimensions) are ignored. See the Appendix A: File Formats for an example tree
file with a PLOT_CENTER record.

Requirements
The minimum data required when adjusting plots includes point data and tree files foreach plot. If you want to take advantage of the automated approach offered when the“Adjust plots” checkbox is turned on, you also need a point shapefile containing plot
locations that is loaded as a point of interest (POI) and a ground file for each plot. The
attribute in the first field of the shapefile data table must provide a base name that is
also used for the tree and ground surface files. For example, if the value in the firstcolumn is “Plot_13”, FUSION will try to use files named Plot_13.csv and Plot_13.dtm forthe tree and ground surface data. If you are using the manual configuration option,
ground files are not required for the adjustment process. However, if your tree files do
not have elevations for the trees, you need to supply a ground model so elevations canbe interpolated and added to the tree records. If you are using the automatedconfiguration option, ground files are required. The tree and ground files for all plots
should be in the same folder or separate folders for each file type. These folder names
are specified in the FUSION project by clicking the button with “…” next to the “Adjust
plots” checkbox. If you have not provided folder names, you will be presented with theopportunity to provide the folder names when you turn on the “Adjust plots” checkbox.
When adjusting tree/plot locations, be sure to make a copy of all of your tree files before
you start to make changes. Once changes are made, new locations are written to thefiles and changes cannot be reversed.

FUSION configuration
There are a few things that need to be configured in FUSION to allow tree location
adjustments. In the FUSION preferences, be sure the “Clip tree objects to sample area”
217option is NOT checked. This tells FUSION to pass the entire set of trees to LDV
regardless of the size or location of the point sample. In the sample options, turn on“include tree models in data sample”. You can use any of the other sampling options
without affecting the tree relocation process. I generally find that normalizing the sample
isn’t helpful when moving trees. Normalization may be useful in some cases dependingon the slope and amount of understory vegetation as well as the return density andnumber of stem hits in your data. If you have a shapefile with plot locations, it is helpful
to turn on the “Snap sample point to nearest POI point” option and use one of the fixedsample shapes with the size set to your plot size (or something larger to accommodate
the expected error in the location). This way you can click close to a plot location andthe sample point will be snapped to the closest plot.

Adjusting tree/plot locations
Once you have configured FUSION and have loaded point data, tree, and optionally apoint shapefile and ground data, you are ready to clip a sample and adjust the tree/plot
locations. In LDV, you should see your point data and tree objects. If you have included
a PLOT_CENTER record in the tree files for your plots, you should also see a circulartarget ( ) slightly below ground. In LDV, press F5 to activate the Tree movement dialog(Figure 20).

Figure 20. Tree movement dialog in LDV.

The tree/plot adjustment capabilities use LDV’s measurement marker features. Table 3
presents the controls used to move the measurement marker as they relate to adjustingtree/plot locations.

218

Table 3. LDV keyboard and mouse controls useful when adjusting tree and plot locations.

Keystroke ormenu item
Ctrl-Rightmouse dragCtrl-Shift-Rightmouse dragCtrl-left mousedrag
Ctrl-Left arrow

PurposeUtility when relocating trees

Move the measurement
markerResize the measurement
markerZoom in/out

Positioning marker to select trees
and moving tree base and top
Displaying more/less points andisolate points for an individual tree

Rotate measurement marker
counterclockwise

Ctrl-Right arrow

Rotate measurement marker
clockwise

Mouse wheel

Raise/lower measurement
plate

Alt-C

Toggle display of points
outside the measurementcylinderReorient the view (overhead)
Spin mode (Esc to stop
spinning)
Move the measurement
marker to the center of thebounding box for the points
within the upper and lower
disks on the measurement
marker.
Set measurement marker ongroundSet measurement marker at
the height of the highest point
within cylinder
Move measurement marker at
the height of the highest point
within cylinder
Toggle labels on the treemodelsWhen all trees are selected, rotate alltrees on plot. No effect when a single
tree is selected.
When all trees are selected, rotate alltrees on plot. No effect when a single
tree is selected.
Positioning tree base and top.
Isolating points when using “F” to fit
the location to the points in thevertical selection area
Speeds up movement and reduces
clutter

Alt-O
Alt-S
F

G
H

Shift-H

Right button
menu-Object
model
options…Showobject labels

219

Confirm proper alignment andlocation of stem
By changing the size and position of
the measurement marker so it
includes only points for a single stemor tree top, “F” centers themeasurement marker within thosepoints.
Setting location of tree baseSetting height of treetop (without
moving XY location)
Setting location of treetop

The labels is the identifier in the tree
filesYou have the choice of adjusting the location of a single tree or adjusting the location of
all trees (i.e., adjust the plot location). In most cases, it is best to start by adjusting theplot location and then fine tune the locations for individual trees. Generally, the denser
the stand and the larger the error in plot location, the harder it is to find a location that is“correct”. For the example shown in Figure 20, The correct location is about 6.5 meters
west of the original location. This offset moves some of the trees visible in Figure 20
outside the point data clipped for the plot. This is why you should make sure you clip
data for an area large enough to accommodate the expected errors in plot locations.

Adjusting individual tree locations
To adjust individual trees, move the marker close to the desired tree and click the“Select closest tree” button. Ensure that the desired tree is selected, then adjust thelocation by moving the measurement marker. You can move the tree vertically byraising or lowering the marker using the mouse wheel. This can help you align the stemwith points. However, be sure to move the tree back to ground level before locking in
the base location. Once satisfied with the location, click the “Set base XYZ” button to“lock in” the base of the tree. The marker will move automatically to the top of the treemodel. If you want to adjust the tree lean, move the marker to the top of the tree, in the
point data, and click the “Set top XYZ” button to “lock in” the tree top location. If you do
not want to adjust the tree lean, you still need to press the “Set topXYZ” button before
you can save the tree. If you decide that the adjustments are incorrect, you can click the“Reset tree attributes” button to move the tree back to its original location or the“Deselect tree(s)” button to move the tree back to its original location and deselect thetree. Once you have the position where you want it, click the “Save tree(s)” button towrite the tree to the tree file. Once the tree is written to the tree file, you cannot “undo”
your changes.
There are special features that make setting the stem position easier. Move themeasurement disk and change its size so the circles above and below the disk contain
only points for a single stem. Then press “F” to move the measurement marker to thecenter of the bounding box for the points. You can adjust the range for the vertical sliceof data used for the fitting process on the Tree movement dialog. The bounding box
midpoint is used instead of the average since we often have trees with stem hits on only
1-2 sides of the tree. When setting the top of a tree, it may help to reduce the size of themeasurement cylinder, position the cylinder so it contains the highest point, and thenuse shift-H to snap the marker position to the highest point. You can also use the rightmouse menu (or Alt-C) to set “Draw only points within the measurement cylinder”. This
makes it easier to see the trees in the point data and it speeds up the movement of thepoint cloud. The Tree movement dialog has an option to display only the active tree.
This also helps cut down the clutter as you reposition trees. You can float the tree
above ground (may be helpful when aligning the stem with points) but be sure to put themarker on the ground before clicking the “Set base XYZ” button. The “Attribute clipping”
dialog (activated using F8) is useful for highlighting or displaying stem and treetop
points. With Attribute clipping turned on, only points within the lower and upper attribute220

values are used to compute the bounding box. The range for vertical fit (on the tree
adjustment dialog) is ignored in this case.
Status code meanings are determined by the user. The Tree movement dialog allows
you to set values of 0-4 for the status code.

Adjusting all tree locations (adjusting the plot location)
To adjust the plot location, move the marker to the plot center and click the “All” button.
If you have a PLOT_CENTER tree record, you can use the “Move marker to plot center”
button to move the marker to the record’s location before making any adjustments.
Placing the marker on the plot center allows you to rotate the plot to correct for overall
azimuth or declination errors and ensure that rotational adjustments occur around theplot center. As you move the measurement marker, all trees will be moved. The best
strategy is to move the trees until the larger trees align with the point cloud. If you findthat a rotation is needed to align the trees, use Ctrl-left arrow and Ctrl-right arrow torotate the entire set of trees around the current location. Once you are satisfied with theoverall alignment for the plot, click the “Save tree(s)” button and proceed with individual
tree adjustments. As with individual tree adjustments, the “Attribute clipping” dialog(activated using F8) is useful for highlighting or displaying stem and treetop points.
When viewing ALS data, treetops are generally more visible than tree stems. Using theattribute clipping feature allows you to view only points in the lower levels of the canopy.
These points, if they include stem hits, may allow you to better align the trees with thepoint data. In tests of the adjustment capability, I found that ALS data with ~10
pulses/m2 contained stem hits for at least a few trees on most plots. If you take time to
explore the point data for a plot and identify points for a few stems, it can greatly
simplify the alignment process.

221