Post-processing the results

Some of the outputs generated by Zonation, such as the rank priority map in jpeg-format or the performance curves created by the Zonation GUI, are immediately useful. Often, however, the results need additional post-processing to better suit your needs. There are of course endless ways how you can post-process the numeric results (e.g. the rank priority raster and the performance curves), but nevertheless there is a set of common post-processing tasks that we have found useful. Note that here we use “post-processing” to refer to any activities that process the Zonation results or combine Zonation results with other sources of information. Any activity that aims at producing informative visualization or numeric outputs from the results we save for the next section. Below we have divided post-processing tasks into two separate categories: tasks done using Zonation (including the GUI) and tasks done using some other software tools.

Post-processing using Zonation

Zonation (from version 4.0 onwards) has several useful automated post-processing functions that you can use to get more information about the solutions or compare the solutions between different runs. “Landscape identification” is a set of automated post-processing procedures that can be set up (before running the analysis) using particular configuration files (see Zonation manual Chapter 3.5). The original landscape identification analysis can be used to generate so called management landscapes (e.g. Mikkonen and Moilanen, 2013) for a selected top fraction of solution. In this top fraction, you can set the distance and similarity between spatially distinct areas to identify sets of locations that can serve as management units. It also possible to use a mask file to constrain the landscape identification analysis to a specific part of the landscape. For each of the units identified, Zonation produces extra statistics about the occurrence of features within the unit. These statistics include information, for example, on the proportions of distributions for each feature in the unit.

Even if you are not directly interested in identifying management landscapes, the landscape identification can be configured to use a pre-defined unit mask. In this analysis, statistics are produced separately for each pre-defined spatial unit. For example, you could be interested in knowing what proportion of the distribution of each biodiversity feature is contained within protected areas, municipalities or within units of some other cadastral delineation. These statistics can then be combined with the spatial data describing the units to produce additional information that helps understand why the priorities are the way they are. Coming back to the example of protected areas, you could provide managers with more information on why particular protected areas are seen as high priority. This type of additional examination is very useful for a broad set of analysis; in fact, we recommend it as a standard procedure whenever meaningful units can be defined for the calculation of statistics.

Zonation is also capable of comparing the spatial overlap between different solutions, using the landscape comparison post-processing functionality. It is possible to configure the options so that the overlap between solution A and solution B can be compared for a given fraction. You could compare, for example, solutions A and B for the top 10% fraction and produce a new output raster that would indicate which cells in the landscape are included in the top 10% in both solutions. By using the “merged map” functionality (see Zonation manual Section 4.3.4) in the Zonation GUI you can further analyze which parts of the landscape are in a given top fraction in solution A, solution B or in both.

You can do a more thorough cross-comparison of different solutions by using the solution loading functionality in Zonation (see Zonation manual Section 3.5.2). The solution load enforces a pre-defined ranking on a different set of data; the ranking may have been developed outside Zonation or using Zonation with different data and/or settings. This type of cross-comparison will not produce information about the spatial overlap of solutions, but it does enable the detailed comparison of the performance of two solutions. You might be interested in how much does the inclusion of a particular connectivity measure influence the performance of your solution (i.e. quantifying trade-offs). Another example where such cross-comparison might be useful is if you are interested in studying whether a set of biodiversity features acts as a surrogate for another. This type of analysis can also be easily implemented by entering all features into the same analysis run and using zero weights for selected taxa.

Post-processing using other software tools

For visualization and interpretation, you will frequently want to import the spatial outputs, most notably the priority rank rasters, into a GIS software. Most of the post-processing tasks that might be applied to Zonation results are beyond the scope of this document, but the single important, albeit semi-obvious, point we want to make is that there is nothing special about the raster files produced by Zonation. You can work with them as you would with any other raster-type spatial data. Nevertheless, it is useful to keep in mind the following technical considerations:

  1. Avoid using the ASCII raster file format (default in Zonation < v4.0) if at all possible. While there is certain appeal in the simple file format, ASCII rasters can become very large and reading in ASCII rasters has its quirks in different GIS software. For example, by default ArcGIS (at least versions up to 10.2.1) will assign ASCII rasters with the integer data type. This means that importing an ASCII-format priority rank raster will not produce the intended output as ArcGIS thinks the raster is an integer raster whereas it actually is a float raster!
  2. Zonation knows nothing about coordinate reference systems (CRS). Since it is using GDAL internally for reading and writing raster files, in most cases your CRS will be preserved in the outputs as well. Nevertheless, it is a good idea to check the outputs for correctness. Furthermore, if your prioritization covers very large areas, such as the whole globe, you need to consider the projection effects (i.e. the raster cells will be of different size at different latitudes).
  3. The non-spatial tabular outputs (e.g. performance curves and outputs from landscape identification) have a format that is primarily designed to be human-readable rather than machine-readable. In other words, reading and parsing the files into other software platforms takes a little work.

In case you are using R programming language4, you might be interested in an R-package “zonator”5 (Lehtomäki, 2014). This package has functionality for (i) automatically reading in a whole Zonation project and associated results as R data structures6, (ii) controlling Zonation programmatically and (iii) post-processing and visualising Zonation results7. Zonator makes it easy to integrate Zonation analyses into your other workflows that use R.

4. https://cran.r-project.org ↩
5. https://github.com/cbig/zonator ↩
6. https://cbig.github.io/zonator/vignettes/zonator-project.html ↩
7. https://cbig.github.io/zonator/vignettes/zonator-results.html ↩