Developing Zonation variants

Before you start implementing your Zonation analysis (i.e. developing the actual input and configuration files needed to run Zonation), it is a good idea to revisit your objectives. Sketch down your model of spatial prioritization if you have not done so yet, and take a look at it. Try to identify the important input data and the different analysis components such as connectivity and weights. The analyses including all relevant data and analysis components are called “production runs”. These potentially complicated analysis runs are the ones that should inform land use decision making. However, Zonation production runs are almost never developed in one go. Rather, they are developed in stages through what we call "development variants" or “variants” in short. There are several important reasons why projects are done like this and we strongly recommend following this approach.

Development variants proceed from simple to complicated, and their number ranges in our experience from several to some dozens. The main logic behind this incremental development can be summarized by the following reasons.

Catching errors in input data or Zonation settings. Each development variant brings in new data or adds structural analysis components via Zonation settings. If you apply lots of data and analysis settings in one go, the likelihood of you not noticing strange outcomes is increased. When data is entered in blocks or analysis settings are switched on one by one, it is comparatively easy to notice if something weird has happened. For example, we once noticed stripes appearing in priority rank maps, which was caused by unnoticed errors in habitat models. Sometimes nothing happens to aggregation in the priority rank maps after some form of connectivity has been switched on. In this case, frequently the parameters of connectivity are wrong or the option is not truly on.

Getting started early. Especially with big projects, it takes a long time before all input data layers (species distributions, habitat distributions) have been updated, acquired, processed and verified. It makes no sense to wait until this point before Zonation analyses are initiated. While you are finalizing the data, it is possible to develop structurally correct analysis setups, enabling rapid completion of analyses after final data is ready. Effectively, you can develop proficiency with Zonation while still fighting with data.

Sensitivity analysis. Development variants can be used to understand the sensitivity of the final product to data components, parameter values, or analysis settings such as connectivity.

There are no fixed rules for how the development variants should be constructed, but the following illustrates an order we have frequently found to be operationally sensible. Note, however, that the sequence does not include all the potential features you can include in your model of spatial prioritization and the consecutive Zonation implementation. For an exhaustive description, consult the Zonation manual.

1. Typically a first analysis is done with partial data (e.g. species only) and without any special analysis settings. The motivation of this analysis is to see that data layers are in format that Zonation understands and that a simple analysis seems to run as expected.
2. After the initial entry of some input features (see 3.1.1), rest of the major data blocks (e.g. habitats, ecosystem services) should be added in. At this stage a sensible weighting between features can also be adopted (see 3.1.2). This analysis starts to give an indication of what to expect, but important considerations like connectivity or costs are still missing.
3. Still early into the analysis, habitat condition should be linked to layers that describe (binary) distributions of habitat types.
4. After the basics, items 1-3 are operational, some form of connectivity should be included. This could involve distribution smoothing for species or matrix connectivity for partially similar habitats or both (see 3.1.3). Also the boundary length penalty could be applied.

The analysis now has biodiversity features, sensible weights for them, habitat condition, and basic connectivity features set up. The next variants start getting close to production variants. Note that there can be several of those: for example analyses with and without costs give different but meaningful outputs.

1. If the aim of the analysis is expansion of a protected area (PA) network, a hierarchical mask for the PA network is used next. Then the highest-priority areas outside existing PAs are the areas that most cost-effectively fix deficiencies of the existing PA network. Effectively, Zonation does a gap analysis and gap filling in one go. If the aim is development of a PA network from scratch, a hierarchical mask is not needed.
2. If developing on top of an existing PA network, one could also apply interaction connectivity to include connectivity to the existing PA network in priorities (see Lehtomäki et al. 2009 for example). This should only be done if connectivity to existing PAs is a priority.
3. Accounting for costs. One or more cost layers can be entered into analysis; these are distinguished by giving them negative weights in the feature list file. If costs are used, Zonation tries to resolve conflicts between ecological benefits and costs; see Moilanen et al. (2011) and Kareksela et al. (2013) for examples.

Typically, you can expect to come up with 2-4 production runs, each providing information valid in its own right. Usually production runs are done with and without considerations that are in partial conflict and which may represent different preferences of stakeholders. These could be, for example, analysis with and without costs, with and without ecosystem services or with and without connectivity to the existing PA network.

As a final consideration, we note the possibility of doing runs either pixel-based (default) or doing them on planning units (PLUs). PLUs can represent, for example hydrological catchments, land parcels, spatially distinct patches of different habitats, etc. If analysis is done on planning units, the priorities come out as slightly different from the averages of pixel-based analysis. This can be, for example, because the occurrence of a very rare feature in a pixel can raise the priority of an entire PLU, whereas in pixel-based analysis and in the absence of connectivity only the pixel itself is influenced. When working with PLUs, one should pay attention to both the mean priority rank of each PLU and the so-called "distribution sum", which is the summed fraction of occurrences of all features in the PLU. To illustrate, a very small PLU can be of very high relative priority but relatively unimportant absolutely, whereas a very big area can be relatively low mean priority but very important in the absolute sense. Both numbers need to be considered when evaluating PLUs. Favouring mean ranks is justified when cost-efficiency is the rule and the habitats in question are such that local-scale connectivity is sufficient. When count of areas is more important than costs (area size), one should shift attention more to the distribution sums.