UCD Information Center for the Environment

Department of Environmental Science and Policy

One Shields Ave

University of California, Davis

Davis, California 95616

Telephone: 530-752-1331 FAX: 530-752-3350

aethode@ucdavis.edu

Abstract

FACE is a new ArcView application which is a proof-of-concept prototype for decision support. FACE proves that an interactive GIS tool can be built for decision makers who have no GIS skills, yet whose use of GIS would enable them to learn more about the data related to the decisions they must make. The vision of FACE is to bring more science into group decision making for groups such as watershed committees or fire safe councils. FACE is designed to be operated on-the-fly at public meetings.

In ArcView, a person draws a polygon on a map of their area. Their area could be their community, their watershed, their county, etc. FACE (1) saves the polygon as a theme, (2) calculates the expected cost and the upper and lower bounds of the cost estimate, (3) provides the user a description of the chosen area in terms of characteristics which are important for determining costs, and (4) provides the user a notepad into which the user can write notes about the alternative implied by the polygon.

I. INTRODUCTION

Many California ecosystems have evolved with fire and are dependent upon fire for regeneration and continued growth. California also has a growing population of over 34 million people looking for a place to live. The conflicts between development and natural fire regimes are tremendous, and the threat of wildfire to the urban-wildland interface is of constant concern for resource managers and the public in California. Management of fuels, such as forest duff, dense tree and shrub layers and grasslands, is the main method of dealing with the threat of uncontrollable wildfire in the urban-wildland interface. However, fuel treatments can be complicated and costly due to issues of multiple land owner-ships, local regulations, and large amounts of fuel buildup due to fire suppression over the last century. The USDA Natural Resources Conservation Service and UC Davis Information Center for the Environment teamed up to help create a decision support tool for fuel treatments in California. This combined effort resulted in the creation of the Fire Area Cost Estimator (FACE).

II. THE BIGGER PICTURE

The general motivation for this work is to bring GIS functionality directly to decision makers who do not know GIS and are too busy to learn it. The GIS functionality is expected to enhance: communication clarity among the decision makers, communication clarity between the decision makers and scientists, use of science in group decision making, and the imagination decision makers use in planning for an uncertain future. In order to fully bring GIS to the group decision making process, alternative dispute resolution techniques such as mediation would be employed together with GIS to create a wholistic decision support system. The general vision is to combine human process techniques with science expressed through GIS.

FACE is part of a larger benefit/cost analysis called the Community Rate of Return Generator (C-RORGEN)(Figure 1). C-RORGEN consists of (1) a Rate of Return Generator (RORGEN) into which individual landowners place values for uninsurable items - such as baby pictures or mature trees - which are more likely to survive a catastrophic fire because of the vegetative management, (2) a statistical method for sampling individual landowners from a community so as to estimate community level benefits, (3) a GIS-based fire model such as FARSITE which will be used to identify the minimum critical management areas so as to minimize cost and maximize benefits.

II. DEVELOPMENT

FACE was developed in ArcView 3.1 using the Dialog Designer and Spatial Analyst Extensions with some pre-processing of data done in ARC/INFO GRID. The development of FACE can be broken into two major parts: A) The User and System Interface and B) the Cost Estimation. These two parts are discussed below.

A. The User and System Interface

The goal for the user interface was to create a simplified ArcView interface for inexperienced users to be able to select an area for fuel treatments (Figure 2). The FACE interface was created using Avenue and Dialog Designer to lead the user through the steps of creating a new polygon theme in an area where they wish to know the cost of fuel treatments. The user is first given the choice of creating a new area or recalculating and old area. To create a new area the user can choose from the following options: 1) a rectangle can be drawn, 2) a circle can be created, 3) a circle of a specified radius can be placed, or a feature can be buffered (Figure 3). Once the area is drawn in the main view the cost estimation, described below, is done and an output dialog is created (Figure 4). If the user wants to save the cost estimation information they are allowed to write notes about the area and then all the information is written to a system text file that is given the name of the area plus a date time stamp. The user interface is short and simple, which was the intent in targeting inexperienced ArcView users. All the scripts for the interface are loaded on the fly into the project and then FACE loads all data into the Main View and Grid View (discussed below), sets legends and sets system directories.

In order to make FACE mobile with data and files intact, an executable was developed using the “Install Shield” software that lets the user place FACE where they wish on their system and then loads the proper data directory structure. When the user chooses the location for FACE, a system variable (FACE) is set to that location (for example SET FACE = C:/USERFILE/FACE). The system variable is written into the user interface scripts to load and write data to and from ArcView. This set-up is quick and prevents the user from having to deal with directory structures and locations.

B. Cost Estimation

How much does it cost to reduce the fuel load? The answer always is: "It depends." This method uses GIS and expert interviews to identify the various conditions upon which costs depend. There are three sections in this discussion about the cost estimation method. The first section gives an overview of cost estimation. The second section describes the cost estimation work. The third section presents the method used to allow user-defined cost estimation.

B.1 Overview

The cost estimation goal of FACE is to interactively respond to a person's individually drawn polygon by estimating the cost of doing the pre-fire work within that polygon and summarizing some of the data which explain the conditions within the polygon that determine cost. The estimator gives three cost figures: most likely cost, lower bound cost, and upper bound cost. The goal is to estimate costs at a planning level in order to allow decision makers to rank areas in terms of costs. Ultimately, decision makers will need both cost and benefit estimates. FACE is a first step in the direction of creating a more complete economics tool.

Basically, the cost estimation method involves using existing GIS data and interviews with pre-fire experts in order to develop expert decision rules about estimating costs given the GIS information.

B.2 Cost Estimation Work

There are two parts in the cost estimation work. The first part concerns gathering the information, both the the initial GIS data and the expert rules-of-thumb for estimating cost. The second part of the cost estimation work is the ArcInfo data manipulations which are expressed in AMLs.

B.2.1 Information Gathering: There were four steps in the process of gathering the data and expert decision rules necessary for FACE.AML

(1) Original Data: These are defined in Appendix A. The first step was to inventory available GIS data. The direction of the expert interviews was determined by the available data. The original data were both grid and vector.

(2) Expert Interviews using Original Data: Having the available data defined, the second step was to frame the questions asked of the experts in terms of both the goal of estimating cost and the available GIS data. For example, although the watershed has two major vegetation types - trees and manzanita - which are significant fuels, the available vegetation data only contained percent tree crown cover. Thus, in interviewing the experts, we knew we had to establish rules-of-thumb which would compensate for the missing data.

(3) Cost Characteristics Grids: These are defined in Appendix B. These are the grids read by FACE.AML. These grids have a prefix "cch", cost characteristics.

From the expert interviews, we were able to distinguish cost characteristic rules which were applied to the original data in order to create the cost characteristics grids. For example, the experts generalized the effect of stream proximity on cost. In the Tahoe Basin, a location with a given set of characteristics that is "close to a stream" is more expensive to manage than a location with the very same set of characteristics but is "far" from a stream. The institutional rules in the Tahoe Basin require that fuel management "close" to a stream can only be done by hand. No machinery is allowed. Thus, the stream vector coverage was buffered to account for the stream proximity consideration. The buffered vector coverage was converted to a cost characteristic grid in which a cell’s value = 1 when that cell is "close" to a stream and value = 0 when far from a stream.

(4) Expert Interviews using Cost Conditions Worksheet: After the cost characteristics grids were created, another interview was conducted to estimate the relative importance of each cost characteristic to total cost. The goal was to obtain weights of importance in cost estimation.

We used a huge worksheet (30" X 36") which contained a data tree. Each level of the tree is a GIS data layer. Each level of the tree was broken into the cost characteristics derived for each of the cost characteristics grids. Thus, for example, consider slope. In this watershed, slope ranges from zero percent to 310 percent (about 80 degrees). For the purposes of cost estimation, slope was defined into four slope characteristics: 0 - 10% "low slope", 10 - 30% "medium slope", 30 - 70% "high slope", 70 - 310% "very high slope". Thus, the data tree level for slope contained four slope categories.

The worksheet was used by the experts as a scratchpad to look wholistically at the weights for each cost characteristic. For example, consider slope. When a grid cell contains low slope, then slope, in and of itself, contributes nothing to the total cost. However, when a grid cell contains very high slope, then slope, in and of itself, contributes significantly to cost estimation (all other things equal). The worksheet was used to limit the second expert interview to assigning relative weights to each characteristic. These weights were hard coded into FACE.AML as the default values.

B.2.2 ArcInfo Grid Work: The grid work is documented in FACE.AML which is provided in Appendix C. This AML produces the final grids which are placed into FACE.APR. The AML does four things.

(1) Cost Condition Grids: FACE.AML reads the cost characteristics grids (the "cch" grids) and applies weights for each cost characteristic and creates cost condition grids. The cost condition grids have a prefix of "cco", cost conditions. The final grid, the total cost condition points grid and the only cost condition grid used later, is named CCOTOT. It contains, for each cell, the total number of cost condition points. The minimum value is zero. This applies to a cell which has zero cost conditions. For this cell, we already know that the total cost will be zero dollars per acre. The maximum value, given the cost condition points assigned for each characteristic, was 15. When the total cost condition points for a cell is 15, it means that this cell is the nightmare vegetation management cell. It has the highest cost characteristics: high slope, close to stream, far from a road, and it's a small parcel.

(2) Cost Condition Points: FACE.AML offers the user the opportunity to change the default values for the weights assigned to each cost characteristic in order to produce the cost condition. Again, consider slope as an example. Suppose the default weight for "medium slope" is 2. However, suppose a particular user thinks the weight should be only 1. FACE.AML allows the user to interactively change the weight. The resulting cost condition grids would use the new, interactively provided, weight. When the user changes the cost condition weight, the cost conditions total points grid, CCOTOT, is recomputed.

(3) Cost Category Table: FACE.AML requires that a text file named COSTCAT.DAT exists on the working directory. COSTCAT.DAT is presented in Appendix D. COSTCAT.DAT is the default remap table for the GRID RECLASS command in which the cost conditions total points grid, CCOTOT, becomes the first of three cost per acre grids, EXP_CPA.

If a new CCOTOT grid has been computed because a user has changed the cost characteristic weights, then FACE.AML recomputes the boundary values of the five cost categories and edits COSTCAT.DAT to insert those new boundary values. Or, if the user to interactively redefines the cost/acre for any of five cost categories, then FACE.AML inserts the new cost values into COSTCAT.DAT.

(4) Cost Grids: There are two steps in calculating the three cost grids needed by FACE.APR. First, FACE.AML computes three cost per acre grids. It does this by using the GRID RECLASS command to obtain the first cost per acre grid which is named EXP_CPA and is the expected cost per acre. The LO_CPA and HI_CPA grids are obtained from EXP_CPA by multiplying by an error factor. The error factor is a + value which comes from expert interviews about the quality of the GIS data and the quality of the rules-of-thumb for estimating costs at a planning scale. Second, FACE.AML computes the total cost per cell by multiplying the cost per acre grid by the acres grid. All three cost grids, expected cost, low cost, and high cost, use the same equation. For the expected cost grid, the equation is:

EXP_COST = (EXP_CPA * ACRES0000) / 10000

B.3 User-Defined Cost Estimation

This section describes the ArcView Avenue work which makes the cost estimates available to the final user's individual polygon. Because the cost calculations were done in ArcInfo, the only Avenue cost work involved creating the clipping shapefile, clipping all of the grids, and summarizing the numerical values from the value attribute tables of those grids. This is done in the background in a new GUI called Grid View. Grid View is a clone of the View GUI, but is hidden to the user (Figure 5).

IV. FUTURE RESEARCH AND DEVELOPMENT

A. Improved Data and Decision Rules

Currently, NRCS and ICE are working with the California Department of Fire Protection (CDF) to better develop decision rules and to acquire better data for the implementation of FACE. Ideally, FACE would be implemented in a watershed using GIS information at a planning scale. Attention to data quality issues, specifically error propagation and its effect on the range of output values will continue to be areas of data development. Equally important will be the specification of decision rules used when data are missing. CDF has indicated that development of fuel treatment choices would be useful. Currently, FACE estimates cost based on the “cheapest” treatment. This change requires more discussion of decision rules with local fuels managers, but not a complete reorganization of the system.

B. INTERFACE – Linking Benefits and Costs

Another future goal for FACE is to expand the GIS economic analysis to include benefits coming from the selected polygon. Specifically, the goal is to connect FACE to FARSITE, a GIS-based fire behavior model. We might name this system "InterFACE". InterFACE would use the user-defined polygon to clip a post-fuel load reduction vegetation layer to simulate fuel reduction in that area. The result would be a grid of vegetation values representing ideal fuel reduction for that polygon. INTERFACE would then merge the post-reduction polygon-defined grid with the pre-reduction grid of the rest of the watershed. The result would be a grid of vegetation values representing fuel reduction for the chosen polygon and existing vegetation condition for the surrounding area. INTERFACE would send this mixed grid to FARSITE. FARSITE would then simulate fire behavior around the fuel treatment allowing the “benefit” of the fuel treatment to be seen.

As FACE currently exists, it is simple and requires very little GIS knowledge by the user. Future development will depend upon the interest of CDF and the value of FACE to their decision-making processes and their ability to communicate with the public.

APPENDIX A: ORIGINAL DATA AND BASIC DERIVED DATA

We obtained the data from the USDA Forest Service (FS) within the Lake Tahoe Basin Management Unit and USDA Natural Resources Conservation Service. The following is a list of the original data with the data name in bold print and data source in parenthesis. These data were used to create the cost characteristics grids.

Original Data:

dem_10m (USDA FS) 10 meter DEM from which we derived the slope grid.

baileys (USDA FS) Polygon coverage of Bailey's Classification: If a parcel is classified as Baileys 1 or Baileys 2, then the Tahoe Regional Planning Agency forbids mechanical treatment unless there is 12 inches of snow pack. Baileys = 1 or 2 when slope is sufficiently steep, or when parcel is sufficiently close to a stream, or when drainage is poor, or when the flora/fauna is fragile. In this cost estimation method, Baileys classification is used as the residual information for those locations which are classified as sensitive even though the slope is relatively flat and far from a stream.

vegtypes (USDA FS) Vegetation Density: This was 9 year old data. It contained only tree density. It lacked understory information. In this watershed manzanita understory is a very important determinant of wildfire behavior. Thus, this data layer introduced errors which understate the most likely costs.

parcels (USDA FS) Parcel polygon coverage: This was used to distinguish small parcels from large parcels. The smaller the parcel, the more costly is the per acre pre-fire management.

roads (USDA NRCS) Road line coverage: Digitized from USGS quad map.

streams (USDA NRCS) Stream line coverage:

watershed (USDA NRCS) Watershed boundary was digitized by MMRansom from delineation made by Vern Finney, USDA NRCS geologist.

Basic Derived Data:

snow (USDA NRCS) Derived snow grid: The whole watershed receives substantial snow during the winter. The snow grid was a reclassification of the slope grid. When slope < 30 percent, pre-fire activities using machines are permitted when there is 12 inches of snow. A grid cell with VALUE = 1 had a slope < 30 percent. Such a cell had a 25% (3 months out of the year) chance of experiencing mechanical fuel removal. Such a cell would be less expensive to treat.

acres (USDA NRCS) Derived sloped acres grid: This was derived from the DEM, calculating sloped acres. A cell with zero slope was estimated to have 100 square meters, or 0.007 acres, of land. However, a cell with the maximum observed slope of 80% was estimated to have .34 acres of land.

APPENDIX B: COST CHARACTERISTICS GRIDS

FACE.AML needs the cost characteristics grids, the “cch” grids, plus the acres grid. Because this watershed had very steep slopes, a sloped acres grid was created.

*Name of Grid*	*Type of Grid*	*Values* (The cost increasing characteristic receives VALUE > 0)
cchdense	integer	0 = vegetation not too dense, no costs 1 = vegetation is too dense, need to incur costs null = outside watershed
cchslope	integer	0 = 0% - 10% slope, no slope component to cost 1 = 10% - 30% slope, slope component exists 2 = 30% - 70% slope, slope very important to costs 3 = 70% - 310% slope, slope dominates costs
cchstrm	integer	0 = not near stream, no stream cost component here 1 = within 500 feet of a stream, costs are higher null = outside watershed
cchroad	integer	0 = within 150 feet of a road, no extra costs here 1 = beyond 150 feet of a road, extra costs for removal null = outside watershed
cchpar	integer	0 = parcel greater than 5 acres, no extra costs 1 = parcel less than 5 acres, extra transactions costs null = outside watershed
cchsens	integer	0 = either already classed as sensitive due to slope and/or stream proximity, or, not sensitive 1 = classed as Bailey’s sensitive even though it is flat and not near a stream null = outside watershed
cchsnow	integer	0 = slope is less than 30%, thus can support mechanical removal on snow, costs are lower 1 = slope is greater than 30%, thus cannot support mechanical removal on snow, costs are higher null = outside watershed
acres0000	integer	Number represents 10,000 acres. To obtain “acres”, divide by 10,000.

APPENDIX C: FACE.AML

Because of the size limitations of the value attribute table formation in ArcView, the cost estimations were performed in ArcInfo Grid. FACE.AML calls four AMLs, one of which calls another AML. FACE.AML creates the final grids sent to FACE.APR.

/* Author: Madalene Ransom, State Economist, USDA NRCS May 2000.

/* This is FACE.AML which runs all of the cost estimation amls.

/* To run FACE.AML, you will need seven grids

/* Format for following list of grids: GRIDNAME (possible values)

/* CCHDENSE (0,1,null) null = outside the watershed

/* CCHSLOPE (0,1,2,3,null) null = outside the watershed

/* CCHSTRM (0,1,null) null = outside the watershed

/* CCHROAD (0,1,null) null = outside the watershed

/* CCHPAR (0,1,null) null = outside the watershed

/* CCHSENS (0,1,null) null = outside the watershed

/* CCHSNOW (0,1,null) null = outside the watershed

/* You will also need a remap file named COSTCAT.DAT

&run killcco.aml

&run assignpoints.aml

&run costcategories.aml

&run calccost.aml

/* Author: Madalene Ransom, State Economist, USDA NRCS May 2000.

/* This is KILLCCO.AML, it kills pre-existing cost condition grids, grids starting with CCO.

/* Loop through the &list which contains 8 grids starting with CCOSLOPE.

&do grd &list ccodense ccoslope ccostrm ccoroad ccopar ccosens ccosnow ccotot

&if [exists %grd% -grid] &then

kill %grd%

&end

&return

/* Author: Madalene Ransom, State Economist, USDA NRCS May 2000.

/* ASSIGNPOINTS.AML assigns cost condition points to the various cell characteristics.

/* These are the default values:

&setvar dense = 1

&setvar sclass0 = 0

&setvar sclass1 = 1

&setvar sclass2 = 2

&setvar sclass3 = 2

&setvar strm = 2

&setvar road = 1

&setvar par = 1

&setvar osens = 2

&setvar snow = 2

&setvar changedefault = [response 'Do you want to change the defaults (y, n)?' y]

/* If user wants to change the defaults, then present the interactive questions.

&if %changedefault% = 'y' &then

&do &until %done%

&type SlopeClass 0 has been assigned [value sclass0] cost condition points.

&setvar sclass0 = [response 'Enter another point value if you wish' [value sclass0]]

&type SlopeClass 0 now has the value [value sclass0].

&type SlopeClass 1 has been assigned [value sclass1] cost condition points.

&setvar sclass1 = [response 'Enter another point value if you wish' [value sclass1]]

&type SlopeClass 1 now has the value [value sclass1].

&type SlopeClass 2 has been assigned [value sclass2] cost condition points.

&setvar sclass2 = [response 'Enter another point value if you wish' [value sclass2]]

&type SlopeClass 2 now has the value [value sclass2].

&type SlopeClass 3 has been assigned [value sclass3] cost condition points.

&setvar sclass3 = [response 'Enter another point value if you wish' [value sclass3]]

&type SlopeClass 3 now has the value [value sclass3].

&type NearStream has been assigned [value strm] cost condition points.

&setvar strm = [response 'Enter another point value if you wish' [value strm]]

&type NearStream now has the value [value strm].

&type FarRoad has been assigned [value road] cost condition points.

&setvar road = [response 'Enter another point value if you wish' [value road]]

&type FarRoad now has the value [value road].

&type SmallParcels has been assigned [value par1] cost condition points.

&setvar par = [response 'Enter another point value if you wish' [value par]]

&type SmallParcels now has the value [value par].

&type OtherSensitivity has been assigned [value osens] cost condition points.

&setvar osens = [response 'Enter another point value if you wish' [value osens]]

&type OtherSensitivity now has the value [value osens].

&type Snow has been assigned [value snow] cost condition points.

&setvar snow = [response 'Enter another point value if you wish' [value snow]]

&type Snow now has the value [value snow].

&setvar done = .true.

&end

/* Calculate the minimum total cost condition points a cell can have.

&setvar minpoints = 0

/* Calculate the maximum total cost condition points a cell can have.

&setvar maxpoints = %dense% + %sclass3% * 3 + %strm% + %road% + %par% + %osens% + %snow%

/* Run SUMPOINTS.AML

&run sumpoints.aml %dense% %sclass0% %sclass1% %sclass2% %sclass3% %strm% ~

%road% %par% %osens% %snow%

&return

/* Author: Madalene Ransom, State Economist, USDA NRCS May 2000.

/* This is SUMPOINTS.AML

/* This uses the "cch", the Cost CHaracteristics grids, in creating the "cco", the Cost COndition grids.

/* This uses the cost condition points from ASSIGNPOINTS.AML

&args dense sclass0 sclass1 sclass2 sclass3 strm road par osens snow

/* The following grid functions use the cost condition points which have been sent, and

/* the "cch", Cost CHaracteristic, grids in the following grid algebra statements.

grid

ccodense = con(cchdense eq 0, 0, 1 * %dense%)

ccoslope = con(cchslope eq 0, %sclass0%, cchslope eq 1, %sclass1% * cchslope, ~

cchslope eq 2, %sclass2% * cchslope, cchslope eq 3, %sclass3% * cchslope, 99)

ccostrm = con(cchstrm eq 1, %strm% * cchstrm, 0)

ccoroad = con(cchroad eq 1, %road% * cchroad, 0)

ccopar = con(cchpar eq 1, %par% * cchpar, 0)

ccosens = con(cchsens eq 1, %osens% * cchsens, 0)

ccosnow = con(cchsnow eq 1, %snow% * cchsnow, 0)

ccotot = con(ccodense eq 0, 0, ccodense + ccoslope + ccostrm + ccoroad + ccopar + ccosens + ccosnow)

quit

&return

/* Author: Madalene Ransom, State Economist, USDA NRCS May 2000.

/* COSTCATEGORIES.AML edits the existing remap table named COSTCAT.DAT.

/* This uses the statistics of mean and standard deviation of CCTOT grid to

/* Kill the pre-existing grid which contains zero values.

&if [exists ccototnz -grid] &then

kill ccototnz

/* Create the CCTOT grid named CCTOTNZ which has no zeroes.

grid

ccototnz = setnull(ccotot eq 0, ccotot)

quit

&setvar value1 = %GRD$zmin% /* This is the minimum value of the range.

&setvar value6 = %GRD$zmax% /* This is the maximum value of the range.

&setvar average = %GRD$mean%

&setvar stddev = %GRD$stdv%

/* Finish creating the other four values, value2 through value5.

&setvar value2 = [calc %average% - [calc 2 * %stddev%]]

&if %value2% lt %value1% &then

&setvar value2 = %value1%

&setvar value3 = [calc %average% - %stddev%]

&setvar value4 = [calc %average% + %stddev%]

&setvar value5 = [calc %average% + [calc 2 * %stddev%]]

&if %value5% gt %value6% &then

&setvar value5 = %value6%

/* The default cost values are:

&setvar cost1 = 400

&setvar cost2 = 800

&setvar cost3 = 1400

&setvar cost4 = 3000

&setvar cost5 = 8000

/* Give user an opportunity to enter Cost/Acre values.

&setvar newcost = [response 'Do you want to enter new Cost/Acre numbers (y or n)?' n]

&if %newcost% eq 'y' &then

&do &until %done%

/* If user does not type in a cost value, use the default.

&setvar cost1 = [response 'Enter Cost1' %cost1%]

&setvar cost2 = [response 'Enter Cost2' %cost2%]

&setvar cost3 = [response 'Enter Cost3' %cost3%]

&setvar cost4 = [response 'Enter Cost4' %cost4%]

&setvar cost5 = [response 'Enter Cost5' %cost5%]

&setvar done = .true.

&end

/* Before working with a file, use the close function to be sure no files are open.

&setvar closefile = [close -all]

/* Define the table to be opened and edited.

&setvar remap_file = [open costcat.dat statusv -write]

&setvar w = [write %remap_file% [quote %value1% %value2% : %cost1%]]

&setvar w = [write %remap_file% [quote %value2% %value3% : %cost2%]]

&setvar w = [write %remap_file% [quote %value3% %value4% : %cost3%]]

&setvar w = [write %remap_file% [quote %value4% %value5% : %cost4%]]

&setvar w = [write %remap_file% [quote %value5% %value6% : %cost5%]]

&setvar c = [close %remap_file%]

&return

/* Author: Madalene Ransom, State Economist, USDA NRCS May 2000.

/* CALCCOST.AML does the final cost calculations.

&do grd &list exp_cpa lo_cpa hi_cpa exp_cost lo_cost hi_cost

&if [exists %grd% -grid] &then

kill %grd%

&end

grid

exp_cpa = reclass(ccotot, costcat.dat)

lo_cpa = 0.75 * exp_cpa

hi_cpa = 1.25 * exp_cpa

exp_cost = (exp_cpa * acres0000) / 10000

lo_cost = (lo_cpa * acres0000) / 10000

hi_cost = (hi_cpa * acres0000) / 10000

quit

&return

Appendix D: COSTCAT.DAT

COSTCAT.DAT is the remap table which contains information about COST CATegories. It is a text file which FACE.AML must have on the working directory. It contains the most recently updated cost categories and cost per acre values in each category. The following COSTCAT.DAT was copied from the working directory. There are five cost categories ranging from the lowest cost to the highest cost. For example, the first category contains cost condition points ranging from 1 to 2. And, cells which are in this cost category incur costs of $400 per acre for fuel managment. The last category, the most expensive, is defined for cells containing between 11 and 12 cost condition points. These are the worst cells and cost approximately $8,000 per acre for the initial fuel load reduction (helicopters are required in this category).

1 2 : 400

2 4 : 800

4 8 : 1400

8 11 : 3000

11 12 : 8000