Improve Model Efficiency - Part 2

Avoid Unintended Outcomes in Spatial Planning

Today, we will investigate unintended consequences in forest planning models. In a typical project, analysts work with a project team to learn what kinds of silviculture need to be modeled. Once established, the silviculturist and biometrician will establish the operability criteria for those actions. Often, the team will also provide you with a list of stands that they plan to harvest in the first period or two. 

As you construct the model, you soon realize that some of these preplanned activities break the rules. For example, there is a 13-year-old stand scheduled for thinning, despite the rule requiring that commercial thinning be carried out between ages 15 and 20. Despite the frustration it causes, this type of thing happens all the time. It is just a matter of extenuating circumstances – things that models are ill-equipped to handle at face value.

So, how do you handle this as an analyst? If you lower the threshold for thinning to 13 instead of 15, your problem goes away, but a new one takes its place. You will generate many more potential timing choices without corresponding yield tables for them. To avoid that, you can restrict them with an additional volume requirement. But that is somewhat inefficient and violates the intent to thin at ages 15 or older, in general.

Special Actions and Prescriptions

Instead, you can create a new variant of the action, which is only available in the first planning period. There are two ways to ensure that it is only available in period 1. You can use _CP = 1 in the operability statement, or you can use *EXCLUDE in the OPTIMIZE section to exclude the special action from being generated in periods 2 onward.

Of the two approaches, I prefer the first because you don’t need a new action code. If you are precise in your operability statement, only the stand that has been identified for harvest is affected. And there’s the rub: how do you know that you targeted a particular stand (polygon)? Here’s an example:

Stands Layer with Stand-IDs Labeled

Harvest Units Layer with Stand-IDs Labeled

In the harvest units layer, look for harvest units 215 and 225 (lime green), scheduled for the first planning period. You also notice that they are both from the same stand 5977 (red). Technically, they are not eligible for harvest under the standard clearfell operability, so you write a special *OPERABLE statement to allow those blocks to be harvested. Here is the code:

LANDSCAPE

*THEME StandID

5977

5978

5980

5981

5982

6626

6638

6639

*AGGREGATE CCP1

5977 6639

ACTIONS

*ACTION aCC Y Clearcut

*OPERABLE aCC

? ? ? ? ? ? ? ? ? CCP1 _CP = 1

Sure enough, the units 215 and 225 are harvested in period 1. But you’ve also generated harvest decision variables for units 10 and 1416, because they are also part of the same stand. This is not what was intended – only units 215 and 225 were supposed to be harvested.

Understanding Forced Choices

Remember that Woodstock does not schedule based on geographic information. It only sees pools of area that are eligible to be harvested. Even using an LPSchedule file does not necessarily mean that a particular polygon is harvested. True, the specified area associated with the development type is treated, regardless of any *OPERABLE statement. But technically, the solution only guarantees that the right number of acres is harvested. If you truly want to guarantee a particular polygon is harvested, you need to identify it within the landscape section somehow.

From our example above, a simple fix is to include a theme that identifies forced choices (e.g., CC for clearcuts, TH for commercial thins, NA for not applicable). Then, you could explicitly write the operable statement as follows:

LANDSCAPE

*THEME StandID

5977

5978

5980

5981

5982

6626

6638

6639 

*THEME Planned Activities

CC

TH

NA

ACTIONS

*ACTION aCC Y Clearcut

*OPERABLE aCC

? ? ? ? ? ? ? ? ? 5977 CC _CP = 1

Because the last thematic attribute is CC for harvest units 215 and 225, they are eligible for harvest. The other parts of stand 5977 do not have CC in the last theme and are not eligible for harvest. Since no other polygons have the combination of standID = 5977 and planned activity = CC, you know that only those explicit polygons are harvested.

Another approach might be to include harvest units as a theme. While this will work, you are dramatically increasing the number of development types. Unless you have a reason to include ALL planning units, this may be overkill. Remember, your goal in modeling is efficiency!

Summary

The main takeaway from this example is to be precise in your operability specifications to avoid unintended consequences. Don’t be misled by the idea that a stand-based or unit-based harvest model is necessarily equivalent to particular polygons. Unless there is a 1:1 correspondence between polygons and development type classes, there may be alternative optimal solutions that include other polygons. When you map out the solution, it may not meet your expectations.

Struggling With Spatial Planning Issues? Contact Me!

If you’d like a new set of eyes to look over your model(s), give me a shout to schedule a model audit or an on-site training review. We can use your own models to ensure concepts are relevant and suggestions are immediately useful to your team.