This page provides some tips & tricks for the process of setting up a landscape in iLand (in addition to already existing documentation pages such as simulation extent, initialization hub or landscape setup).
The most common setup is described on the landscape setup page and consists of the following elements:
a definition of the project area as a GIS grid (10m resolution): this is very often derived from some polygonal data (for example a map of stand polygons). Cells with the same (integer) grid value belong to the same "stand". In addition to the forested area within the project area, the grid contains information about the area surrounding the forest. Pixels can be marked as forested (forests not simulated) or as unforested (e.g. agricultural land) (see landscape setup).
You can visualize the stand grid in iLand via ja
An environment grid is often used for defining site and climate conditions with a resolution of 100m (i.e., the resolution of resource units). While alternative ways to accomplish this exist (see simulation extent), the most often followed approach is:
- an environment grid contains regions with homogeneous soil and climate conditions. The grid itself holds a (integer) "id" for these regions
- a table (CSV or other text format) contains for each "id" the values for soil and climate conditions (and also things like carbon pools for soil and deadwood). This file is called the "environment file".
- when iLand initializes a resource unit, it uses the values provided in the environment file. The link to a climate is established via the *table name* in the climate data base.
- use the same projection in GIS for all spatial input data in iLand
- the grids can be larger than the intended simulation area: for instance, if the environment grid is larger than the simulated area, all unused area is discarded. Similiarly, the stand grid should be large enough to cover the relevant out-of-project areas (used e.g. for external seeds).
- iLand uses the center point of each resource unit to query the environment grid. Since the layout of the resource units is not necessarily aligned with the environment grid (see discussion below), the origin of the project area should be set with care.
The spatial data such as the stand or environment grid defines a "canvas" for iLand (note that there is potentially more gridded input data in iLand: e.g. a simulation extent for the fire module, wind speed information for the wind disturbance module).
The actually simulated area is defined by a rectangular area on that canvas. This allows you to simply select smaller parts of a larger landscape for testing. iLand tries to avoid loading unnecessary data (e.g. climate data that is not really used, or forest vegetation that is outside of the simulated area).
The world.location section in the project file defines the origin of the "local" coordinate system that is used in the model in real-world coordinates on the "canvas". The size of the simulated area is defined by world.width and world.height. Note that all internal grids (e.g. the resource units) are aligned to this origin.
Again, there are several ways to set up the initial state of the forest, but a practical way is to use the standgrid mode for tree initialization. In this case a tabular file defines for each of the "stands" of the stand grid (described above) the initial vegetation. The same approach can be used to initialize saplings (i.e. trees < 4m). See initialize trees for trees, and for saplings.
Both ways of forest management in iLand can operate on the spatial entities defined in the stand grid. When the agent based forest management module is used then stands can be grouped to management units, and agents and stand treatment programs can be assigned to a stand (see ABE spatial setup).