The data-processing methodology described in this paper, focusing on the spatial component of the ALMaSS landscape model (Fig. 1), enables the generation of a raster landscape map and additional data outputs necessary to produce three mandatory external input files required to run a landscape simulation in ALMaSS: a binary raster map (.lsb format), a polygon reference text file (PolyRef.txt), and a farm reference text file (FarmRef.txt). The full specification of these file formats and their implementation within the ALMaSS software architecture is described in Topping and Duan (2024); here we provide only the detail necessary to understand the data requirements that drive the processing pipeline.

The .lsb raster map defines the spatial extent and resolution of the landscape and assigns each raster cell a reference number linking it to a specific landscape polygon. The PolyRef file describes the attributes of each polygon using that reference number as a unique identifier. The current list of polygon attributes is shown in Table 1; it is this set of attributes that the external data processing must ultimately populate. The FarmRef file lists all farm units within the landscape, each assigned a farm type, and links them to individual field polygons via the PolyRef file. Each farm can be further linked with a specific crop rotation scheme described in a .rot text file. Crop management plans, weather inputs, vegetation growth curves, and floral resource curves, which drive the temporal component of the landscape simulation, are generated separately and are not covered here; details are provided in Topping and Duan (2024) and Topping and Olesen (2005).

Here, we describe all processing steps applied to the input data described above that are required to generate the full set of mandatory external input files (a ‘.lsb’ binary raster map file with an associated PolyRef.txt file describing the landscape structure and a FarmRef.txt file associating the farming structure with farm types) needed to run a landscape simulation in ALMaSS.

The ALMaSS landscape methodology was first developed for Danish landscapes, based on topographic, land-cover, and agricultural data for 2012–2013 (Topping et al. 2016). The mapping algorithm used to generate a landscape raster map was coded using a Python script and the Python library ArcPy to access geographic information system (GIS) functions available in ArcGIS. R scripts were used to prepare the PolyRef and FarmRef reference files (https://github.com/flemmingskov/python-landscapegen). Since then, the methodology has undergone several changes, one of the most important being the shift from filling data gaps in the landscape map with more general land-cover data to the development of a multi-stage algorithm that removes data inconsistencies (sliver polygons) while simultaneously filling data gaps. The new procedure was first tested and applied to Polish landscapes (Ziółkowska et al. 2021) and subsequently to Dutch landscapes (Ziółkowska et al. 2022). Furthermore, slight modifications were made during the implementation of the methodology in several other countries within the Horizon 2020 EcoStack project. Here, we present the most recent version, which is entirely coded in Python scripts (see section ‘Workflow automation’), resulting from experience gained over several years of work with ALMaSS landscape simulations.

This section is divided into three parts. First, we present a mapping algorithm to generate a landscape raster map (‘ALMaSS landscape map’). Second, we describe the method for classification and definition of farm types and crop rotations (‘Farming structure and cropping system’). Third, we present the algorithm used to generate the ALMaSS input PolyRef and FarmRef reference files and to transform the raster ALMaSS map into the .lsb format for ALMaSS (‘Producing ALMaSS inputs’).

The raster ALMaSS landscape map is a single-layer representation of reality, meaning that each landscape polygon corresponds to a distinct land-cover or land-use element, such as agricultural fields, forests, roads, or water bodies. As such, the ALMaSS landscape map does not incorporate vertical stratification of landscape elements and lacks a multi-layered representation of vegetation or structural complexity. However, two important aspects enrich this simplified structure. First, properties assigned to landscape polygons via the PolyRef text file allow the incorporation of additional “layers of information” related to structural complexity. For example, the PollenNectarCurve property enables the association of a given polygon with a specific plant composition. Second, the temporal component of the ALMaSS landscape model allows polygon properties to change over time, further enhancing the informational depth of the landscape representation.

The ALMaSS landscape map results from a multi-stage process of spatial data processing using GIS functions. The aim of this process is to obtain a raster map of landscape elements covering areas in a complete and disjoint manner, i.e. such that each pixel of the raster map is unambiguously assigned to a specific polygon representing a given type of landscape element. The whole process can be divided into several steps, as described below.

ALMaSS uses its own typology of landscape elements (TOLEs), designed to support ABMs of the species present in the system (Suppl. material 1: table SS1). The typology is therefore habitat-oriented, linking land-cover information with land use, vegetation, and topography. ALMaSS also utilises the classificatory attributes of the PolyRef text file, which hold information about specific characteristics of TOLEs. Each TOLE can then be individually interpreted from the perspective of modelled species, for example, by assigning quality values describing breeding habitat or food resources.

Identifying geodata that allow the mapping of ALMaSSTOLEs for a given study area is the first important step in the ALMaSS landscape model generation process. Reviewing the metadata, geographical scope, credibility, and thematic scope of potential input data is crucial for proper understanding of the data content and context. For example, within the ALMaSS TOLE typology, it is necessary to distinguish between managed and semi-natural grassland habitats. The first group includes permanent grasslands under agricultural management that may be mown, grazed, or fertilised. They are further subdivided into specific TOLEs according to the type and intensity of management (e.g. permanent pasture, low-yield permanent pasture) and linked to specific management plans. The second group includes natural areas of grasses and herbaceous plants, further subdivided into dry grasslands and wet grasslands. This distinction is important because vegetation type determines the availability of food resources, shelter, and other essential elements, while management type modifies these conditions. Unfortunately, grasslands are defined and mapped differently in national topographic databases across Europe, and even layers with the same thematic name can have different meanings (Table 2). This example demonstrates that thorough understanding of the input data is necessary to map ALMaSSTOLEs accurately.

The output of this step is a landscape data description table (LandDataDescriptionTable.csv) and a database organising the input geodata (in the form of a single geodatabase or folder). The landscape data description file lists all geospatial layers used in the landscape generation process, together with information on their definition or thematic scope and additional attributes required for subsequent processing steps. Depending on the structure of the input data, a particular information layer may be represented by a single geospatial layer or by a subset of a layer’s features. In the latter case, a query expression must be defined on the source geospatial layer to obtain the features required for the information layer. Thus, the landscape data description file may distinguish between the information layer and the source geospatial layer, where the latter forms part of the input database and the former undergoes further processing steps. The file includes query expressions where necessary. Other information contained in the landscape data description file relates to the data type (vector or raster), spatial resolution (in the case of raster data), geometry type (in the case of vector data; point, line, or polygon), applied buffer (in the case of point and line vector data, used to convert zero- or one-dimensional objects into two-dimensional ones), and the corresponding TOLE code.

In addition, each information layer is assigned to one of the following themes: natural (including natural or semi-natural land-cover types), cultivable (including agriculturally managed areas: fields in rotation and permanent crops, such as orchards or pastures), built-up (including built-up areas of different types and individual buildings), cultural (complexes of land uses or other objects constituting important habitats, such as cemeteries or hedges), water (water network and related infrastructure), and transport (road and railway networks and related infrastructure). The information layers in each theme are assigned three-digit codes. The first digit of the code identifies the theme, while the other two form a number indicating the order of the layers in terms of their spatial priority, which is highly significant for the next step of processing the layers and their combination within each theme (see below).

A database organising the input geodata contains datasets harmonised to a common coordinate reference system (CRS). If necessary, input geodata are reprojected to the official, legally recognised projected CRS of the country or region for which the ALMaSS landscape map is generated. This ensures metric consistency and avoids distortions in distance-based operations (e.g. buffering and Euclidean distance calculations). The final ALMaSS landscape raster products are provided in this projected CRS.

ALMaSS landscape model generation requires high-accuracy and high-resolution input data, the processing of which for large areas (e.g. on a regional or national scale) would be computationally very demanding and time-consuming, possibly requiring high-performance computers. Therefore, the mapping algorithm is designed to process data at the study-area level, which for ALMaSS typically means a 10 km × 10 km processing window.

Prior to further processing, vector geometries are validated to ensure topological correctness. Invalid geometries (e.g. self-intersections, sliver polygons, duplicate vertices, or gaps) are repaired using standard geometry validation and cleaning procedures. This step ensures robust rasterisation and prevents artefacts during layer merging. All input datasets are then clipped to the spatial extent of the study area. To minimise boundary effects during spatial operations, an additional buffer (typically 1 km) is added around the study-area extent. All subsequent spatial analyses are performed within this buffered processing window.

A base raster layer, referred to as ‘land’, is generated for the full buffered extent. This raster defines the target CRS, spatial resolution (1 m²), spatial extent, and grid alignment of the final landscape map. The land raster serves as the snap raster for all subsequent rasterisation procedures, ensuring that all derived raster layers share identical cell size, grid alignment, spatial extent, and CRS. This guarantees spatial consistency during layer merging.

The next step is to process the input data according to the information provided in the landscape data description file. This step involves generating individual information layers (using query expressions where necessary) and then converting the vector layers into raster layers. Polygon features are directly rasterised using the predefined 1 m² grid and snap raster settings. Point and line features (i.e. zero- and one-dimensional geometries such as roads, streams, or individual trees) require preprocessing to ensure appropriate nominal spatial representation in raster format. First, Euclidean distance raster surfaces are calculated for these features. A predefined cut-off value (specified in the landscape data description file) is then applied to add a buffer to the features, effectively transforming them into two-dimensional raster representations. This procedure preserves the continuity of linear elements and ensures that narrow features are not fragmented or omitted during conversion from vector to raster.

If input datasets include raster data with spatial resolutions different from 1 m², they are resampled to the target 1 m² grid using a nearest-neighbour assignment method. This approach preserves categorical data integrity and avoids the creation of artificial intermediate classes.

During conversion to raster, all pixels representing objects from a given information layer are assigned a value according to the three-digit code provided in the landscape data description file, and all background pixels are assigned a value of 1. The information layer for the agricultural fields is an exception, as pixels representing each field are assigned separate values (codes) starting at 1000.

Individual raster layers within each theme are then combined into thematic layers representing natural areas (Natural theme), cultivable areas (Cultivable theme, excluding agricultural fields), built-up areas (Built-up theme, excluding individual buildings), cultural features (Cultural theme), water features (Water theme), and transport infrastructure (Transport theme). Agricultural fields and buildings are treated as separate layers. The layers within each theme are overlaid based on their spatial priority, as defined by the three-digit code assigned in the previous step according to the landscape data description file. Overlaying is achieved by applying a ‘maximum’ cell statistic tool, which for each pixel returns the highest spatial priority value from the input raster layers. This procedure enables objects with a higher priority (those assigned a higher three-digit code value) to overlay objects with a lower priority (those assigned a lower three-digit code value) (Fig. 2).

The set of resulting single-theme rasters is then stacked in sequence so that the final raw landscape map displays the ecologically meaningful layers at the top (Fig. 3). The ordering of the themes depends on data characteristics and data quality (so that more reliable data are prioritised); therefore, this part of the mapping algorithm needs to be adapted each time a new region or country is processed. The resulting raw landscape map may still contain some unclassified areas (‘background’), especially if the input data come from different sources and are of varying quality.

In addition to unclassified (‘background’) areas, the raw landscape map may also contain artefacts related to the spatial alignment between input geodata features (i.e. gap or overlap slivers between those features) (Fig. 4). The extent to which these issues are present will again depend on the quality and consistency of the input data. Information layers from a single topographic database should, by design, be consistent with each other. However, their combination with LPIS agricultural field data or other thematic data from different sources may introduce various artefacts related to input data inconsistencies rather than reality. We have developed a multi-stage procedure to resolve instances of unclassified areas (hereafter referred to as ‘background’) and input data inconsistency artefacts. Table 3 presents the main stages of this process in the order in which they are usually applied, indicating whether they relate to the removal of data gaps or error artefacts (slivers). The order of the stages presented has been chosen to provide the best output (based on our experience in generating ALMaSS landscape models for different European countries and regions) but can be rearranged as deemed appropriate. In addition, the conditions applied in some stages (e.g. geometry rules) often need to be adapted to geographic context-specific landscape and agricultural structure characteristics. For example, a minimum area threshold applied to identify agricultural fields not present in the LPIS data (i.e. ‘missing’ fields) may vary considerably depending on the cropping system and field size structure. Furthermore, in some specific cases, additional processing steps may be necessary due to the thematic resolution and quality of the input data (see ‘Operational implementation in Polish agricultural landscapes’ section). For example, subclassification of grassland may be necessary if the input data does not distinguish between natural and cultivated grassland (Table 2).

Once this processing step is complete, a landscape map without any unclassified pixels or erroneous landscape feature artefacts has been produced, with each pixel of the resulting map having specific associated land-cover/land-use information.

The landscape map produced from the preceding processing stage typically exhibits a higher thematic resolution than that specified by the TOLE classification in ALMaSS (Suppl. material 1: table SS1). Consequently, a reclassification step is required to reduce the thematic resolution of the landscape map, ensuring alignment with the TOLE typology as defined in the data description text file. Executing this processing step at this stage ensures that the input data processing remains independent of the TOLE typology within ALMaSS. Consequently, if modifications are made to this typology or its structure (e.g. transitioning to a hierarchical classification system), it is unnecessary to repeat the entire landscape map preparation process. Instead, only the reclassification step and the subsequent steps need to be revisited.

The final raster landscape map for ALMaSS must delineate polygons of homogeneous land-use/land-cover types (according to the TOLE) by assigning them unique reference numbers (‘PolyRefNum’). This is achieved through the application of a regionalisation function, which records the identity of the connected region for each cell in the output map (Fig. 5). In practice, the algorithm scans the raster grid and records the identity of each connected region of cells representing the same values. Connectivity between cells is evaluated using an eight-neighbourhood rule, meaning that cells sharing either an edge or a corner are considered connected. In this context, the delineation of regions is determined by the allocation of cells to a specific TOLE. Eight neighbouring cells are used when evaluating connectivity between cells that define a region. The resulting raster representation of polygons (homogeneous land-use/land-cover types) is exported in ASCII format for further processing (ASCII_{study_area}.txt).

In addition, two other mandatory and up to five optional outputs are used to produce the final ALMaSS landscape external inputs (see section ‘Producing ALMaSS landscape external inputs’) (Fig. 5). One of the two mandatory outputs is the attribute table (in .csv format, ATTR_{study_area}.csv) of the polygon raster map, which must include a ‘link’ field storing the TOLE value of the zone to which the cells of each region in the output belong. The other mandatory output is the attribute table (in .csv format, FIELDS_{study_area}.csv) of the vector layer with agricultural fields, which is generated at the end of the multi-stage process of removing inconsistencies and data gaps in the “raw” landscape map. This attribute table should include a “link” field storing the field ID number from the agricultural register. The field ID number from the agricultural register can be directly linked to other field-related data, such as the farm unit ID. The five optional outputs include tables (in .csv format) linking each polygon (region) ID (‘PolyRefNum’) of the raster landscape map with information on: (1) soil type (SOIL_{study_area}.csv), (2) elevation (ELEV_{study_area}.csv), (3) slope (SLOPE_{study_area}.csv), (4) aspect (ASPECT_{study_area}.csv), and (5) habitat/flora type (HAB_{study_area}.csv). Using sourced raster maps of these variables, a zonal statistics function can be applied to calculate the majority (in the case of soil type and habitat/flora type) or mean (in the case of elevation, slope, and aspect) values of each of these variables within each polygon of the raster landscape map and to store these results as .csv tables.

In ALMaSS, agricultural management (including the allocation of crops to individual fields according to rotation plans) is applied at the farm level, necessitating the grouping of individual agricultural parcels (fields) into farm units of various farm types. Typically, farm type assignment is not included in the agricultural register and must be generated separately for each country or region based on available crop and farm animal data. Unless specified otherwise, the standard farm types considered in ALMaSS include farms specialised in field crops (arable), horticulture (vegetables and flowers), potato, beet, permanent crops (orchards – fruits, wine, and olives), grazing livestock, granivores, and mixed stock, with distinctions between conventional and organic practices. Additionally, hobby farms, which are smallholdings or small farms maintained without the expectation of being a primary source of income, are considered separately. This typology generally aligns with the types of farming recognised in the Farm Sustainability Data Network (FSDN), formerly known as the Farm Accountancy Data Network (FADN), the EU’s farm-accounting data collection system. We, however, also distinguish between farms specialising in field crops and those specialising in potato and beet production due to the particularly large amount of agrotechnical treatments, including fertilisers and pesticides, applied to these crops. Alternative sets of ALMaSS farm types may be applied for different regions or countries, depending on the types of farming present. For example, for Denmark the farm type set does not include permanent crops, and grazing livestock is considered either a pig or cattle farm type.

The initial step in ALMaSS farm type classification involves compiling a list of individual farms within a country or region, including information on their field acreage, total crop acreage by specific categories, and the number of animals of different types owned, expressed in terms of livestock units (LSUs). Specific crop categories include cereals (common wheat and spelt, durum wheat, rye, barley, oats, summer cereal mixes, grain maize, and other cereals for grain production); other field crops (dry pulses, potatoes, sugar beet, herbaceous oilseed and fibre crops including seed, hops, tobacco, and other industrial crops); energy crops; vegetables and flowers (fresh vegetables, melons, strawberries, flowers, and ornamental plants); vineyards; total permanent crops (fruit and berry orchards, citrus fruit orchards, olive groves, nurseries, and other permanent crops) broken down into orchards, olive groves, and other permanent crops; forage crops (fodder roots and brassicas, other fodder plants, temporary grass, meadows and permanent pastures, and rough grazing); agricultural fallows; and set-aside land. The number of animals of different types is recalculated to LSUs according to Eurostat guidelines (https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary:Livestock_unit_(LSU)). Livestock types include, where possible, dairy cows, other cattle, sheep and goats, pigs, and poultry. The crop categories and livestock types correspond to the statistics used by FADN. Consequently, crop and animal FADN statistics for different types of farming determined for the country or region under investigation can be compared with similar crop and animal statistics calculated for farm units based on the agricultural register. This comparison allows the determination of rules for classifying farm units into specific farm types (Table 4).

Following farm type classification, each farm unit in the agricultural register is assigned a farm type, and summary statistics on the proportions of crops cultivated by farms of different types are calculated. Based on these proportions, crop rotation schemes can be generated individually for each farm type. Typically, only crops with more than a 1% share of the area of a given farm type are considered. It is therefore assumed that the rotation could be represented by 100 crops (1 crop for each 1%). The sequence of crops adheres to typical agronomic practices, and the built-in ALMaSS farm code addresses issues such as late harvests, which can lead to impossible sowing conditions. This prevents unrealistic agronomic crop sequences. The result is a pattern of changing crops on a field that precisely matches the overall crop distribution pattern for that farm type over 100 seasons. For instance, if a specific crop, such as maize for silage, appears 13 times out of 100 in the rotation, it will, on average, occupy 13% of all fields covered by that rotation at any given time. Additionally, predefined crop rotation schemes can be used.

The production of ALMaSS landscape inputs begins with the preprocessing of input data related to agricultural fields. The attribute table of the vector layer with agricultural fields (FIELDS_{study_area}.csv) is merged with the agricultural register based on the ID numbers of agricultural fields. This integration ensures that each field in the analysed landscape window is assigned information on ALMaSS crop type, farm unit ID, and farm type. There may be several agricultural fields missing this information. These fields, generated during the multi-stage process of removing inconsistencies and data gaps in the “raw” landscape map, represent agricultural fields not present in the LPIS data (i.e. ‘missing’ fields), as not all fields may be registered for subsidies. A special procedure is required for these fields, as agricultural fields without assignment to a farm unit are not permitted in the final ALMaSS landscape input files. Consequently, these fields are randomly divided into groups forming farm units. The size of each artificially generated farm unit is derived from a uniform distribution with minimum and maximum values based on the size statistics of farm units present in the analysed landscape window. All new farm units are assigned the most common farm type in the analysed landscape window. Next, the crop type for each agricultural field is verified. If an agricultural field is managed as a field in rotation, it receives an ALMaSS TOLE number ‘20’. Conversely, fields with permanent crops are assigned a specific ALMaSS TOLE number corresponding to the given permanent crop (Suppl. material 1: table SS1). For example, conventionally managed orchards receive TOLE number ‘56’, while conventionally managed permanent pastures receive TOLE number ‘35’. All agricultural fields generated during the multi-stage process of removing inconsistencies and data gaps in the “raw” landscape map are treated as fields in rotation.

The subsequent step involves processing the attribute table of the polygon landscape raster map (ATTR_{study_area}.csv). In this step, ATTR_{study_area}.csv is merged with the attribute table of the vector layer with agricultural fields (FIELDS_{study_area}.csv) and tables providing information on additional attributes of landscape polygons (soil type, elevation, slope, aspect, and habitat/flora type). Farm unit ID numbers and landscape polygon attributes are assigned to specific attributes of the polygon reference (PolyRef_{study_area}.txt) file (Table 1). If any attribute tables are missing, the corresponding attributes in the polygon reference file are assigned a value of –1 for all landscape polygons. If a given landscape polygon is not agriculturally managed, it receives a value of –1 for the ‘FarmRef’ attribute. Based on the polygon reference file, a list of all farm units and their farm types is generated and saved as the FarmRef_{study_area}.txt file. In this file, farm unit ID numbers are renumbered starting from 0, and farm types are recoded to numbers starting from 32, as required by ALMaSS. Finally, the polygon reference file is cleaned to include only the necessary attributes (Table 1), and the landscape raster binary file {study_area}.lsb is generated from the polygon landscape raster map ASCII_{study_area}.txt.

The entire workflow is implemented in three Python 3.x scripts, utilising the arcpy library to access ArcGIS geoprocessing functions and the Pandas library for tabular data handling. The scripts and associated running directories are publicly available at the GitLab repository (https://gitlab.com/ALMaSS/almass_methodology/-/tree/main/landscape_generation), with the overall processing flow summarised in Fig. 6. The protocol supports batch processing across multiple landscape windows, enabling scaling to regional or national extents on mainframe computers or clusters.

Detailed land-use/land-cover maps generated as part of the ALMaSS landscape models can be utilised to describe structural and farmland heterogeneity through a set of landscape- and class-level metrics (Fig. 9). This type of analysis serves multiple purposes, including assessing the impact of landscape and farmland heterogeneity on changes in species population dynamics simulated with ALMaSS. For instance, Ziółkowska et al. (2021, 2022) employed ALMaSS to simulate the population dynamics of the ground beetle Bembidion lampros in landscapes with varying degrees of landscape and farmland heterogeneity and representing different farming systems. Both the composition (e.g. coverage of herbaceous and woody semi-natural habitats) and configuration (e.g. landscape and farming diversity, landscape shape index, number of fields, mean field size, and field boundary density) of landscape elements were analysed in the studied landscapes of 10 × 10 km. The authors found that the observed effects on beetle populations were highly context-specific, with beetle populations being larger and distributed over larger areas in more diverse landscapes with a higher proportion of herbaceous semi-natural areas.

Given that ALMaSS simulations are highly CPU-intensive, it is often necessary to make choices regarding simulation scenarios. This decision-making process can be supported by analyses of structural and farmland heterogeneity conducted on a set of potential landscape windows before running ALMaSS simulations. This ensures that simulation scenarios include landscapes with desired properties (e.g. a gradient from small to large fields) or landscapes representing specific types, as demonstrated in Ziółkowska et al. (2024).

Detailed land-use/land-cover maps generated using the methodology presented here can also be employed to select study sites for fieldwork, ensuring that they meet specific conditions related to landscape characteristics. For instance, this methodology was applied in the study by Sowa et al. (2022) to generate detailed land-use/land-cover raster maps for two distinct landscapes, each 12 km × 16 km. One landscape was dominated by large fields, while the other was characterised by small fields and family farming. Based on these maps, field study sites for sampling the ground beetle Poecilus cupreus were delineated within each landscape by analysing the types of crops cultivated within a 500 m radius around the midpoints where the beetle traps were located. Similarly, in the study by Bednarska et al. (2021), the selection of study sites and the location of red mason bee (Osmia bicornis) nests in the field were based on a detailed analysis of landscape structure and crop characteristics derived from land-use/land-cover maps generated using the presented methodology. Importantly, these detailed land-use/land-cover maps enable the characterisation of landscapes from a species perspective by analysing agricultural landscape properties tailored to the species of interest. For example, Mikołajczyk et al. (2021) evaluated landscape composition and configuration at different spatial scales from the perspective of O. bicornis.

One limitation of the presented workflow is its reliance on the ArcPy library within the ESRI ArcGIS environment. ArcPy is not open source and requires a licensed GIS platform, which may affect reproducibility, accessibility, and transparency. While the algorithmic logic is fully documented, execution depends on proprietary software. From a computational perspective, ArcPy provides robust geoprocessing tools, but processing speed depends on landscape complexity and extent, local hardware, and the internal optimisation of ESRI tools. Many geoprocessing steps, including raster operations such as Nibble (which assigns values from nearest neighbours to fill missing or erroneous raster cells) and vector spatial joins, become computationally intensive at high resolution (1 m), representing the main performance bottlenecks. Although some tools support parallel processing, not all benefit equally, and performance can vary considerably across computing environments. Equivalent operations implemented in modern, in-memory Python libraries such as GeoPandas or GDAL/OGR may execute faster.

To address these limitations, efforts are underway to develop an open-source implementation of ALMaSS landscape generation utilising Python packages from the osgeo family, specifically GDAL and OGR. This transition would improve accessibility, transparency, and customisation possibilities and would enable execution on high-performance computing (HPC) systems based on Linux. Such capability is crucial for handling large-scale simulations and complex data processing tasks, thereby enhancing efficiency and scalability.

Another source of uncertainty arises from integrating spatial datasets of differing resolution and coordinate systems. In the workflow, heterogeneous vector and raster datasets are harmonised into a 1 m raster to capture narrow landscape elements such as field margins and hedgerows. Downscaling coarser datasets may introduce artificial boundary sharpness, while reprojection can cause minor geometric distortions along complex boundaries. These effects may influence ecologically important small landscape elements, potentially affecting habitat availability, edge density, and connectivity. Sensitivity analyses could help evaluate how spatial resolution impacts species modelling and whether slightly coarser input data could produce similar outcomes with more efficient processing. A formal sensitivity analysis evaluating the influence of spatial resolution and dataset harmonisation on model outcomes would therefore be a valuable direction for future research.

The landscape simulation in ALMaSS is dynamic in terms of crop rotations, agro-technical treatments, and vegetation growth in response to weather conditions. However, the underlying landscape polygon structure remains static, and changes in land use or land cover are not modelled outside arable fields. A crucial step in future development is incorporating the ability to modify the landscape structure during simulation to account for land-use or land-cover changes. ALMaSS could be integrated with agent-based models of land-use and land-cover change in agricultural landscapes, considering processes such as farm cessation, expansion, and diversification that shape landscape structure (Valbuena et al. 2010; Bakker et al. 2015; Beckers et al. 2018). Potential trajectories of change could be associated with each landscape element or applied at the landscape scale based on a probability matrix of changes for defined land-use or land-cover types.

The long-term objective is to develop a Data Linkage and Integration module facilitating automated generation of landscape inputs for any selected location within the EU, drawing on the best available national and European datasets (Fig. 10). The primary challenge lies in maintaining dynamically updated data flows and developing algorithms for flexible, quality-aware data selection across heterogeneous sources, ensuring seamless connections between input data and the processing tools described here.