ForestModel XML

Before we get into specifics lets take a general look at the Matrix Builder processing steps:

  1. Read the XML ForestModel and validate the syntax.

  2. Read the inventory file and group fragments into blocks based on a user-defined block identification field.

  3. Process blocks one at a time:

    1. For each block, create an area-weighted set of attribute curves that describes forest conditions (growth and yield, habitat development) for the group of block fragments.

    2. Determine the eligible management activities for the current block condition. For each management activity determine the products that would be generated from the activity, and the future block condition.

    3. Repeat step a for each eligible management activity. Keep track of the interval of time between each management action. Continue repeating until a decision tree has been expanded beyond the proposed planning horizon.

  4. Write out curves, blocks, features, groups, products, tracks and tracknames. Whereever possible, compress the size of the output files by reusing and recycling identical curve and track definitions.

The ForestModel can be thought of as a series of questions and possible answers based on patterns specified in <select> statements. The questions in the <select> statements will be asked to every record in the input inventory. A suite of curves and management actions will be generated based on responses that are received.

As the ForestModel is being loaded (step 1 above), the Matrix Builder will sort the contents of the <select> statements into lists of components that tell the ForestModel how a particular stratum behaves: retention, treatments (tracks), features, products and succession. These lists are maintained in the order that they are encountered in the ForestModel.

While processing step 3, each record from the input inventory will be matched against the lists of components statements in sequential order until a matching condition is found. The matching values are then used to guide the matrix composition process. Components are matched in roughly the following order:

  1. <retention>

  2. <succession>

  3. <feature>

  4. <treatment>

  5. <products>

<retention> elements assist in the implementation of aspatial retention rules. Spatially explicit retention is defined by block area being pre-apportioned to 'managed' and 'unmanaged' stand components, based on the value of theme variables. Aspatial retention can simulate the implementation of an area retention policy that cannot be defined in advance with a line on the ground (for example, retain 5% of block area for wildlife hiding cover). <retention> elements identify the stand types that are applicable, the percent area that should be withdrawn from the managed part of the landbase, and an optional set of attribute curves that should be attached to the retained areas (in addition to all of the original block attribute curves). Retained areas are withdrawn from the eligible landbase before the start of the simulation and added to the unmanaged landbase. Retained areas will be subject to succession events just like the available landbase.

The <succession> elements provide an opportunity to mimic natural changes associated with senescence, breakup and renewal. These tags define the timing of breakup events, the age of renewal, and the new stand attributes. Patchworks requires that stands renew to a single stratum after breakup, defined in terms of the chosen stratification variables. This is unlike the behaviour of many aspatial models that allow strata to breakup and renew to a number of new strata at various timings.

<feature> elements associate attribute curves to each inventory fragment. Attribute curves describe the extant conditions of forest polygons, such as standing volume, seral stage condition, or habitat availability. Attributes are classified by user-defined labels, and are quantified by curves describing the change in value over time. The Matrix Builder application will compute an area-weighted set of attribute curves as it assembles fragments into blocks.

Management actions are described in <track> elements. Tracks can contain multiple treatment options, each having different operability limits and responses. <transition> elements describe the post-treatment stand condition (in terms of the theme variables). The products generated as a consequence of management are described by <product> elements.

When all is said and done, the Matrix Builder will read in the XML ForestModel and the inventory file containing the fragments. The fragments are amalgamated into blocks, and Patchworks data files are created describing stand development attributes, treatment options and responses.