# NPS Documentation

# Quiet Places Initiative/Sensitive Areas Model (SAM)

# 

[Topics:]{.underline}

> Background
>
> Selecting Input Data
>
> Data Issues
>
> Running the Model
>
> Model Output
>
> Use of Output Products

####### ***Background***

The Sensitive Area Model, or SAM, is a spatial analysis tool that allows
multiple-theme overlays, theme buffering, and weighting of input themes
to analyze sensitive resource areas within National Park Service units.
The model was previously known as the Quiet Places initiative during its
prototype development. The Quiet Places effort intended to support three
related yet independent topics of concern to the NPS Soundscape
Management program: 1) Air Tour Management Planning (ATMP); 2)
implementation of soundscape management per Director's Order 47; and 3)
the delineation of Military Operation Areas (MOA). While SAM has been
developed with soundscape management issues in mind, this tool has
utility beyond soundscape-related issues. Spatial and temporal modeling
is made relatively easy through the model interface and park managers
should as a result find opportunities to address other resource
management questions using this tool.

The prototype model development occurred at Glacier National Park in
late 2001 and early 2002.

# Spatial Data Basics

Arcview supports a variety of spatial data formats, but the two primary
formats used in the Sensitive Areas Model are:

-   Vector -- points, lines, and polygons. All data stored in a
    shapefile is vector data. The two primary components of vector data
    are the shape, defined by one or more points, and the associated
    attributes.

> In a vector data model, each location is recorded as a single x,y
> coordinate. Points are recorded as a single coordinate. Lines are
> recorded as a series of ordered x,y coordinates. Areas are recorded as
> a series of x,y coordinates defining line segments that enclose an
> area, hence the term polygon, meaning 'many-sided figure'.

-   Raster \-- The raster data model is more like a photograph than a
    map. If you look at a photograph through a strong magnifying glass,
    you'll see that it is made up of a series of dots of different
    colors or shades of gray. The raster data model works in a similar
    way; it is a regular grid of dots (called cells, or pixels) filled
    with values.

> In the raster data model, each location is represented as a cell. The
> matrix of cells, organized into rows and columns, is called a grid.
> Each row contains a group of cells with values representing a
> geographic phenomenon. Cell values are numbers, which represent
> nominal data such as land use classes, measures of light intensity or
> relative measures.
>
> The size of the grid cell chosen for the analysis depends upon the
> data resolution required for the most detailed analysis. Larger grid
> cells may include more than one data value, which must be aggregated
> or prioritized and given a single value, thereby decreasing data
> resolution. The optimum grid-cell size to capture the appropriate
> detail varies from study to study. The smaller the grid cells the
> greater the resolution and accuracy; but coding, database storage, and
> processing speed for analysis is more costly.
>
> Because the raster data model is a regular grid, spatial relationships
> are implicit. Therefore, explicitly storing spatial relationships is
> not required as it is for the vector data model.
>
> One type of phenomenon that the grid-cell data structure is best
> suited to represent is continuous spatial data. These are phenomenon
> that produce a continuous surface where each location on the surface
> is based on the inherent characteristics of a location relative to a
> known fixed point or from an emanating source. They include elevation
> (the fixed point being sea level) and aspect (with the fixed point
> being a directional system: north, east, south and west), or the noise
> sensitivity of any location within a National Park.
>
> Grid systems treat points, lines, polygons and surfaces, and their
> locational structures the same way: as cells in a grid. When all the
> data types are in the same structure, one semantical language can be
> used. More importantly, the different data types can be mixed with no
> prior preparation. An environment that integrates data types provides
> the user greater flexibility when modeling.
>
> Because the grid-based system's foundation uses uniform grids, the
> mathematics are very simple and very fast when completing analysis
> between grids. Once registered, computing or deriving a value for an
> output cell from two or more input cells is a matter of direct value
> computation. No geometric detection, topology building and error
> checking is necessary.
>
> Understanding the raster model is important, because to perform
> analysis in this application, all input data sets are ultimately
> converted to the grid format.
>
> The grid data model does not support spaces and most special
> characters anywhere in the data's full path string (See complete
> discussion under the *Setting the Working Directory* topic.

###### *Selecting Input Data*

This application has been designed with no specific data requirements
allowing almost any spatial data to be used by the custom functions.
ArcInfo coverages, grids, shapefiles, and CAD-based themes can be used
in their native format. None of the input data will be edited by the
application, so write permission is not required. Source data can be
located on any combination of local and networked drives, but
performance will be much better with local data.

The model has four categories for defining data inputs: biological
habitat, wilderness, visitor use, and cultural resources. These
categories help track output grid processing and are useful for
organizing and preparing data for execution of the model. It is possible
to add additional data categories if desired. These four categories,
however, should be the starting point for defining model inputs when
addressing soundscape management issues. Considerations for specific
model inputs for ATMP analyses are described below. These
recommendations in general are applicable to other planning or
compliance-related applications of the model.

####### **Cultural Resources**

-   Recognized or protected through federal designation (National
    Register of Historic Structures, National Landmark Status, Historic
    Districts)

-   List of Classified Structures designation

-   State Section 106 compliance concern

-   Referenced in park enabling legislation, purpose and significance,
    primary interpretive themes, etc.

-   Archaeological site data should be used with extreme caution

> Generalize site locations.
>
> Not recommended that these data be used.

####### **Visitor Use**

-   Management zones from published planning documents.

-   Facilities or services referenced in park enabling legislation,
    purpose and significance, primary interpretive themes, etc.

-   Roads, trails, campsites and other visitor use assets.

####### **Wilderness**

-   Designated as wilderness formally.

-   Areas "managed as" wilderness.

####### **Biological Habitat** 

-   Protected through federal legislation (E.g. Threatened and
    Endangered Species Act, Migratory Bird Act).

-   Documented in the CFR.

-   State-listed species or habitats of concern (E.g. State Heritage
    Programs).

-   Published, peer-reviewed literature that documents impacts
    attributed to noise.

-   Referenced in park planning documents experiencing public review,
    such as General Management Plan or GPRA.

-   Referenced in park resource management task documents (E.g. RMP,
    PMIS).

-   Referenced in park enabling legislation, purpose and significance,
    primary interpretive themes, etc.

####### **Data Issues**

*Data quality, integrity, and defensibility*

Data sets chosen as model inputs must be of high quality in their
content and spatial integrity. These data must be defendable in court if
results generated by the model are challenged legally.

*Data availability and utility*

The utility of data sources, in the context of adding value to the
model, must be critiqued robustly. Data sets that provide general
habitat information, for example, may not be wise choices to include in
the model. Montana GAP data describes summer habitat for grizzly bears
in Glacier NP occurring on all but 10% of the park's 1.07 million acres
as habitat. This data is too general to add value to the model. Data
sets that are grossly incomplete, likewise, must also be evaluated for
their utility in the model. For example, park data describing known
golden eagle nest locations may be excellent in three of the park's 32
drainage's and non-existent for the other 29 drainage's, despite
biologists being "fairly confident" there is golden eagle nesting
occurring in at least fifty percent of those unsampled watersheds. Will
the limited data set add value to the model? Perhaps yes, as it is the
only available and verified information. GAP data, if available,
provides a viable alternative in cases such as this.

*Sensitive data and data-sharing legal issues*

Caution must be exercised when applying sensitive data as model inputs.
Data considered sensitive includes specific locations of archaeological
sites or threatened and endangered, or otherwise protected, species. It
is strongly recommended that as a general rule data sharing requirements
be well understood. There are two important considerations with regards
to sensitive data. The first and arguably most important is the
potential for this data, through its inclusion in a model, to be
released under FOIA and its related legal interpretations. A possible
scenario is if a researcher or contractor is using the model and
requests bald eagle (T&E species) nest location data to assist their
needs. Once a park releases that data it must share that data with any
subsequent requesting parties, regardless of affiliation. Section 207 of
the Thomas Bill and the 2001 NPS management policy provide some latitude
to parks for protecting sensitive data from FOIA and associated
requests. The second consideration is the content of sensitive data that
is released. A standard practice that protects these important locations
is the generalization of the data prior to release. GIS tools are
available to convert discrete point data to polygons, modify geographic
coordinates, and otherwise add fuzziness to site-specific information.

*Data preparation -- buffering*

No clear guidelines exist for determining appropriate buffer distances
for model inputs with regards to soundscape management. This may change
as more acoustical data is collected and analyzed. Examples encountered
during the prototype experience at Glacier NP included such inputs as
backcountry campsites, trails, golden eagle nests, and National Register
properties. Data inputs will often include points and these data may not
be very meaningful to the model as discrete points. Thus, some zone of
influence should be defined through buffering for these inputs.

*Data preparation -- weighting*.

Likewise, there are no guidelines for determining appropriate weighting
values for model inputs. These decisions are left to the discretion of
the resource managers and GIS staff. Weighting model inputs provides a
powerful vehicle to explore the relative value of park resources.
Weighted values can also assist the generation of seasonal scenarios to
address biological resources and visitor use. Prudence is advised in
determination of weighting values.

*Data preparation -- choosing theme names*.

When first loaded, a theme will be given the same name as its source
file. For example, a shapefile named trls01.shp representing park trails
would produce an Arcview theme with the same name when first loaded.
This name probably won't be meaningful to others who use this
application or read the report generated during the modeling process, so
giving each theme a meaningful name should be a priority. By making a
theme active in the Arcview Table of Contents and clicking *Theme* --
*Properties*, on the default Arcview GUI, a more meaningful name, such
as *Major Hiking Trails* can be entered. It is most useful when the
theme's name actually describes the content of the theme. In the case
described above, trls01.shp might contain all trails within the park,
but if a theme definition query has been applied, removing everything
except major trails from the view, *Major Hiking Trails* effectively
describes the theme's current content.

# Application Software Requirements

-   Arcview 3.2a or higher

-   Spatial Analyst

-   Sensitive Areas Management extension

**Application Optimization Suggestions**

It has been documented that a running Lotus Notes application can cause
problems with a running Arcview application. This has been fixed in
Arcview 3.3, but if using an earlier version of Arcview, it is
recommended that Lotus Notes be closed before running this application.

# Model Setup and Administration Menu

The **Model Setup** **and Administration** menu is where the entire
model process is managed, from data setup to the final overlay analysis.
The menu consists of six functional areas, each of which can be
interacted with during the model process.

![](media/image1.png){width="5.997916666666667in"
height="3.8694444444444445in"}

Figure 1

Model Setup and Administration Menu

-   *Details Section*. This is the top portion of the menu and is empty
    by default. All of the theme-based settings are displayed in this
    section, which consists of one row for each theme present in the
    *Sensitive Areas Model (SAM) Source Data view* and one column for
    each type of setting. Starting on the left side of the Details
    Section, the columns are Theme Name, Category, Buffer Distance,
    Process, Weight, and Shape.

    -   *Theme Name* is the name of the theme as it appears in the
        *Sensitive Areas Model (SAM) Source Data view* and will be
        referred to by this name throughout the model. If the settings
        are saved and reloaded at a later time, the theme names in the
        view must be the same. If a theme's name has changed, the
        application will not recognize it as the same theme.

    -   *Category* is the major category or classification that the
        theme falls in. All themes are undefined by default, but can be
        set to Visitor Use, Cultural Resources, Sensitive Habitat, or
        Wilderness. A single mouse click on the desired row will pop up
        a list of valid values to choose from. Choosing a category is
        not required for the model to run, but can be used to organize
        data into functional categories during the setup process and in
        post model reporting. The application has been designed with the
        assumption that additional categories may be added in the
        future. See **Application Administration** for further details.

    -   *Buffer Distance* is the distance that each spatial feature will
        be buffered. The default is *Do Not Buffer*. Themes with any
        valid shape type can be buffered by a user-defined distance,
        which is expressed in feet, meters, or the data's native map
        units and must be entered as a real number. If the source data
        is in UTM meters, then the buffer distance will also be in
        meters by default. Under normal circumstances, point and line
        based themes should be buffered, whereas polygon and grid based
        themes should only be buffered if it is determined to be
        necessary. For example, a theme of park trails would have very
        little impact on the model if it were not buffered by some
        distance since lines and points are dimensionless features and
        are more effectively represented when the size is increased. For
        example, a trail represented by a linear feature with no width
        may actually be effected by noise occurring within 1000 feet of
        the trail, so it should be buffered by 1000 feet to accurately
        model the trail..

    -   *Process* indicates inclusion in the current model. Since all
        themes in the Data Setup view are added to the Details Section,
        the *Process* setting allows each theme to be included or
        excluded. A single mouse click on the current setting will
        toggle between "yes" and "no". For example, the model may be run
        once with a target date of July 1. If it is determined that all
        themes in the view represent entities that will be present on
        July 1, then the *Process* value for each theme should be set to
        "yes". If the model is run again, but with a target date of
        January 1, some of the Sensitive Habitat themes may not be
        valid. In this case, the *Process* value for each of the themes
        that represent entities not present on January 1 should be set
        to "no".

    -   *Weight* is an optional setting that is only valid when running
        a *Weighted Overlay Analysis*, which requires that the *Standard
        Overlay* be completed first and is described elsewhere in the
        documentation. When running a *Standard Overlay*, this column is
        ignored and each theme has a value of 1, indicating that no
        theme is more significant than any other.

    -   *Shape* is included for informational purposes only and cannot
        be changed by the user. When evaluating a list of themes, it is
        helpful to know the shape type of each theme and can be
        important when deciding if a Buffer Distance should be set.

-   **Load Theme Settings (1)**. This section provides functionality to
    load the list of themes from the *Sensitive Areas Model (SAM) Source
    Data view*, load *from Last Completed Model* (only if one has been
    run), or an *Archived Model*. Optionally, settings can be saved for
    later use if the model will not be run immediately. If running the
    model now, settings are automatically saved. *Load Theme Settings*
    is the first step that must be completed.

    -   **Load From Sensitive Areas Model (SAM) Source Data view**. All
        themes currently in the Sensitive Areas Model (SAM) Source Data
        view are loaded into the Details Section of the menu and default
        values are set for each theme when this option is chosen. If
        themes have already been loaded from the Setup Table, the user
        can optionally choose to add new themes only. For example, if a
        model has been configured and run previously, but one additional
        theme has just been added to the view, the user could first load
        saved settings from the Settings Table, then load the new theme
        from the Sensitive Areas Model (SAM) Source Data view. Any of
        the settings designed to be interactively changed by the user
        can be changed once the defaults have been initialized for this
        new theme.

    -   **Last Completed Model**. A predefined table will be created the
        first time the extension is used and is designed to persist
        saved settings from one session to another. The table
        (nsmodelsetup.dbf) is created in the system's temp directory and
        is automatically recreated by the extension if it has been
        deleted. The assumption is that the list of themes and most
        settings will rarely change. Once each of the parameters has
        been set, the settings can be saved to the table and reloaded at
        any time for use in another model. Each time the model is run,
        themes can be included or excluded from the process and specific
        settings such as Buffer Distance can be modified. To load from
        the Setup Table, each theme referenced in the table must be
        present in the Sensitive Areas Model (SAM) Source Data view. If
        one or more referenced themes are not present in the view, those
        particular settings will not be loaded.

    -   **Archived Model**. Once a model has been completed, the
        settings table is copied to the archived model's directory and
        can be reloaded at any time. When a standard overlay model is
        run, a date/time stamped (unique) directory is created. Inside
        this directory, subdirectories named *buffered, converted,
        reclassed, and final* are created to hold data created during
        various stages of the model process. To load an archived table,
        navigate to the *final* directory of the desired archived model
        and load nsmodelsetup.dbf. Since the archived directory names
        consist of a unique date and time, you may wish to rename it to
        something more meaningful and document the purpose of this
        specific version of the model so it can be located later.

    -   **Save**. This overwrites any currently saved settings in the
        Settings Table with settings in the Details Section of the menu.
        The table is saved automatically each time a model is run, but
        can be saved at any time by using this button.

-   **Buffer Distance Units (2).** User provided source data for this
    model is stored in specific Map Units, such as meters, and can be
    identified in the *View \-- properties* menu. By default, all
    distances are expressed in your data\'s native map units, but this
    can be changed. Below are some typical scenarios:

    -   Map Units are unknown or are not set in *View \-- Properties*.
        In this case, select *Other* and it will be assumed that
        user-defined buffer distances are expressed in the same units as
        the map units. For example, data is in decimal degrees, so
        buffer distances must be entered in degrees.

    -   Map Units are feet or meters. In this case, buffer distance
        units can be entered in either feet or meters and units will be
        converted to map units.

    -   If the wrong combination of map/distance units is used, such as
        map units = unknown and *Buffer Distance* units = feet), a
        warning message will prompt the user to modify these settings.

-   **Output Data Settings (3)**. This part of the menu sets parameters
    for the output data created the model process. Each of these
    settings is required before the model can be run.

    -   **Working Directory**. All data created for the purpose of
        generating the final output model is written to the working
        directory. By clicking on this button, the user can navigate to
        an existing directory or create a new directory to function as
        the top-level working directory. During the model process,
        several subdirectories will be created (Figure 2). To guarantee
        uniqueness, a new subdirectory will be created each time a model
        is run and is composed of a combination of date and time values.
        When sorted chronologically, the most recent model will appear
        at the bottom of the list of subdirectories. Within each model
        subdirectory, directories named *converted, buffered,
        reclassed*, and *final* will be created to hold data generated
        during each stage of the modeling process. They have been named
        logically such that the user knows which directory contains
        which type of data. Data initially converted from vector to grid
        will be put in *converted*. Themes with a buffer distance
        specified will be buffered and put in the *buffered* directory.
        All converted and buffered data will be reclassified to ensure
        that values are either 0 or 1 (non-weighted). All reclassified
        data will then be combined to form the final model output.

![](media/image2.png){width="3.113888888888889in"
height="5.218055555555556in"}

> Figure 2 Output Directory Structure
>
> The grid data model does not support spaces and most special
> characters anywhere in the full path to the source data and could
> cause unpredictable errors if they are present. For example, if a grid
> containing bald eagle nesting areas is located in C:\\Glacier National
> Park\\Data\\bald_eagle, the theme would not load into Arcview
> correctly. Arcview will not allow you to load data from a directory
> with spaces and the Working Directory tool will not allow you to
> choose a directory with spaces.

-   **Overlay Extent Theme**. Each time the model is run, themes of
    different spatial extents can be included. To limit the analysis
    extent, a theme representing the park boundary or any other logical
    spatial extent can be used to define this setting. The overlay
    extent theme must be present in the Sensitive Areas Model (SAM)
    Source Data view and the *Details Section* of the menu, but can have
    a *Process* setting of *no* to be excluded from the model. For
    example, the Park Boundary theme makes no contribution to a
    Sensitive Areas Analysis process other than to define the area of
    interest, so it should not be included as one of the *sensitive*
    areas.

-   **Resolution (Cell Size)**. Each theme converted during the modeling
    process is converted to a grid, which is a cell-based raster data
    format. The output cell size must be set before running the model to
    ensure that each output data set has the same cell size. The cell
    size is in map units, so if using data in State Plane feet, the cell
    size will also be in feet. If a cell size of 100 feet is entered,
    each cell in the output data sets will be 100ft by 100ft. The cell
    size can be set by moving the slider, using the left and right
    buttons, or typing a number in the input box and hitting enter on
    the keyboard. A smaller cell size will result in a higher
    resolution. A larger cell size will result in a lower resolution.
    Increasing the resolution also increases the amount of storage space
    and computation time required. Reducing the cell size can improve
    the resolution, but the output theme will not be more accurate than
    the maximum cell size of the input themes. When testing various
    parameters and running multiple iterations of the model (Draft
    Mode), it might be beneficial to choose a larger cell size. When all
    of the parameters have been set and you are ready to generate a
    final model for presentation, a much smaller cell size will produce
    a more aesthetically pleasing product, but will take longer to
    generate. There is no exact science that indicates the most
    appropriate cell size, but considering the type and resolution of
    input data can help. For example, if several detailed point and
    linear input themes are being used and have a small buffer distance
    (\~50 meters), then choosing an output resolution of 100 meters may
    be too coarse. A sub 50-meter resolution would be more appropriate
    in this case. If the buffer distances are in the 500-meter range,
    then a 60 to 100 meter cell size might be appropriate when in draft
    mode.

```{=html}
<!-- -->
```
-   **Standard Overlay (4).** Once all of the settings have been
    specified the *Standard Overlay* process can be run. This step first
    checks for required parameters, runs the data conversion and
    preprocessing steps, and creates the standard overlay data
    (non-weighted).

    -   **Convert Data and Create Standard Overlay Model.** This takes
        all of the themes and settings saved to the Setup Table and runs
        the model. Data is converted from vector to raster, buffered,
        and reclassified. Several factors, such as output cell size,
        number of themes, location of themes (local or network), and
        complexity of data will influence the processing time. When the
        preprocessing has finished, all of the layers are added together
        resulting in a single output data set. Each theme input into the
        model represents areas of interest and is converted to a
        standard format showing either presence or absence of the entity
        represented by the theme. For example, a shapefile-based theme
        representing linear trails throughout the park is first
        converted to a grid. Since lines are dimensionless, it probably
        makes sense to buffer them. Otherwise the lines will have very
        little impact on the final model. Each trail feature is
        converted from a linear feature to a set of contiguous grid
        cells and then buffered by the specified buffer distance if one
        has been entered. The result is a new grid layer with a larger
        area of influence instead of just the trails themselves. Each
        output grid cell can only have values of 0 or 1, indicating
        presence or absence. The overlay process ignores any weights
        that have been assigned and gives each data in each theme a
        value of 1. The standard model process combines all input grids
        after each input has been converted and preprocessed. The output
        data set is a continuous grid representing the sum of values
        from all of the input themes at a given location. This step is
        required before the *Weighted Overlay* process can be run.

> If any of the input themes have selected features, only those features
> will be used in the model. If a theme does not have selected features,
> all features present in the Sensitive Areas Model (SAM) Source Data
> view will be used. If the application detects selected features, it
> will tell the user which themes have selected features and allow the
> process to be stopped so selections can be removed or adjusted if
> necessary. For example, the user may have performed a query on the
> roads theme, resulting in a selected set consisting of a single road
> segment. If a *Standard Overlay* model is then run with roads as one
> of the input themes, only the selected road would be used by the
> model. This process allows the user to discover any unwanted
> selections or theme definitions and remove them if necessary. The user
> may also choose to continue with the selection if the selected set is
> valid for the current model.

![](media/image3.png){width="5.993055555555555in"
height="3.432638888888889in"}

Figure 3 Standard Overlay Model output grid combined with a hillshaded
DEM for display enhancement. In this view, dark red areas are more
sensitive than light areas.

-   **Weighted Overlay (5)**. This step is necessary if the user wishes
    to assign weights to specific themes, causing the model to treat
    them as more influential than others. The process is exactly the
    same as the *Standard Overlay*, but allows values other than 1.
    Because the *Weighted Overlay* uses the preprocessed data generated
    by the Standard Overlay process, this function requires that at
    least one *Standard Overlay* be completed first.

    -   **Enable Weighted Overlay**. Enables the *Run Weighted Overlay*
        button and tells the model to honor the values in the *Weight*
        column of the menu's *Details Section*. By default, and when
        this is not checked, the *Weight* column is displayed, but the
        values are not used. The status message immediately below the
        checkbox will change and the icon will change from red to green
        when the *Weighted Overlay* functionality has been enabled,
        which decreases the likelihood of running a *Weighted Overlay*
        by mistake..

    -   **Run Weighted Overlay**. This takes data converted during the
        *Standard Overlay* process and using the assigned weights,
        creates a single *Weighted Overlay* theme. Each time a *Weighted
        Overlay* process is initialized, the system will attempt to
        locate the last completed Standard Overlay output. If one has
        not been completed during the current session, the user will be
        prompted to locate the last completed model. Each time a
        *Standard Overlay* model is completed successfully, a file
        called *completed.mdl* is written into the current working
        directory's *reclassed* subdirectory. If running the application
        for the first time today without first using the *Standard
        Overlay* function, the user must browse to a previously
        completed model directory with this file. After browsing to this
        file, the system will be able to locate the completed *Standard
        Overlay* grid and its associated input data. Since the same
        input data may be used to generate multiple *Weighted Overlay*
        grids, this process can be run more than once in the same
        directory and creates a user-named output grid in the *Final*
        directory. By default, the first *Weighted Overlay* grid is
        called *Weighted01*. The user is free to continue this naming
        convention with additional *Weighted Overlays* or can use any
        other unique output name. The grid data format has a
        13-character name limit and does not allow spaces or some
        special characters. To change one or more input themes or to
        alter buffers, the **Basic Steps** must be run again.

#### Running the Model 

######### 

######### *Seasonal Scenarios*

The model user can easily explore seasonality issues through adjustments
of theme settings. The *process* setting can be toggled on/off to
include or omit themes for a particular analysis. For example, the
incubation period of nesting bald eagles can be turned 'on' to analyze
the period March 15 -- April 15 when incubation is occurring. Model runs
for April 16 -- March 14 might have this theme turned 'off' in the theme
setting. Another example is the toggling of backcountry trail and
campsite use to coincide with the appropriate use season.

######### *Weighting Model Inputs*

As with toggling the *process* switch to accommodate seasonal concerns,
the user can apply the model's weighting functionality to provide a
sense of relative resource value to model outputs. For example, National
Landmark Status properties may be considered of greater resource value
than List of Classified Structures (LCS) properties and are set to a
weight of three, while the LCS data is not weighted. Another example is
wildlife habitat. In Glacier National Park, grizzly bears are protected
under the Threatened and Endangered Species Act. Grizzly bear summer
habitat has been delineated through the Montana GAP project to include
approximately 90% of park. Research has documented that in late summer
bears are drawn to high-elevation talus slopes to feed on Army cutworm
moth colonies. GIS data describing known moth aggregation sites can be
weighted to provide a sense of relative habitat value, as compared with
the GAP data.

####### *Data Management*

The model generates lots of new GIS data and the user has little control
in naming these files. These data are saved to one folder, containing
well-organized subfolders, that is named by the date and time the model
is run. Take a few moments to consider where this folder will be
located. Also, there are no provisions for generating metadata for model
outputs. It is recommended that metadata is developed to document the
resulting model output data.

#### Model Output

#### 

### Data Structure

The *Standard Overlay* output, a grid named *Standard*, was designed to
capture a record of all input values and their source for each grid
cell. Because of the need for this 'record' of the output's origins, its
structure had to be altered from that of a typical grid. Normally, the
*value* column contains values of interest for a grid, but the user is
able to add additional attribute columns as needed. Because of the
methods used to capture the required data, the *value* column only
contains arbitrary id values used internally. The most useful field in
the output *Standard* and *Weighted* grids is one called *total* and
contains the total value or sensitivity for each cell. Fields with the
same name as each input grid have been added to the output grid and
contain references to the original values for each cell, allowing the
user to determine where each value originated. These are the abbreviated
names recorded in the NSModelSetup.dbf table, which is copied to each
model's *Final* directory for future reference. See **Load Theme
Settings From Archived Model** for more information about the output
directory structure. For example, a model may consist of five input data
sources with a total value of two at a particular location. By looking
at the new fields, it could be determined that the trails and roads
themes each contributed a value of one for that location and when
combined result in a total of two. When a grid theme is added to
Arcview, its value field is used as the primary display field by
default, but manipulating the new theme's legend can change this. A
custom legend file (*standard.avl*) is generated and applied to the new
theme each time the *Standard Overlay* grid is generated. If the project
is saved and reloaded at a later time, the classification will still be
present. A custom legend is also generated for the shapefile
representation and is loaded with the theme each time it is added to a
project, because it has the same prefix as the theme. This default
behavior does not work with grid-based themes, so if added to the
project at a later date, the *Standard* grid theme can be displayed
correctly by loading the custom legend from the same location as the
data set.

#### *Output Resolution*

The user controls the model's output grid resolution. This setting
determines the cell size for data conversion to grids and also
determines the final overlay grid resolution. It is recommended, to
speed the model's performance, that the *cell resolution* setting is
kept high during preliminary model runs. The cell size can be lowered
when data inputs and settings are acceptable and the user is ready to
produce final products.

######### 

######### *Output Cartography*

The Sensitive Areas Model generates overlay grid products that are
subsequently converted to shapefile format to facilitate graphic
rendering of the model results. It is recommended that the model results
get draped over a shaded relief image to provide a sense of terrain
where applicable. The output shapefile should be rendered with
transparent fill patterns to optimize the visibility of the underlying
terrain.

**Use of Output Products**

-   Cost distance analysis to determine flight routes.

-   Enhanced terrain analyses.

# Example User-Scenario

1.  Open the *Sensitive Areas Model (SAM) Source Data view* and add
    themes from disk or copy from other views. Each theme should be
    given a unique and descriptive name so anyone can easily interpret
    its content. There are no specific data requirements, although
    recommended guidelines have been provided and are located elsewhere
    in this document. There are two general types of data that can be
    included in the model:

    -   Model inputs. All data to be used in the model, including
        points, lines, polygons, and grids, should be loaded into the
        view. If the themes already exist in another view, they can be
        copied to this view without actually copying the source data to
        a new location.

    -   Boundary theme. The park boundary is an example of the boundary
        theme and does not have to be included in the model for any
        other purpose, meaning that it can be excluded from the additive
        overlay process. This standardizes the model's analysis extent
        to be equal to this theme's extent and enables the inclusion of
        much larger data sets without increasing the spatial and
        physical size of the output. The boundary theme can be any
        feature type since the theme's extent is all that is being
        considered.

2.  From the *Sensitive Areas Management Model* pulldown menu on the
    standard Arcview GUI, choose *Open Model Setup and Administration
    Menu*. The *Details Section* of the menu will be empty when
    initialized.

3.  The *Details Section* can be populated by loading themes from
    either:

    -   The *Quiet Places Sensitive Areas Model (SAM) Source Data view*.
        Use this option if running the model for the first time or if
        themes have been added or removed since last running the model.

    -   Settings saved with a completed model. Use this option only when
        at least one model has been successfully completed. Theme names
        in the view must match those in the saved settings table.

4.  Assuming this is being run for the first time, load from *Data Setup
    View*. The details section will be populated with default settings
    for each theme present in the view.

5.  Theme preferences can be set in any order and are not applied until
    the model is run. Each row of settings corresponds to one theme.

    -   Start with the *Category* column and click on each
        *\-\-\--Undefined\-\-\--* text and select a category from the
        list. For example, Trails fall within the *Visitor Use*
        category.

    -   Set a buffer distance for each theme that should be buffered.
        Trails will be buffered by 500 meters. Leave the default value
        for themes that will not be buffered.

    -   Next, decide whether each theme should be processed by toggling
        yes/no values in the *Process* column. To exclude a theme due to
        seasonality, leave the default value of *no* in place.

    -   Values in the other columns cannot be changed, with the
        exception of *Weights*, which can be used later in the process.

6.  When finished setting theme preferences in the *Details Section*,
    hit the *Save* button to save the current settings to the setup
    table.

7.  Set *Buffer Distance Units*. The coordinate system for the Glacier
    NP test data is UTM and the map units are meters, which is set in
    the Arcview *View -- Properties* menu. Buffer distances are entered
    in feet, so the *feet* radio button will be selected. Choose units
    appropriate for your data.

8.  Now update the *Output Data Settings* at the bottom of the menu.

    -   Select the Park Boundary theme in the *Details Section* and
        click the *Overlay Extent Theme* button at the bottom.

    -   Click the *Working Directory* button and navigate to a writeable
        directory for output data to be created in. For example, to
        select the E:\\temp directory, navigate to E: and select Temp in
        the folder list below, but don't double click the Temp
        directory. Remember not to choose a directory with spaces
        anywhere in the full path name.

    -   Set the *Resolution (cell size)* to an appropriate number. This
        number is in the source data's map units. Setting this high will
        result in faster processing time, but the data will be coarse.
        Setting a small cell size will cause the processing time to
        increase, but the output resolution will be more detailed. When
        running multiple 'What If?' scenarios, it is recommended that a
        larger cell size be used for performance reasons. It may take
        several iterations to determine optimum cell size in order to
        balance performance and accuracy since this is dependent on the
        spatial extent and level of detail within the input themes.

9.  Continue on to the *Standard Overlay* section and run the *Data
    Conversion and Standard Overlay* function. Press this button and
    notice the status window that pops up informing the user of its
    progress. If a query has been performed to filter displayed
    features, the application will give the user the option to stop and
    remove the selection. This will help identify themes with selections
    or theme definitions that may have been forgotten. If the input data
    is large or if using data on network drives, the conversion and
    overlay process can take several minutes or longer. Status messages
    will inform the user of progress and identifies each theme as it is
    being processed.

10. Upon completion, you will be prompted to add the Standard Overlay
    theme to a view. This is the final result of the conversion and
    *Standard Overlay* process. Hit *yes* and select a view from the
    list when the application generates a list of all views in the
    current project. If adding this to the Sensitive Areas Model (SAM)
    Source Data view, remember to remove it from the view or exclude if
    from future models by setting its *process* value to *no*. It is
    unlikely that the Standard Overlay result would be useful as an
    input theme in another model.

11. To perform a *Weighted Overlay* analysis, check the *Enable Weighted
    Overlay* checkbox. Do not attempt to change settings in any column
    other than the Weight column as these settings are only used when
    preprocessing data and generating the Standard Overlay grid.
    Weighted Overlays only use data that has been preprocessed.

12. Click on each weight that should be changed from the default value.
    If weights have been set during previous runs, they will be still be
    present and can be used in a *Weighted Overlay*. Each weight should
    be an integer value and will be applied to the entire theme. If this
    is the first weighted overlay being run since running a *Standard
    Overlay*, the output grid will be called *Weighted01*. Each time
    thereafter, you will be prompted for an output name, which can be
    any unique string 13 characters or less with no spaces or special
    characters. The processing time is much less than that for the
    standard overlay because all input data has already been
    preprocessed.

13. When finished, the same prompts that followed the *Standard Overlay*
    creation will be presented. You will be asked if the output data
    should be added to a view as a theme. These procedures were
    discussed earlier in the documentation and can be referenced for
    more information. As with the *Standard Overlay*, the *Weighted
    Overlay* grid is added to the view as a new theme and can be further
    processed or analyzed with standard Arcview tools.

## Next Steps

Once the Standard and Weighted Overlay products have been generated,
there are an unlimited number of paths that can be followed to make
further use of the data. Below are some of the possibilities.

1.  Convert Standard Overlay and/or Weighted Overlay grids to shapefile
    to better accommodate presentation-quality mapping. Raster data can
    look blocky, since the data is based on square cells. When converted
    to the vector shapefile format, the blocky edges tend to be rounded
    off and can look much better when using in a presentation. This
    conversion is done automatically upon successful completion of the
    model and allows either the grid or shapefile format to be used for
    post-model display and analysis.

2.  Reclassify values into something more meaningful. For example, the
    values in a Standard Overlay grid might range from 0 to 20, with 20
    being the most sensitive areas. This may be more detail than the
    average user wants, so reclassifying the data into simpler values,
    such as 1, 2, and 3, where 1 represents values 0 -- 7, 2 represents
    8 -- 15 and 3 represents 16 -- 20. Reclassification results in a new
    data set and does not retain the original values in the new data
    set. There is an easier way to accomplish this. Double-click on the
    theme's legend in the view's table of contents to open the legend
    editor. Change the legend type from *Unique Value* to *Graduated
    Color*. Hit the *Classify* button to change the number of classes
    from the default number (usually five) to three (or any appropriate
    number). Next, change the value range and labels to match. Using the
    above example, values 0 -- 7 would be labeled Low, 8 -- 15 labeled
    Moderate, and 16 -- 20 labeled High, which might make more sense to
    an end user. For more information on changing a theme's legend,
    search the Arcview Help Index for *legends*.

3.  Create a histogram of values by management zones. To further examine
    the distribution of sensitivity values throughout the park, load a
    polygon theme representing park management zones or any other type
    of management area. First make the polygon theme active in the table
    of contents. Next, under Arcview's *Analysis* pulldown menu, choose
    *Histogram by Zone*. The result is a chart document illustrating the
    range and distribution of values by zone.

4.  Cost distance analysis to determine flight routes.

5.  Enhanced terrain analyses.

# Application Administration

The current application consists of the following components:

-   An extension (Sensitive Areas Model.avx) created with Arcview 3.2a

-   An Arcview 3.2a project used to create the extension

-   Application documentation (SAM.doc) in the form of a Microsoft Word
    document.

> When the extension is installed and used for the first time, several
> tables are created in the system temp directory. Each time the
> extension is used, they are located and added to the project if not
> already present. If they cannot be located, each table will be
> recreated.

-   **ModelCategories.dbf** This table stores a reference to each valid
    model category and its associated abbreviated name. This list is
    presented to the user each time the *Category* column is clicked on
    the Model Setup and Administration Menu's Details Section and allows
    the user to choose one category for the current theme. During the
    data conversion steps, the abbreviated name is used to generate
    names for each data set. For example, if the Trails theme is chosen
    to be in the *Visitor Use* category, and is the first *Visitor Use*
    selection in the Details list, the converted data will be called
    *vis1grd* (short for Visitor Use 1 grid). If buffered, the output
    buffered grid will be called *vis1buff* and when reclassified, the
    output will be called *vis1recl*. This provides a consistent naming
    convention that allows easy identification of a theme throughout its
    model life cycle. Once a model has been completed, the converted and
    preprocessed data can be identified by referring to the values in
    this table. The categories and abbreviated names can be modified by
    editing values in the source table and new categories can be added
    by adding a new record to the table and providing both a category
    name and an abbreviated name.

-   **NSModelSetup.dbf** This table records user-specified theme
    preferences and is updated each time the model is run. Neither the
    user nor the administrator should directly edit this table.