Once a dataset has been imported (step 3), and either before or after specifying any common tables (step 4), the next step is to set some global analysis parameters. Note, if you opened a previously saved model, you can modify the analysis parameters as well before executing the program.
In the left pane of the model dialog window make sure the Analysis parameters tab is selected, as shown in figure 5.
Figure 5. Model dialog for parameterizing FRAGSTATS, shown here for a "new" model that has yet to be parameterized, and with the "Analysis parameters" tab in the left panel selected.
- Neighbor rule -- Chose between the 4-cell and 8-cell rule for delineating patches. The 4-cell rule considers only the 4 adjacent cells that share a side with the focal cell (i.e., orthogonal neighbors) for determining patch membership. The 8-cell rule considers all 8 adjacent cells, including the 4 orthogonal and 4 diagonal neighbors. Thus, if the 4-cell rule is selected, two cells of the same class that are diagonally touching will be considered as part of separate patches; if the 8-cell rule is selected, these will be considered part of the same patch. The choice of patch neighbor rule will affect most of the configuration metrics, but will have no affect on the composition metrics. The 8-cell rule is the default.
- Automatically save results -- You can automatically save the results to output files after execution by checking the Automatically save results check box. If you choose to automatically save results, you must also specify a "basename" for the output files by clicking on the browse button and navigating to the desired folder, and then entering a "basename" or selecting an existing file name to overwrite. This basename will be given the extensions .patch, .class, .land and .adj for the corresponding patch, class, and landscape metrics and adjacency matrix, as selected.
- Note, if you do NOT check the Automatically save results box, the results can always be saved after the execution from the results dialog box (see below).
- Note, if you check the Automatically save results box and fail to specify a basename file for the output, FRAGSTATS will fail and you will get an error message to that effect in the activity log.
- Note, if you specify the basename of a file that already exists, FRAGSTATS will automatically rename the extension of the existing files to *.bk1. The next time there is a conflict, the files will be renamed *.bk2, and so on. Appending the results to an existing file is not an option because there is no guarantee that the output file structure will be the same.
- Note, if you specify the basename of a file name that already exists, you need only include the basename of the file; i.e., the name up to the first period. You do not need to include the file extension, as it will be ignored.
- Sampling strategy -- You have several sampling strategies to choose from, depending on the objectives of your analysis, as follows:
- No sampling [tabular output] - You have the option to treat the landscape mosaic as a whole, without any sampling, and the choice of the following levels of metrics (and you must choose at least one level) and whether or not to output a patch ID grid, as follows:
- Patch metrics -- If selected, patch metrics can be computed. However, this merely enables (i.e., turns on) patch metrics; you still must select one or more individual patch metrics (see below), otherwise no patch metrics will be calculated.
- Class metrics -- If selected, class metrics can be computed. However, this merely enables class metrics; you still must select one or more individual class metrics (see below), otherwise no class metrics will be calculated.
- Landscape metrics -- If selected, landscape metrics can be computed. However, this merely enables landscape metrics; you still must select one or more individual landscape metrics (see below), otherwise no landscape metrics will be calculated.
- Output patch id grid -- You have the option of creating and outputting a Patch ID image. If you select this option, a patch ID image will be created by FRAGSTATS and output in the same data type format as the Input Data Type. The Patch ID image will contain a unique ID for each patch in the landscape. All background cells will be assigned a negative of the user-specified background value. This patch ID corresponds to the patch ID in the "basename".patch output file. This image is needed if you wish to associate the patch-level output with specific patches and view the results using a GIS. Note, the patch ID file will be named using the following convention and output to the same directory as the input image:
Input file name _4 or 8 (depending on neighbor rule) + ID
Thus, an input file named "test" analyzed with an 8-neighbor rule will be given the following patch ID file name: test_8id. If you attempt to create and output an ID image that already exists, e.g., from a previous run, FRAGSTATS will ask you whether you want to overwrite the existing file.
- Patch metrics -- If selected, patch metrics can be computed. However, this merely enables (i.e., turns on) patch metrics; you still must select one or more individual patch metrics (see below), otherwise no patch metrics will be calculated.
- Exhaustive sampling with user-provided tiles [tabular output] -- You have the option of subdividing the landscape into user-provided tiles and analyzing each tile as a separate sub-landscape. Here you must chose one or more levels of metrics (and you must choose at least one) as described above, but here the output will include separate calculations for each tile. In addition, you must input a tile grid that has the exact same dimensions, alignment and data format as the input landscape.
- Exhaustive sampling with uniform tiles [tabular output] -- You have the option of subdividing the landscape into uniform square tiles and analyzing each tile as a separate sub-landscape. Here you chose the side length (m) for the tiles and FRAGSTATS will create sub-landscapes for the analysis starting in the upper left of the grid, including any nodata area outside the landscape boundary but within the rectangular grid. Incomplete tiles that do not fit within the grid will be discarded. In addition, you have the option of specifying whether to include tiles that are not entire contained within the landscape boundary; i.e., part of the tile is nodata. Specifically, you must specify the maximum percentage of border or nodata to accept as a valid tile. Any tile not meeting this threshold will be ignored in the analysis. For example, if you specify 0% then any tile not completely inside the landscape boundary (i.e., containing any border or nodata cells) will be discarded. Again, you must chose one or more levels of metrics (and you must choose at least one) as described above, but here the output will include separate calculations for each tile.
- Exhaustive moving window analysis without kernel weighting [grid output] -- You have the option of conducting an exhaustive local neighborhood structure analysis (or moving window analysis) with fixed-sized windows and outputting the results as a new grid for each selected metric. If you select this option, then you must specify the metric level (class or landscape) and the shape (round or square) and size (radius or length of side, in meters) of the window to be used. A window of the specified shape and size is passed over every positively valued cell in the grid (i.e., all cells inside the landscape of interest). However, only cells in which the entire window is contained within the landscape are evaluated (see below). Within each window, each selected metric at the class or landscape level is computed and the value returned to the focal (center) cell. Patch metrics are not allowed in the moving window analysis. The moving window is passed over the grid until every positively valued cell (including positively valued background cells) containing a full window is assessed in this manner. Note, internal background cells containing real positively-valued classes in the window may receive a value in the output grid, despite the fact that the cell is background in the input grid. Specifically, if the entire window is internal background, then the cell will receive a minus background value in the output grid. There are several important considerations when conducting a moving window analysis:
- Window shape and size -- The user-specified window size refers to the radius (in meters) of a near-circular window or hexagon-shaped window, or the length of the side (in meters) of a square window, depending on the shape chosen. It is important to note that the actual area of the window as implemented algorithmically will vary slightly from the area calculated mathematically based on the geometry of a circle or square for two reasons. First, the radius is given as the distance from the focal cell to the edge of the window. For example, given a cell size of 10 m and a circular window, a 40 m radius would be implemented as a mask 4 cells wide. The diameter of the window would equal 90 m - twice the radius plus the size of the focal cell - as opposed to 80 m. The addition of the focal cell to the diameter of the window is necessary to force the focal cell to always be located at the exact center of the window. Second, the specified radius (in meters) is always rounded to the nearest cell. Thus, if the radius is not perfectly divisible by the cell size, the actual window will be somewhat smaller or larger. Essentially, the window will always be rounded to the nearest odd number of cells so that the focal cell is always located at the exact center of the window.
- Boundary effects -- Cells located close to the edge of the landscape (i.e., near the landscape boundary) are biased in moving window calculations if the window intersects the landscape boundary. Consider a cell located on the landscape boundary. A normal window placed on that cell would extend well outside the landscape boundary, in fact, half the window would extent beyond the landscape where information on landscape structure is absent. In fact, any cell within the specified radius of a round window or ½ the length of a side of a square window will be biased in this way. There are several alternative ways of handling this bias. FRAGSTATS adopts a conservative method that involves simply not computing the metrics for focal cells containing a partial window (i.e., a window not fully contained within the input grid). Actually, FRAGSTATS returns the user-specified exterior (negative) background value for these cells. Thus, in practice, the output grid will contain a peripheral buffer of exterior background cells surrounding the core of the landscape - only the core (cells containing a full window) will contain metric values (Fig. 6a).
Figure 6. (A) Moving window applied to an input grid without a border produces an output grid for each unique class-metric combination in which a strip the width of the window around the periphery of the grid is given a background value in the output grid. (B) A landscape border at least as wide as the window allows all cells inside the landscape boundary (dark line) (i.e., positive values) to be given the computed focal cell value.Clearly, as landscape extent increases relative to window size, the magnitude and spatial extent of the boundary effect decreases. For this reason, care should be exercised in selecting a window size that minimizes the loss of information due to the boundary effect. An alternative approach for dealing with the boundary effect is to expand the extent of the input landscape to include a suitably wide expansion strip of positively valued and appropriately classified cells around the actual landscape of interest, where the width of this extension is equal to the radius of the window (Fig. 6b). In this manner, the core of the landscape in the output grid produced by the moving window analysis will align with the original landscape boundary of interest. It is important to realize that including a suitably wide landscape border (negatively valued, but classified cells) does not have the same effect. Border, by definition, consists of negatively valued cells outside the landscape of interest, and FRAGSTATS ignores all negatively valued cells when calculating metrics, except for the information provided on adjacency to positively valued cells.
- Input data types -- Moving window analysis is restricted to input data types that can effectively handle floating point values. Thus, the 8- and 16-bit binary data formats are not allowed in a moving window analysis. If these data type are included in a batch file used in conjunction with a moving window analysis, the corresponding records will be ignored.
- Selection of classes and metrics -- For each selected metric and enabled class, FRAGSTATS outputs a separate grid (in the same format as the input grid). Thus, if the input landscape contains 10 classes and all of them are enabled in the class descriptors file (see above) and you select one class-level metric, then FRAGSTATS outputs 10 grids, one for each class for the selected metric. In this case, each output grid represents a separate class, and the cell values represent the computed values of the selected metric for that class. Specifically, a window is placed over the first cell in the input landscape, the selected metric is computed for the first class, and this value is output to the corresponding cell in a new grid for that specific metric-class combination. The process is repeated for the next class, and so on, until all classes have been assessed. Next, the window is placed over the next cell and the process is repeated. The process is repeated in this manner until all positively valued cells containing a full window in the input landscape have been evaluated. The end result is a new grid for each class, in which the cell values represent the values of the computed metric. Accordingly, if you select five class-level metrics, then FRAGSTATS outputs 50 grids, one for each class-metric combination. If, in addition to these class metrics, you also select three landscape metrics, FRAGSTATS outputs an additional three grids, one for each landscape metric. Clearly, the number of output grids can increase quickly with several classes and several metrics. Thus, it is important to carefully select the most parsimonious set of classes and metrics. Note, windows containing no cells of the corresponding class, or in some cases just a single cell of the corresponding class, will be assigned a background value in the output grid.
- Computer processing and memory requirements -- The computer processing and memory demands of the moving window analysis are phenomenal. Consider a relatively small grid of 100 x 100 cells; i.e., 10,000 cells. The moving window analysis involves placing a window over every cell and computing one or more metrics. This is equivalent to doing 10,000 FRAGSTATS analyses. Now imagine that you have a larger grid of 1000 x 1000 cells; i.e., 1,000,000 cells. Clearly, the processing time quickly becomes overwhelming. In addition, the memory demands increase as a function of the size the input grid. FRAGSTATS must be able to allocate memory for at three grids, where each grid requires four bytes for every cell. See Computer Requirements in the Overview Section for a detailed description of the memory requirements. Clearly, given the limited memory available in most personal computers, it is quite possible that you will not have enough memory to do even a single unique class-metric combination, let alone the dozens or hundreds that could easily result if you selected several classes and several metrics. If more than one class-metric combinations are selected, FRAGSTATS will determine how many can be done given the available memory and then parse the job into separate passes. For example, if 20 class-metric combinations are selected, but available memory is sufficient for only four at a time, then FRAGSTATS will conduct five passes across the landscape, output four grids each pass. Given these considerations, it behooves you to use this option sparingly and with great patience until computer processing capabilities increase substantially. And don't be too surprised if your computer is simply unable to allocate sufficient memory to do any moving window analysis.
- Output grid naming convention -- Given the number of possible output grids produced from a moving window analysis and limits on the file name length with some data types, the output file naming convention is somewhat cumbersome. If a moving window analysis is selected, FRAGSTATS will create a new subdirectory beneath the directory containing the input file by appending "_MW1" (for moving window #1) to the name of the input file. Thus, a directory named "Test" containing the input file named "TestGrid" will have a new subdirectory under the Test directory named "TestGrid_MW1". This subdirectory will contain an output grid for each class-metric combination and landscape metric selected. For landscape metrics, the output grids are named using the metric acronym. For class metrics, the metric acronym is combined with the class ID value (see Class descriptors) because each class has a separate output grid. For example, landscape-level Contagion index (CONTAG) would be given the grid name: CONTAG. Class-level Clumpiness index (CLUMPY) for class ID #3 would be given the grid name: CLUMPY_3. See the list of metrics in the FRAGSTATS Metrics documentation for the metric acronyms. If a second moving window analysis is conducted on the same input file (e.g., using a different window size), a second directory is created by appending "_MW2" to the name of the input file. And so on for each subsequent moving window analysis.
- Window shape and size -- The user-specified window size refers to the radius (in meters) of a near-circular window or hexagon-shaped window, or the length of the side (in meters) of a square window, depending on the shape chosen. It is important to note that the actual area of the window as implemented algorithmically will vary slightly from the area calculated mathematically based on the geometry of a circle or square for two reasons. First, the radius is given as the distance from the focal cell to the edge of the window. For example, given a cell size of 10 m and a circular window, a 40 m radius would be implemented as a mask 4 cells wide. The diameter of the window would equal 90 m - twice the radius plus the size of the focal cell - as opposed to 80 m. The addition of the focal cell to the diameter of the window is necessary to force the focal cell to always be located at the exact center of the window. Second, the specified radius (in meters) is always rounded to the nearest cell. Thus, if the radius is not perfectly divisible by the cell size, the actual window will be somewhat smaller or larger. Essentially, the window will always be rounded to the nearest odd number of cells so that the focal cell is always located at the exact center of the window.
- Exhaustive moving window analysis with kernel weighting [grid output] -- You have the option of conducting an exhaustive local neighborhood structure analysis (or moving window analysis) with a kernel-weighted window and outputting the results as a new grid for each selected metric. Note, here the kernel window varies depe If you select this option, then you must specify the metric level (class or landscape) and the shape (round or square) and size (radius or length of side, in meters) of the window to be used. A window of the specified shape and size is passed over every positively valued cell in the grid (i.e., all cells inside the landscape of interest). However, only cells in which the entire window is contained within the landscape are evaluated (see below). Within each window, each selected metric at the class or landscape level is computed and the value returned to the focal (center) cell. Patch metrics are not allowed in the moving window analysis. The moving window is passed over the grid until every positively valued cell (including positively valued background cells) containing a full window is assessed in this manner. Note, internal background cells containing real positively-valued classes in the window may receive a value in the output grid, despite the fact that the cell is background in the input grid. Specifically, if the entire window is internal background, then the cell will receive a minus background value in the output grid. There are several important considerations when conducting a moving window analysis:
- Window shape and size -- The user-specified window size refers to the radius (in meters) of a near-circular window or hexagon-shaped window, or the length of the side (in meters) of a square window, depending on the shape chosen. It is important to note that the actual area of the window as implemented algorithmically will vary slightly from the area calculated mathematically based on the geometry of a circle or square for two reasons. First, the radius is given as the distance from the focal cell to the edge of the window. For example, given a cell size of 10 m and a circular window, a 40 m radius would be implemented as a mask 4 cells wide. The diameter of the window would equal 90 m - twice the radius plus the size of the focal cell - as opposed to 80 m. The addition of the focal cell to the diameter of the window is necessary to force the focal cell to always be located at the exact center of the window. Second, the specified radius (in meters) is always rounded to the nearest cell. Thus, if the radius is not perfectly divisible by the cell size, the actual window will be somewhat smaller or larger. Essentially, the window will always be rounded to the nearest odd number of cells so that the focal cell is always located at the exact center of the window.
- Boundary effects -- Cells located close to the edge of the landscape (i.e., near the landscape boundary) are biased in moving window calculations if the window intersects the landscape boundary. Consider a cell located on the landscape boundary. A normal window placed on that cell would extend well outside the landscape boundary, in fact, half the window would extent beyond the landscape where information on landscape structure is absent. In fact, any cell within the specified radius of a round window or ½ the length of a side of a square window will be biased in this way. There are several alternative ways of handling this bias. FRAGSTATS adopts a conservative method that involves simply not computing the metrics for focal cells containing a partial window (i.e., a window not fully contained within the input grid). Actually, FRAGSTATS returns the user-specified exterior (negative) background value for these cells. Thus, in practice, the output grid will contain a peripheral buffer of exterior background cells surrounding the core of the landscape - only the core (cells containing a full window) will contain metric values (Fig. 6a).
Figure 6. (A) Moving window applied to an input grid without a border produces an output grid for each unique class-metric combination in which a strip the width of the window around the periphery of the grid is given a background value in the output grid. (B) A landscape border at least as wide as the window allows all cells inside the landscape boundary (dark line) (i.e., positive values) to be given the computed focal cell value.Clearly, as landscape extent increases relative to window size, the magnitude and spatial extent of the boundary effect decreases. For this reason, care should be exercised in selecting a window size that minimizes the loss of information due to the boundary effect. An alternative approach for dealing with the boundary effect is to expand the extent of the input landscape to include a suitably wide expansion strip of positively valued and appropriately classified cells around the actual landscape of interest, where the width of this extension is equal to the radius of the window (Fig. 6b). In this manner, the core of the landscape in the output grid produced by the moving window analysis will align with the original landscape boundary of interest. It is important to realize that including a suitably wide landscape border (negatively valued, but classified cells) does not have the same effect. Border, by definition, consists of negatively valued cells outside the landscape of interest, and FRAGSTATS ignores all negatively valued cells when calculating metrics, except for the information provided on adjacency to positively valued cells.
- Input data types -- Moving window analysis is restricted to input data types that can effectively handle floating point values. Thus, the 8- and 16-bit binary data formats are not allowed in a moving window analysis. If these data type are included in a batch file used in conjunction with a moving window analysis, the corresponding records will be ignored.
- Selection of classes and metrics -- For each selected metric and enabled class, FRAGSTATS outputs a separate grid (in the same format as the input grid). Thus, if the input landscape contains 10 classes and all of them are enabled in the class descriptors file (see above) and you select one class-level metric, then FRAGSTATS outputs 10 grids, one for each class for the selected metric. In this case, each output grid represents a separate class, and the cell values represent the computed values of the selected metric for that class. Specifically, a window is placed over the first cell in the input landscape, the selected metric is computed for the first class, and this value is output to the corresponding cell in a new grid for that specific metric-class combination. The process is repeated for the next class, and so on, until all classes have been assessed. Next, the window is placed over the next cell and the process is repeated. The process is repeated in this manner until all positively valued cells containing a full window in the input landscape have been evaluated. The end result is a new grid for each class, in which the cell values represent the values of the computed metric. Accordingly, if you select five class-level metrics, then FRAGSTATS outputs 50 grids, one for each class-metric combination. If, in addition to these class metrics, you also select three landscape metrics, FRAGSTATS outputs an additional three grids, one for each landscape metric. Clearly, the number of output grids can increase quickly with several classes and several metrics. Thus, it is important to carefully select the most parsimonious set of classes and metrics. Note, windows containing no cells of the corresponding class, or in some cases just a single cell of the corresponding class, will be assigned a background value in the output grid.
- Computer processing and memory requirements -- The computer processing and memory demands of the moving window analysis are phenomenal. Consider a relatively small grid of 100 x 100 cells; i.e., 10,000 cells. The moving window analysis involves placing a window over every cell and computing one or more metrics. This is equivalent to doing 10,000 FRAGSTATS analyses. Now imagine that you have a larger grid of 1000 x 1000 cells; i.e., 1,000,000 cells. Clearly, the processing time quickly becomes overwhelming. In addition, the memory demands increase as a function of the size the input grid. FRAGSTATS must be able to allocate memory for at three grids, where each grid requires four bytes for every cell. See Computer Requirements in the Overview Section for a detailed description of the memory requirements. Clearly, given the limited memory available in most personal computers, it is quite possible that you will not have enough memory to do even a single unique class-metric combination, let alone the dozens or hundreds that could easily result if you selected several classes and several metrics. If more than one class-metric combinations are selected, FRAGSTATS will determine how many can be done given the available memory and then parse the job into separate passes. For example, if 20 class-metric combinations are selected, but available memory is sufficient for only four at a time, then FRAGSTATS will conduct five passes across the landscape, output four grids each pass. Given these considerations, it behooves you to use this option sparingly and with great patience until computer processing capabilities increase substantially. And don't be too surprised if your computer is simply unable to allocate sufficient memory to do any moving window analysis.
- Output grid naming convention -- Given the number of possible output grids produced from a moving window analysis and limits on the file name length with some data types, the output file naming convention is somewhat cumbersome. If a moving window analysis is selected, FRAGSTATS will create a new subdirectory beneath the directory containing the input file by appending "_MW1" (for moving window #1) to the name of the input file. Thus, a directory named "Test" containing the input file named "TestGrid" will have a new subdirectory under the Test directory named "TestGrid_MW1". This subdirectory will contain an output grid for each class-metric combination and landscape metric selected. For landscape metrics, the output grids are named using the metric acronym. For class metrics, the metric acronym is combined with the class ID value (see Class descriptors) because each class has a separate output grid. For example, landscape-level Contagion index (CONTAG) would be given the grid name: CONTAG. Class-level Clumpiness index (CLUMPY) for class ID #3 would be given the grid name: CLUMPY_3. See the list of metrics in the FRAGSTATS Metrics documentation for the metric acronyms. If a second moving window analysis is conducted on the same input file (e.g., using a different window size), a second directory is created by appending "_MW2" to the name of the input file. And so on for each subsequent moving window analysis.
- Window shape and size -- The user-specified window size refers to the radius (in meters) of a near-circular window or hexagon-shaped window, or the length of the side (in meters) of a square window, depending on the shape chosen. It is important to note that the actual area of the window as implemented algorithmically will vary slightly from the area calculated mathematically based on the geometry of a circle or square for two reasons. First, the radius is given as the distance from the focal cell to the edge of the window. For example, given a cell size of 10 m and a circular window, a 40 m radius would be implemented as a mask 4 cells wide. The diameter of the window would equal 90 m - twice the radius plus the size of the focal cell - as opposed to 80 m. The addition of the focal cell to the diameter of the window is necessary to force the focal cell to always be located at the exact center of the window. Second, the specified radius (in meters) is always rounded to the nearest cell. Thus, if the radius is not perfectly divisible by the cell size, the actual window will be somewhat smaller or larger. Essentially, the window will always be rounded to the nearest odd number of cells so that the focal cell is always located at the exact center of the window.
- No sampling [tabular output] - You have the option to treat the landscape mosaic as a whole, without any sampling, and the choice of the following levels of metrics (and you must choose at least one level) and whether or not to output a patch ID grid, as follows: