Policies in Envision

Envision Policies Policies in ENVISION represent the fundamental unit of decision-making – they define and constrain the range of possible decisions an actor can make, and define the outcomes resulting from an actor selecting and applying the policy to an IDU. Policies can be thought of as “strategies” or “decision rules” available to actors. Policies have a number of characteristics in ENVISION: where in a landscape they are applicable, what outcomes are generated in response to an actor choosing to select and apply a policy to an IDU, what management goals the policy is intended to be responsive to, and other characteristics. Policies definitions must be supportable by the underlying landscape attributes contained in the IDU coverage; for example, if a policy is to be constrained to only apply in riparian areas, then the IDU coverage must have a representation of what defines a riparian area. Similarly, if a policy outcome is to change a site from undeveloped to developed, then the IDU coverage must have an attribute or attributes consistent with that representation.

Envision Policy Editor ENVISION can contain any number of policies. Using the Envision desktop interface, users can define new policies, or edit/delete existing policies, using the Policy Editor. Alternatively, policy XML can be hand-coded directly by editing teh policies XML file with any text editor (e.g. NotePad) The Policy Editor is available from the Edit Policies option on most of the main ribbon tabs. Policies are stored as XML in either the project (.envx) file or as a separate XML document, as indicated in the <policies> section of the project file - see here for details.

Policies in ENVISION have a number of attributes that can be specified by a user or application developer through the Policy Editor. The Policy Editor presents these attributes on a series of tabs in a dialog box. The attributes, organized by tab, are described below.

This tab, shown to the right, allows specification of some basic policy attributes as described in the following table. Additionally, it allows the creation of new policies, cloning of existing policies for modification, deletion of policies, and the selection of the color used to represent the policy application in thematic maps and plots.

Policy AttributeDescription
Effectiveness PeriodHow long (in years) this policy remains in effect after an actor selects it, expressed as a range between some minimum and maximum number of years. This is useful if you want to specify a temporal “footprint” for a policy. It is particularly useful in combination with the “Exclusive” attribute describe below. To utilize this attribute, check the “The effectiveness of this policy persists for a period after application” checkbox and specify the minimum and maximum persistence periods. The actual effectiveness period of a given policy application is selected stochastically from a uniform distribution between the minimum and maximum specified.
Is MandatorySpecifies whether this policy is mandatory. Mandatory policies are always applied by actors on IDU’s where the site attributes are satisfied
Start DateSpecifies, if checked, that the policy does not become available to actors until the specified number of years have passed from the beginning of the analysis period.
End DateSpecifies, if checked, that the policy is no longer available to actors after the specified number of years have passed from the beginning of the analysis period.
Is Scheduled PolicyIndicates, if checked, that the policy occurs automatically (independent of an actor decision) at the specified point in time (specified as the start date, the number of years since the beginning of the analysis period)
Is ExclusiveIndicates that this policy, when selected by an actor and applied to an IDU, prevents any other policies from being applied to the IDU until the policy expires, as indicated by its effective period.
Shared PolicyPart of the editing control system for policies. If checked, the policy is available to any user of the policy database specified in the Project file; otherwise, only the author of the policy can use it in an analysis.
Editable PolicyPart of the editing control system for policies. If checked, the policy can only be edited by the author of the policy; otherwise, any user of the policy database specified in the Project file can edit/modify the policy.
NarrativeTextual description of the policy. This can be used to document the policy or provide other information about the policy

Site Attributes This tab, shown to the left, allows the construction of spatial queries that specify where in the landscape the policy may be applied. ENVISION has a built-in query language that is used in the Site Attribute Specification. The query allows a range of logical and spatial operators, and is described more fully here. If ENVISION’s “Map” tab is active, the [Update Map] button in Envision's Policy Editor will execute the current Site Attribute Query and show where on the map the Policy is potentially applicable; this is a very useful feature for determining whether the Site Attribute Query is meeting your requirements for the policy.

To specify a Site Attribute Query, the Policy Editor provides a query builder. Queries can be types directly into the Site Attribute Query field of the Policy Editor, or can be constructed using the builder functions provided. Field/Value attributes are constructed by selecting the desired Field/Operator/Value sets and pushing the [Add] button, which insert the specified triplet at the current insertion point in the query string.

Spatial Operators


Similarly, a spatial operator can be inserted into the Site Attribute Query by selecting the [Spatial Operators] button, which brings up the Spatial Operators dialog box (depicted to the right). The arguments to the spatial operators include a query string that defines the target of the spatial operator, using syntax consistent with any other ENVISION spatial query.

Global Constraints

Envision supports the concept of “global constraints” on policy applications, expressed in terms of “costs” of an individual policy application, and one or more budgets (global constraints) defined globally for a set of policies. The basic idea is that if a policy has an associated global constraint, its adoption will be limited when that constraint is met. These constraints are defined on an annual basis. For example, suppose we have a budget for restoration, and a set of policies whose adoption rates are constrained by this budget. We would then define a global constraint (whatever the annual budget is) and policy constraints (defining the cost of adopting the policy). As Actors adopt policies, the cost of those policies are accumulated against the budget defined by the global constraint. One the global constraint is met, the policy is no longer available for adoption in that time step.

Costs consist of two elements: 1) The initial cost, accrued at the time of policy adoption, and 2) an annual maintenance cost, accrued each year for a specified maintenance duration. Cost can be specified on a per unit area basis, or a fixed quantity for each adoption event.

Any number of global constraints can be defined, and a policy can have multiple constraints associated with it, that can reference one or more global constraints.

The Outcomes Tab (shown below) specifies what changes to the IDU database can occur if an actor selects and applies a policy to an IDU. ENVISION employs a flexible grammar and syntax to define one or more outcomes for a policy. Alternative outcomes can be specified, with an associated probability, when more than one distinct set of outcomes can occur when a policy is applied by an actor. For each alternative outcome specified, any number of resulting attribute changes in the underlying IDU data can be defined.

Outcomes

The grammar and syntax for specifying outcomes is as follows: an individual outcome is defined by a sequence of one or more Field=Value pairs, separated by the “and” keyword. A probability of occurrence can optionally be specified by suffixing the outcome string with a colon, followed by a probability value between 0-100. If this is not specified, a probability of 100 percent is assumed. Inline comments (ignored by the outcome compiler) can be specified in braces (“{ } “) to improve readability of the outcomes. For example, assume a riparian policy results in a land use change to “shrublands” (stored in the LULC_C field in the IDU database with an attribute code of 87) and sets the IDU into conservation status (indicated by setting the CONSERV field to 1), and that this always occurs. The outcome string in this case would be:

LULC_C=87 {shrub} and CONSERV=1

To specify that this outcome only occurs 50 percent of the time (instead of the 100 percent assumed above), the outcome would be modified to read:

LULC_C=87 {shrub} and CONSERV=1:50

Note that any number of Field=Value pairs can be specified. Specified fields MUST exist in the IDU database, or the outcome compiler will generate a compilation error. Further note that in this example, nothing happens 50 percent of the time this policy is selected and applied by an actor.

To specify that alternative possible outcomes may results from a policy application, individual outcomes as described above are specified, with each individual outcome separated by a semicolon (“;”). For example, to extend the example above to include an additional possible outcome of land use changing to grass buffers instead of shrubs 25 percent of the time, the outcome string becomes:

LULC_C=87 {shrub} and CONSERV=1:75; LULC_C=92 {grass} and CONSERV=1: 25

Any number of multiple outcomes can be specified in this manner. If the probabilities sum to less than 100, the difference (100-sum) become the probability of no outcome changes occurring. If the probabilities sum to over 100, they are normalized to sum to 100.

Expanding the effect of a Policy Outcome


This tab (shown below) allows the specification of the policy effectiveness for the metagoals defined for this application. Metagoals are indicated by flagging the “Decision Use” attribute for Evaluative Models, indicating they are used in self-interested or altruistic decision making in the Project file (see Project file description above). Effectiveness scores indicate roughly the expected utility of the policy at addressing the indicated metagoal(s). Effectiveness values are specified using slider bars: One slider bar is generated for each of the metagoal specified in the application. Effectiveness scores, like all scores in ENVISION, are specified in a -3 to +3 range, where -3 indicated the policy is counterproductive to the goal, 0 indicates the policy is neutral to accomplishing the goal, and +3 indicates the policy is very effective at addressing the goal.

Effectiveness scores can be computed by ENVISION, or set manually based on expert knowledge of the policy effects. To have ENVISION automatically compute the scores, select the “Compute Effectiveness Scores for this Policy” button. ENVISION’s process for this involves running an analysis with and without the policy being applied to the landscape, and assessing the change in the metagoal landscape metrics between these runs. When computing these scores automatically, you can specify the parameters of analysis as follows:

Compute Scores
Analysis SettingDescription
Years to RunThe length of the analysis period used to define a parameter. This should be roughly the expected time the effects of the policy take to be realized.
Percent CoverageThe portion of the possible sites (as defined by the Site Attribute Query) that the policy is applied to for the analysis.
Metagoals to IncludeSpecifies which metagoals to compute effectiveness scores for.

This method works reasonably well to get first approximations of policy effectiveness score settings. However, these scores generally need to be reviewed and adjusted to ensure they reflect the policy author’s intentions.