Marxan User Manual: Input Files continued

3.2.4 The Planning Unit versus Conservation Feature File
The Planning Unit versus Conservation Feature File contains information on the distribution of conservation features across planning units. It has the default file name, ‘puvpsr2.dat’. There are two different formats this file can take, vertical and horizontalWARNING: Plugin disabled TAG!8. Either is acceptable and Marxan will test the header line to determine which format is being used.

More information on generating either format can be found in the tutorials (Appendix C-3).

WARNING: Plugin disabled TAG!8In previous Marxan manuals, these vertical and horizontal formats were known as “relational” and “tabular,” respectively.

3.2.4.1 Vertical Format
When using the vertical format, the Planning Unit versus Conservation Feature File contains three columns, all of which are required. The file starts with a header row which contains the name of each of the three variables, ‘species’, ‘pu’ and ‘amount’. Each subsequent row then contains an id for a conservation feature (under the header ‘species’), a planning unit id (under the header ‘pu’), and a value for the amount of that conservation feature found in that planning unit (under the header ‘amount’). Thus there will be one row for each time a feature occurs in a planning unit. There are no default values for this file and any missing data or incorrect headers will prevent Marxan from running.


An example of the vertical form of the Planning Unit versus Conservation Feature File (puvspr2.dat) used in Marxan.

3.2.4.1.1 Conservation Feature ID
Variable – ‘species’
Required: Yes

Description: The unique id number of each conservation feature. This must correspond to the id numbers used in the Conservation Feature File (see Section 3.2.2.1).

3.2.4.1.2 Planning Unit ID
Variable – ‘pu’
Required: Yes

Description: The id of a planning unit where the conservation feature listed on the same row occurs. The planning unit id numbers must correspond to the numbers used in the Planning Unit File (see Section 3.2.3.1).

3.2.4.1.3 Conservation Feature Amount
Variable – ‘amount’
Required: Yes

Description: The amount of the conservation feature occurring in the planning unit listed on the same row. This amount may be related to the abundance of a species or the extent of a certain habitat type.

Getting Started: There is no requirement to use the same metric for all conservation features. It is essential, however, that the amount for a given feature is in the same units used to set the target representation for that feature (see Section 3.2.2.3). In the vertical file format, you should not list cases where a feature does not occur in a planning unit, for example you should not have a row with an amount of ‘0’. Instead the row should be omitted altogether from the file. Marxan will assume that conservation features only occur in planning units where an amount has been entered. The default amount for a planning unit/feature pair that is omitted from the file is zero.

Note: It does not matter how the data in this file is ordered (i.e. it does not have to be sequential by any of the variables), however, ordering by conservation features helps to ensure that the data for all features has been entered.

More information on generating either format can be found in the tutorials (Appendix C-3).

3.2.4.2 Horizontal Format
In the horizontal format, the Planning Unit versus Conservation Feature File is simply a matrix of planning units versus conservation features. The first column begins with the header, ‘id’, and is a list of the id number of every planning unit found in the Planning Unit File (see Section 3.2.3.1). Each subsequent column has a header with the id number of a conservation feature. These must correspond to the id numbers found in the Conservation Feature File (see Section 3.2.2.1), and there must be one column for each conservation feature. Marxan will assume that any conservation feature that does not appear as a column header does not occur in any planning units. Each row will be populated by values that indicate the amount of every conservation feature found in that planning unit. This includes entries of ‘0’ in cases where a particular feature is not found in that planning unit. Although this is perhaps a more intuitive way to present conservation feature distribution data, and easier to read, it results in larger files with a lot of redundant information. As with the vertical format, there are no default values for this file and any missing data or incorrect headers will prevent Marxan from running.


An example of the horizontal form of the Planning Unit versus Conservation Feature File (puvspr2.dat) used in Marxan.

More information on generating either format can be found in the tutorials (Appendix C-3).

3.3 Optional Files
The following two files are both optional, if no file name is given in the Input Parameter File (see Section 3.2.1), Marxan will not attempt to find them.

3.3.1 The Boundary Length File
The Boundary Length File contains information about the length or ‘effective length’ of shared boundaries between planning units. This file is necessary if you wish to use the Boundary Length Modifier (see Section 3.2.1.1.2) to improve the compactness of reserve solutions. It is not necessary to specify boundary lengths for all planning units (where they are not specified, Marxan will assume there is no boundary between planning units). However any missing values within the file will prevent Marxan from running, for instance if ‘id1’ and ‘id2’ are set but no value for ‘boundary’ is entered.


An example of the Boundary Length File (bound.dat) used in Marxan.

3.3.1.1 Planning Unit IDs
Variables – ‘id1’ and ‘id2’
Required: Yes

Description: ‘id1’ and ‘id2’ contain the id number of the two planning units that share a boundary. These do not have to be adjacent planning units, though they usually are – see below, and the MGPH for more details.

Getting Started: It does not matter in which order id numbers appear but it is important not to duplicate boundaries as Marxan will sum duplicate entries together when calculating boundary length.

3.3.1.2 Boundary Length
Variable – ‘boundary’
Required: Yes

Description: The value for the variable ‘boundary’ can be derived in a variety of ways but it is essentially a relative measure of how important it is to include one planning unit in the reserve system, given the inclusion of the other. For instance, if the planning unit in the column, ‘id1’, has been added to the reserve system, how important is it that the planning unit in the column, ‘id2’, is also included, and vice versa. Because this is analogous to a ‘cost’ that must be paid if both planning units are not included, this variable is generally referred to as ‘boundary cost’.

Getting Started: In its most typical application, boundary cost reflects the actual geographical length of the boundary between two adjacent planning units, and this is a good place to begin. This cost can, however, be easily adjusted to reflect some other association between planning units, for instance, boundaries that are particularly desirable or undesirable. As an example, it may be undesirable to have reserves with boundaries adjacent to heavily populated areas, whereas having boundaries that abut private reserves or other conservation areas may be very desirable. In neither of these cases is this information reflected in the actual boundary length between neighbouring planning units.

It is very important that if some relative measure, other than actual boundary length is used, the chosen metric must be well justified. Remember you are introducing bias into the reserve selection process and all stakeholders have a right to understand why. Transparency and defensibility are two of the core strengths of systematic conservation planning. Two planning units that are not adjacent to each other can still incur a ‘boundary cost’ if there is an important relationship between them. For instance, if a species requires habitat found in disparate planning units, either at different times of the year or during different life stages, then it makes little sense to protect one and not the other. If no association between these planning units is specified, Marxan may trade one in place of the other when in reality both are required for persistence of the species. This method could also be used to identify paths of connectivity between planning units, for instance, larval transport in marine systems, or hydrological flows in aquatic systems.

In some cases there will be no possibility of removing a boundary by including a neighbouring planning unit in the reserve system. This may happen, for instance, at the edge of a territorial jurisdiction or mandated planning region. Because planning units at the edge of a region will generally have shorter ‘shared’ boundaries, selection may be biased towards these planning units. This may be undesirable. To avoid biasing the selection of these planning units, they should feature in the Boundary Length File as ‘irremovable boundaries’. This can be accomplished by specifying the length of a planning unit’s boundary with itself, i.e. by repeating the same planning unit id in both the ‘id1’ and ‘id2’ columns.

The value entered in ‘boundary’ should always be ‘0’ or greater. Although it is not generally necessary to specify cases where there is no cost between planning units, a zero cost boundary can be useful if you want to identify two planning units as neighbours but there is no actual boundary cost. This may be necessary if you have set minimum clump sizes for some conservation features (see Section 3.2.2.5).

More information on generating the bound.dat can be found in the tutorials (Appendix C-5).

3.3.2 The Block Definition File
The Block Definition File is very similar to the Conservation Feature File (see Section 3.2.2) and is used to set default variable values for groups of conservation features. It is always used in conjunction with the Conservation Feature File. Groups of conservation features must first be defined using the variable, ‘type’ in the Conservation Feature File (see Section 3.2.2.2). Features may form part of a group because the values for some of their variables are, for example, defined by specific legislation, or they are similar in their ecological characteristics. For each different type of conservation feature, the values for all other variables in the Conservation Feature File can then be defined using Block Definition File. This provides a quick and easy method for implementing common targets for groups of features and is useful in cases where various targets are being used and different levels of protection explored. It also provides a quick way to provide proportional (percentage) protection, without having to manually calculate these values.

In order for groups of features to take on the values defined in the Block Definition File, the variable value in the Conservation Feature File must be set to ‘-1’.


An example of how values must be set in the Conservation Feature File (spec.dat) if you wish these parameters to take on the values defined in the Block Definition File (blockdef.dat). In this case, all 24 conservation features will take the Block Definition value for the variables ‘spf’ (Penalty Factor) and ‘sepnum’, and 11 of the conservation features will take the Block Definition value for the variable ‘targetocc’ (Target for Separated Feature Occurrences).

This is a convenient way to allow some variables to take on the group value and some to be set individually. For instance, in the example above the variable ‘target’ is defined for separately for each feature, perhaps because of differing abundance in the planning region. On the other hand, the variable ‘spf’, the Conservation Feature Penalty Factor (see Section 3.2.2.4), always takes on the value defined in the Block Definition File. This may be useful in cases where the different types of conservation feature are of differing importance but we are unsure of the appropriate ‘spf’ value. By using the Block Definition File we can alter the ‘spf’ for each type feature without having to alter every entry in the Conservation Feature File.

The Block Definition File can contain up to eight different variables and should be in the same format as the Conservation Feature File.


An example of the Block Definition File (blockdef.dat) used in Marxan. 1. Negative 1 must be entered in this file if you want the variable to take on the original value defined in the Conservation Feature File. 2. ‘Prop’ is the only new variable in this file --see below for description.

The only variable that is required in this file is ‘type’, and the only new variable is ‘prop’. Both of these are described below.

3.3.2.1 Conservation Feature Type
Variable – ‘type’
Required: Yes
Description: A unique numerical identifier for groups of conservation features. Each ‘type’ must correspond exactly with the types identified in the Conservation Feature File (see Section 3.2.2.2).

3.3.2.2. Proportion Target for Feature Representation
Variable – ‘prop’
Required: No
Description: The variable ‘prop’, is short for proportion and can be used to set the proportion (i.e. percentage) of a conservation feature to be included in the reserve system.

Getting Started: This should be a number between 0 and 1. For instance, if ‘prop’ for a type of feature is set to 0.2, then Marxan will set the target for all features within that type at 20% of the total abundance, based on the data in the Planning Unit versus Conservation Feature File (see Section 3.2.4). Total abundance is the sum total of the amount found in all planning units, including those that may be locked either in or out of possible reserve solutions. Because ‘prop’ sets a target value, where it is used the value for the variable, ‘target’, should be set to ‘-1’. It makes no sense to set both, and if both are set then the variable, ‘prop’, will take precedence and the variable, ‘target’, will be ignored.

The proportion is based on the total amount defined in the Planning Unit versus Conservation Feature File. If some pre-processing of the data has occurred, for instance to remove small or fragmented occurrences of a feature, then this may not be the same as indicated in the original data set.

3.3.2.3 All other variables
The remaining variables in the Block Definition File (‘target’, ‘target2’, ‘targetocc’, ‘sepnum’, ‘sepdistance’ and ‘spf’), all have the same definition as in the Conservation Feature File (see Section 3.2.2) and where not defined here will take on the value in that file. If you wish any of these six variables, that are defined, to take on the original value from the Conservation Feature File, simply set the value in the Block Definition File to ‘-1’. This is also the default value for
these variables and any missing entries will take this value.

---