# Developing a generic DSS model metadata catalogue and APIs for crop protection

Hanna Huitu, Tor-Einar Skog, Christophe Pradal, Antonio Calatayud, Tor Skaslien, Brita Linnestad, Ari Ronkainen, Christian Fournier, Marc Labadie, Dave Skirvin, et al.

► To cite this version:

Hanna Huitu, Tor-Einar Skog, Christophe Pradal, Antonio Calatayud, Tor Skaslien, et al. Developing a generic DSS model metadata catalogue and APIs for crop protection. 2025. hal-05218411

HAL Id: hal-05218411

https://hal.inrae.fr/hal-05218411v1

Preprint submitted on 21 Aug 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Developing a generic DSS model metadata catalogue and APIs for crop protection

Hanna Huitu <fnref n="1" />*, Tor-Einar Skog <fnref n="2" />, Christophe Pradal <fnref n="3" />,<fnref n="4" />, Antonio Calatayud <fnref n="5" />, Tor Skaslien <fnref n="6" />, Brita Linnestad <fnref n="2" />, Ari Ronkainen <fnref n="1" />, Christian Fournier <fnref n="7" />, Marc Labadie <fnref n="3" />, Dave Skirvin <fnref n="5" />, Matti Pastell <fnref n="1" />, David Melchior <fnref n="6" />, Johannes Tobiassen Langvatn <fnref n="6" />, Berit Nordskog <fnref n="2" />

Decision Support Systems (DSS) in crop protection can give a helpful pest risk prognosis or recommendations for pest control, allowing farmers to make better-informed decisions. As a part of European Union policy strategy steering at the sustainable use of plant protection products, the EU H2020 project "IPM Decisions" created an online platform allowing farmers and advisors to access many DSS for major pests, weeds, and diseases in a variety of crops across Europe. The project has assessed and analyzed a set of research verified DSS's for integrated pest management. Information on the models employed by these DSS has been collected into a model catalogue, which is used by the IPM Decisions platform.

Two Application Programming Interfaces (APIs) have been built to facilitate use of these models. In the spirit of the FAIR (Findable, Accessible, Interoperable, Reproducible) principles, the DSS API provides access to DSS models with their metadata, including the description of model input-and output parameters. Weather API allows access to European on-line weather data sources and adapts their offering to the needs of the DSS models. The new APIs work as part of the IPM Decisions Platform, but they are publicly available so that also other agricultural software such as crop protection applications or farm management information systems (FMIS) can use them.

In this article, we discuss the development of DSS and Weather APIs and present their structures and definitions. Finally, we present the services that DSS API and Weather API provide, and demonstrate the use of the APIs in three application cases.

## 1. Introduction

EU has an incentive to make agriculture more sustainable. The use of pesticides within the EU is regulated under Directive for the sustainable use of pesticides (2009/128/EC) and pushed further with strategies such as Farm to Fork, Biodiversity strategy and Green Deal (EC, 2021). Integrated Pest Management (IPM) integrates pest control strategies, methods, and tools to perform better and

<footnote n="1">¹Natural Resources Institute Finland (Luke), Latokartanonkaari 9, 00790 Helsinki, Finland</footnote>

<footnote n="2">²Norwegian Institute of Bioeconomy Research (NIBIO), N-1431 Ås, Norway</footnote>

<footnote n="3">³CIRAD, UMR AGAP Institut, 34398 Montpellier, France</footnote>

<footnote n="4">⁴INRIA and LIRMM, Univ. Montpellier, CNRS, 34090 Montpellier, France</footnote>

<footnote n="5">⁵RSK ADAS Ltd, Spring Lodge, 172 Chester Road, Helsby, WA6 0AR, England</footnote>

<footnote n="6">⁶Norwegian Meteorological Institute (MET Norway), P.O. Box 43, 0313 Oslo, Norway</footnote>

<footnote n="7">⁷UMR LEPSE, Univ. Montpellier, INRAE, Institut Agro Montpellier, 34000 Montpellier, France</footnote>

<footnote>*Correspondence E-mail: hanna.huitu@luke.fi</footnote>
with less harmful impact. Guiding principles of IPM can be dynamically applied to local situations
as suggested by (Barzman et al., 2015).

Successful crop protection at the farm requires expertise and considers aspects such as pest preva-
lence, the likelihood of damage caused by the pest, treatment price vs. the return of investment,
uncertainty in the crop response, building of pathogen resistance, weather conditions, and the avail-
ability of machinery and workforce. During the last decades, many Decision Support Systems (DSS)
with heterogenous approaches have been developed. They can assist the decision-making processes
at operational, tactical, and strategic level, both at farm and field level, and regionally (González-
Domínguez et al., 2023; Magarey et al., 2002). Common questions for DSS to address are whether
pest prevention or suppression measures are needed; how to schedule crop protection interventions;
how to optimize pest monitoring programs, and whether and how to best carry out pesticide appli-
cation (Rossi et al., 2019). Web-based DSS and their functionalities and limitations in disseminating
IPM technologies were recently reviewed by Tonle et al. (Tonle et al., 2024). Information on the ben-
efits of DSS use in crop protection is available for individual studies (Fabre et al., 2007; Jalli et al.,
2020; Lázaro et al., 2021), but the big picture is uncertain. Some of the benefits are also difficult to
quantify; for instance Evans et al. (Evans et al., 2017) highlight that enhanced situational awareness
provided by DSS is a valuable benefit in itself, helping producers take a more proactive approach to
risk management.

Changing climate alters the growing conditions in agriculture, affecting both the crops and pests (Lehmann et al., 2020; Lázaro et al., 2021; Sutherst et al., 2011). New crops or cultivars are taken into cultivation and new pests are spreading to formerly untouched areas, and at the same time there are changes in prevalence for pests that were formerly seen as less significant. Decision support systems enable the knowledge transfer from areas with greater experience of future conditions, although suitability of a model to new area must always be carefully judged and tested. Effective sharing of IPM decision-making tools as laid out by Rossi et al. (Rossi et al., 2023) is now more important than ever.

The need to increase availability and improve the interoperability of existing DSS models from
multiple providers were important drivers for the EU funded IPM Decisions -project. The project
set up an IPM Decisions platform (ipmdecisions.net) that offers the DSS models in the spirit of the
FAIR (Findable, Accessible, Interoperable, Reusable) guiding principles (Barton et al., 2022; Wilkin-
son et al., 2016). We present here the web APIs that 1) provide information on the models and 2) provide tools for managing the weather input data for these models. The APIs interface reposito-
ries of DSS model and weather data sources and provide methods to their use. Standard ways were
developed to store and deliver DSS information, and to collate weather input data. The APIs and
their capabilities can be seen as new digital infrastructure where information on multiple tested and
validated DSS models for crop protection can be found and accessed in a structured way for testing
and implementation. To our knowledge these are the first public APIs for this purpose.

Scientific literature on the decision-making tools in crop protection uses the terms DSS, decision
tools, and models sometimes interchangeably. In this article, DSS is a larger entity (system) and may
contain one or more models (or DSS models). In the new model metadata repository, individual
model forms one record.
# 2. Design of the DSS model metadata repository and APIs

## 2.1. User needs and specifications

A repository of DSS model metadata, catalogue of input weather data, and the DSS and Weather APIs were built as part of a free and open IPM Decisions platform (platform.ipmdecisions.net). The work was preceded by collating and prioritization of DSS models available to the platform (Nistrup-Jørgensen, 2020). APIs provide functionalities also for the users and services outside the IPM Decisions platform.

Modern cultivation is data intensive, and a large spectrum of software is currently being used by the farms to manage the production and machinery and to support reporting tasks. In the rapidly evolving technological environment, characteristics of future uses for these APIs are not all known. We describe uses where there is a user application (client software) for the APIs, that wants to provide its end users (farmers, advisors, or researchers for instance) an interface to one or more DSS models provided by the APIs. User needs at high level are illustrated in the following two use cases A and B.

In the use case A, the user John who is a crop manager wants to know if disease pressure in his wheat crop has risen above the threshold value, or if he can safely proceed without spraying fungicide. First, he opens his user application and gives information on his crop (crop, location). The user application lists suitable models to be accessed. John selects one. Then application asks for model input information, namely sowing date and cultivar resistance, and John specifies them. As John first mistypes the date, the application prompts John to correct it. For the possible weather data sources provided, John selects one from a list. Then he asks application to calculate disease pressure. Behind the scenes, necessary weather data is being fetched, formatted to fit the model requirements, and cumulative disease pressure to the given crop is being calculated. User application then presents the result to John as a graph with illustrative symbols, confirming John's perception of low disease pressure.

In the use case B, user Jill who is a software developer working in a big agricultural advisory organization wants to add their prognosis model to the model catalogue so that the model can be easily accessed by farmers. Board of the IPM Decisions Platform was in favor of including it, as it was already validated for use in two European countries and described in peer-reviewed scientific article. Jill goes to a GitHub web page, and following a protocol defined there and using the provided tools composes model information, integrates it to the model metadata repository, and tests that model works as intended.

The structure enabling these use cases is as follows. A DSS API is interfacing the DSS model metadata repository, and provides search and conformance testing functionalities needed in use case A. The DSS API first enables finding and selecting the correct model from the repository. John can search models by crop, pest, and area of validity. For each model, the required and optional input parameters (here sowing date and cultivar resistance) and their ranges of allowed values are listed in a schema. Also the detailed requirements for weather input data are stored, together with web endpoint addresses to the models and definitions for model output. These model specific pieces of information allow the user application to automate tasks, as in here to alert when input is not valid, seek suitable weather input data, and build the correct representation of the result.

The weather API interfaces weather data source catalogue and provides functionalities to build required weather input for the models. In use case A, the API first lists possible weather data sources. For the data source John selected, the API pulls weather data from source and provides it to John's
user application in format that that conforms the model input requirements.

Use case B integrates a new model into the DSS model metadata repository and DSS APIs to ef-
fectively share it with the user community. A new model record is formed in the metadata repository.
All information defined by the model schema is input, including target crops and pests, area where
the model is valid, parameters that are needed for input, the weather source data that is required,
and specifications how the model result is to be shown and understood. A URL to the model's own
API is also stored in the repository. Jill uses the testing functionalities of DSS API and when all works
as expected, she accepts that the model can now be published in the repository.

3. Implementation

3.1. Implementation of IPM Decisions DSS API

3.1.1. Services and endpoints

The DSS API (Skog, 2024) is a micro-service that provides a searchable catalogue of DSS models available. The service describes each model, its purpose and functionality in human readable form, allowing well-informed decisions on whether to use it for a given purpose. It also describes the models to the client applications in machine-readable form, so that they can provide the required input data and are able to consume the results. Use of the DSS model metadata repository and its schemas is arranged through fixed API endpoints. Figure 1 shows a simplified example where client software uses the DSS API to select a DSS model and prepare for communication with the selected DSS model.

<figure><img src="image_2.png" /><figcaption>Fig. 1: Use of DSS API to select a DSS model (1-2) and prepare for communication with the selected DSS model (3-4).</figcaption></figure>

The client software prepares the required model input, and Figure 2 shows a simplified example
on the retrieval of model results from the selected DSS model.

The web service endpoints of the DSS API are grouped to three services according to their func-
tion. The DSS-Service is used as a catalogue of available DSS models. The Meta的服务 declares
data structures; it includes endpoints providing the data structure definitions (schemas), and valida-
tion services for data. Administrative functionality is provided by the AdminService, which is not
available to external users. Such functionality is e.g. to return CSV-format data used for starting
a DSS translation process when integrating new DSS into the platform. A list of commonly used
endpoints is shown as table 1.
<figure><img src="image_3.png" /><figcaption>**Fig. 2:** Retrieval of model results. VIPS is used as one example of several DSSs.</figcaption></figure>

<table><caption>**Table 1:** List of important web service endpoints in the DSS API. For all endpoints and their full documentation, refer to resources in Table 6.</caption><thead><tr><td>Service</td><td>Endpoint path</td><td>Description</td></tr></thead><tbody><tr><td>DSS</td><td>/rest/dss</td><td>List all DSSs and models available in the platform</td></tr><tr><td>DSS</td><td>/rest/dss/{DSSId}</td><td>Get all information about a specific DSS</td></tr><tr><td>DSS</td><td>/rest/dss/crop/{cropCode}</td><td>Returns a list of DSSs that are applicable to the given crop (identified by EPPO code)</td></tr><tr><td>DSS</td><td>/rest/dss/pest/{pestCode}</td><td>Returns a list of DSSs that are applicable to the given pest (identified by EPPO code)</td></tr><tr><td>DSS</td><td>/rest/model/DSSId/ModelId</td><td>Metadata for a DSS model in the default language. Adding language parameter (for instance, "?language=no") to the path results in the translated version.</td></tr><tr><td> MetaData </td><td>/rest/schema/dss</td><td>Returns the complete structure of metadata as defined in the JSON schema</td></tr><tr><td> MetaData </td><td>/rest/schema/dss/yaml/validate</td><td>Takes DSS metadata in YAML format as input, and validates it against the JSON schema provided in the /rest/schema/dss/ endp</td></tr></tbody></table>

Target crop types and target pests for models are identified in these services at differing levels of hierarchy. The DSS API employs the international coding system maintained by The European and Mediterranean Plant Protection Organization EPPO (E.P.P.O., 2022), which includes codes for relevant target crops and pests, their scientific and common names in multiple languages to support trans-national use, and a separate API for dynamic use of the code database.

The services have been implemented in the Java programming language and packaged as a Java web application in a .WAR file, allowing for deployment on a variety of server platforms. For easy deployment on a cloud computing service such as Microsoft Azure and Amazon EC2, the source code enables building the application as a Docker image.

A simple example in Figure 3 illustrates how a user (for instance; a data engineer exploring the service) first requests a list of available models from the DSS API and then converts the body of the response to text string. This example uses freely available programming language R (R Core Team, 2022) and functionalities from R package htr2 (Wickham, 2024), however the API can be used with a wide range of other programming languages as well.
<figure><img src="image_4.png" /><figcaption>**Fig. 3:** Use of the DSS API for getting a list of EPPO codes for all crops for which an integrated (ONTHEFLY) DSS model is available. As seen from the URL address, this example uses the services deployed by the IPM Decisions Platform.</figcaption></figure>

### 3.1.2. DSS Model metadata repository

Metadata for each DSS model contains the sections listed in table 2.

<table><caption>**Table 2:** DSS Model metadata sections in DSS Model metadata repository</caption><thead><tr><td>Section</td><td>Content</td></tr></thead><tbody><tr><td>Human-readable description</td><td>Title, purpose, description, authors etc.</td></tr><tr><td>Categorizations for filtering</td><td>Valid crops and pests described by EPPO codes, spatial validity described by country list and by geographic polygons</td></tr><tr><td>Execution description</td><td>Type of model (fully integrated or just a link), Json schema definition for input data, and web service endpoint for execution</td></tr><tr><td>Weather input data description</td><td>Required weather data parameters and their sampling frequency (hourly, daily etc.)</td></tr><tr><td>Output data description</td><td>How to interpret the risk status returned by the model, metadata for displaying results in a chart</td></tr></tbody></table>

Human-readable description in the metadata for each DSS is stored in the default language only. Translations are stored as Java ResourceBundles and provided on-the-fly from the DSS-Service endpoints when the language parameter is part of the web service request (see example earlier in table 1). Metadata translation is carried out by plant protection experts. The process includes converting the existing metadata to a human-readable work file, and after translations are carried out converting the result file into a Java properties file. Conversions are performed using Python scripts located in the metadata repository.

Categorizations for filtering include valid crops and pests and spatial validity of the model and enable the API to query and suggest valid models.

A Json schema specifies both the standard input data such as which types of weather data are required, and features that are unique to the model. The schema is crafted by or at least supervised by the DSS owner to ensure that all parameters can be clearly defined with regards to type or unit, default values, value steps and max/min values. Field observations of the pests are a special case
among model inputs, as models tend to require very specific and diverging quantifications of the observations. Thus, custom JSON schemas for the quantifications are necessary.

### 3.1.3. Available DSS models

DSS models can be integrated either fully or as links and the type of integration is stored in model metadata repository. Models can be added (or removed) to the repository as needed. The list of DSS models available is dynamic, as new DSS and their models can be added to the catalogue without changing the DSS API. Table 3 lists the integrated models available at the time of writing. Up-to-date information can be requested from the DSS API using web service endpoints in Table 1.

<table><caption>**Table 3:** Currently available and fully integrated DSS models.</caption><thead><tr><td>Model</td><td>DSS</td><td>Purpose</td></tr></thead><tbody><tr><td>Cutworm Model</td><td>IPM Decisions</td><td>Estimates the risk of cutworm larvae surviving to third instar</td></tr><tr><td>Orange Wheat Blossom Midge Emergence Model</td><td>IPM Decisions</td><td>Estimates the risk of emergence of adult Orange Wheat Blossom Midge</td></tr><tr><td>Pollen Beetle Migration Model (simplified)</td><td>IPM Decisions</td><td>Estimates the risk of pollen beetle migration</td></tr><tr><td>Saddle Gall Midge Model</td><td>IPM Decisions</td><td>Estimates the risk of emergence of adult saddle gall midge.</td></tr><tr><td>Codling moth flight model</td><td>IPM Decisions</td><td>Estimates the risk of the start of codling moth flight into crops, and associated egg laying in pome fruit.</td></tr><tr><td>BYDV TSUM model</td><td>IPM Decisions</td><td>Estimates risk of transmission of virus by aphid vectors</td></tr><tr><td>Hutton Criteria Late Blight Model</td><td>IPM Decisions</td><td>Estimates risk of late blight</td></tr><tr><td>Grey Field Slug (Cereals)</td><td>IPM Decisions</td><td>The purpose of the model is to determine the threshold at which control measures are recommended.</td></tr><tr><td>Grey Field Slug (Oilseed Rape)</td><td>IPM Decisions</td><td>The purpose of the model is to determine the threshold at which control measures are recommended.</td></tr><tr><td>Carrot fly flight model</td><td>VIPS</td><td>Estimates risk of flight and egg laying in crop</td></tr><tr><td>Cabbage fly flight model (Scandinavia)</td><td>VIPS</td><td>Estimates risk of flight and egg laying in crop</td></tr><tr><td>Cabbage moth model</td><td>VIPS</td><td>Estimates risk of damage by Cabbage Moth</td></tr><tr><td>Naerstad model</td><td>VIPS</td><td>Daily risk of infection</td></tr><tr><td>Alternaria TOMCAST</td><td>VIPS</td><td>Daily risk of infection</td></tr><tr><td>Negative prognosis</td><td>VIPS</td><td>Estimates risk of Late Blight infection</td></tr><tr><td>Downy mildew of grapevine</td><td>gaiasense</td><td>Estimates Downy Mildew infection risk. North East Region of Peloponnese, Greece only</td></tr><tr><td>Septoria Humidity Model</td><td>SEGES DSS models</td><td>Estimates risk of septoria</td></tr></tbody></table>
## 3.2. Implementation of IPM Decisions Weather API

### 3.2.1. Services and endpoints

The weather API (Skog et al., 2024) manages creation of weather input data for the models behind the DSS API. Weather API provides a searchable catalogue of weather data sources and helps in finding and pre-processing their data. Figure 4 shows a simplified diagram of using these web services. The Weather API provides forecast and historical data both as point data measured by weather stations and as calculated gridded data.

<figure><img src="image_5.png" /><figcaption>Fig. 4: Requesting weather input data that is needed by the DSS model.</figcaption></figure>

The web service endpoints of the weather API are grouped into services according to their function: a) composing of the weather input data and fixing of potential gaps or problems (WeatherAmalgamationService); b) catalogue of available sources for weather data (WeatherDataSourceService); c) conversion of weather data from a specific source to the required format (WeatherAdapterService); d) quality control of weather data (QualityControlService), e) querying meta data (Meta的服务) and f) testing (TestService)。Some of the endpoints are general-purpose, while others provide variations in their use. A list of examples of web service endpoints is shown in table 4.

### 3.2.2. Weather data sources and provision of weather data to DSS models

Weather API connects to several different weather data sources. Reliable, open sources for gridded weather analysis and forecasts exist for all parts of Europe, though with different scales ranging from 7 km grid spacing (or more, depending on time scale) down to 1 km and even downscaled to sub-km grid spacing in some areas for nowcasting purposes and short-range forecasts. Both measured data, (re)analysis and forecasts are available, from international services, national services, and private weather stations (table 5).

The Weather API is designed to be flexible; it can adapt both to the improving open data policy among the European Meteorological Institutes and to the increasing number of observations and fine scale models. This way the Weather API takes advantage of preprocessing (data assimilation and quality control of observations), numerical weather prediction (NWP) and post-processing by the National Meteorological Institutes, e.g., open and publicly accessible download services from
<table><caption>**Table 4:** Examples of web service endpoints in the Weather API. For all endpoints and their full documentation, see resources in Table 6.</caption><thead><tr><td>Service</td><td>Endpoint path</td><td>Description</td></tr></thead><tbody><tr><td>Amalgamation</td><td>rest/amalgamation/amalgamate</td><td>Try to get all the requested parameters for the given location in the specified period. The service tries to fix QC failing data, missing data, and data that needs to be calculated.</td></tr><tr><td>WeatherDataSource</td><td>rest/weatherdatasource/location/point/Weather data sources and their parameters at a given location. Location (for instance "?latitude=60.8&longitude=23.5") to be added to the path.</td><td></td></tr><tr><td>WeatherAdapter</td><td>rest/weatheradapter/fmi/</td><td>Get weather observations in the IPM Decision's weather data format from the Finnish Meteorological Institute-https://en.ilmatieteenlaitos.fi/. Access is made through the Institute's open data API: https://en.ilmatieteenlaitos.fi/open-data</td></tr></tbody></table>

Norwegian Met. Institute (Båserud et al., 2020; Lussana et al., 2023; Müller et al., 2017; Nipen et al., 2020).

The WeatherAmalgamationService is a common entry point that aims to provide best fitting weather data for the user's needs, using available weather data sources (table 5). Weather data for a given location is automatically selected using source ranking (see figure 5).

An observation (weather station) is e.g. normally ranked above NWP output. For past and present weather data, NWP output can be used to fill in gaps between observations, for one or more parameters. Ranking is partly dependent on the location, as the spatial resolution, time resolution, update frequency and postprocessing quality may differ between sources and regions.

WeatherAmalgamationService can also perform other tasks to build the requested data set. The weather parameter Leaf Wetness is rarely measured and if required, can be calculated by the service. Also, if the weather data contains missing temperature data, the service attempts to fix gaps in the time series by simple linear interpolation of maximum one missing value. For use cases where it is important to maintain transparency to the origin and processing of weather parameters, the user can (instead of using the amalgamation service) also choose for data from a defined weather data source.

Weather data from an online source can be used for models in the DSS API by using the IPM Decisions JSON formatted standard format. The schema and the validation service for weather data are part of the MetaDataService. The MetaDataService also provides lists of the weather parameters and QC codes. WeatherAmalgamationService and some of the weather data sources deliver weather data in the abovementioned standard format, but for other weather data sources adapters have been developed. The adapter downloads the weather data and transforms it into the correct format for the DSS's. The adapters are available from the WeatherAdapterService.

National Meteorological Institutes have thorough quality control systems, and their observations are assumed to be quality controlled. Observations from private weather stations, however, are processed by basic quality control system (QualityControlService). Quality control consists of a logical
<table><caption>**Table 5:** Weather data sources currently recognized by the Weather API 2.</caption><thead><tr><th>Weather data source<fnref n="1" /></th><th>Region</th><th>Historic or forecast</th><th>Grid or station network</th></tr></thead><tbody><tr><td>Norwegian Meteorological Institute<br>https://www.met.no/<br>Met Éireann<br>https://www.met.ie/<br>Danish Meteorological Institute<br>https://www.dmi.dk/<br>Swedish Agricultural University<br>Meteorological Network<br>https://www.slu.se/en/faltforsk<br>Deutscher Wetterdienst<br>https://www.dwd.de/<br>Finnish Meteorological Institute<br>https://www.ilmatieteenlaitos.fi/<br>Agrometeorological Service of Norway<br>https://lmt.nibio.no/<br>Meteobot<fnref n="2" /><br>https://meteobot.com/en/<br>Fruitweb<fnref n="2" /><br>https://www.fruitweb.info/en/<br>METOS<fnref n="2" /><br>https://metos.global/en/<br>Météo Concept<fnref n="2" /><br>https://www.meteo-concept.fr/<br>Open-Meteo<fnref n="3" /><br>https://open-meteo.com/</td><td>Global<br>Ireland<br>Denmark<br>Sweden<br>Germany<br>Finland<br>Norway<br>Global<br>Global<br>Global<br>France<br>Global</td><td>Forecast<br>Forecast<br>Historic and forecast<br>Historic and forecast<br>Forecast<br>Forecast<br>Historic<br>Historic<br>Historic<br>Historic and forecast</td><td>Grid<br>Grid<br>Grid<br>Grid and stations<br>Grid<br>Grid<br>Grid<br>Stations<br>Stations<br>Stations<br>Stations<br>Stations<br>Grid</td></tr></tbody></table>

test and tests (Interval test, Step test and Freeze test) where threshold values can be set separately. If gaps in their time series are discovered, the service interpolates the missing observations.

<footnote n="1">¹ The availability of data from each of the providers, such as available parameters, spatial and temporal resolution may change over time.</footnote>

<footnote n="2">² Access to private weather stations will require login details.</footnote>

<footnote n="3">³ Open-Meteo is an open-source weather API and offers free access to weather data from multiple national weather services for non-commercial use.</footnote>
<figure><img src="image_6.png" /><figcaption>**Fig. 5:** Source ranking. At any European location (lat, long) the actor gets the presumable best weather data needed for the DSS in question. The Amalgamation service of the Weather API delivers the first choice of each parameter following this priority list.</figcaption></figure>

# 4. Application examples

## 4.1. IPM Decisions platform as user of the DSS and Weather APIs

IPM Decisions platform (https://platform.ipmdecisions.net/) is a web-based framework providing farmers, advisors and researchers access to a wide range of validated decision support systems and weather data from across Europe through a set of four dashboards. Figure 6 shows an example how model results are presented in user dashboard.

The DSS and Weather APIs are essentially built to serve this platform and consequently, the platform dashboards are the main users for the APIs.

The IPM Decisions Platform is initiated when users register, log in, and fill out background information for their farms. For each farm, the information needed is the location and crops, and selection the decision support models for specific pests that they like to follow during the growing season. The platform then daily updates the model status for each crop and pest combination using the newest weather data extracted from the weather API, and the users can get an overview of the model outcomes and warnings for their crops on any given day. The different dashboards enable comparisons between models, simulations with historical data, and experimenting with model parameters.

The interaction of the platform with the DSS and Weather API is displayed in Figure 7.

The platform uses the DSS API services to retrieve information from the DSS model metadata repository among other microservices. As the users in the Dashboard fill out information on their crops, the Platform requests DSS API for the available models for users to choose for their specific crops and locations. The model input schema stored in the DSS model metadata repository describes the input at the level needed to form it correctly. This allows the platform to request the API for necessary information and automatically create a web form for the user Dashboard, where the user is prompted to fill out the required parameters.

To improve and simplify users' experience on the platform, although the Weather API has multiple weather data sources, the platform utilizes the WeatherAmalgamationService of the Weather API. The weather dataset for the input file is created by deploying this service, which automatically
<figure><img src="image_7.png" /><figcaption>**Fig. 6:** User dashboard of the IPM Decisions platform. Results for a winter wheat model are shown in form of a bar chart, line chart and explanatory text.</figcaption></figure>

identifies the best weather data sources for the location of the farms and the requested weather parameters. The service also handles any necessary modifications to the weather data format and uses methods such as interpolation to refine the weather data before it is sent to the model.

Additionally, the platform provides an option for users to add their own private weather stations from external weather provider networks. Users can integrate these stations by adding their login details and weather station information. When this option is selected, the platform calls the `WeatherAmalgamationService` with the user's personal weather station information. The weather data from the user's station is then used, and if any parameter is unavailable, the platform will supplement it with data from the primary sources provided by the Weather API.

When the platform receives the result from the model endpoint, the representation of the result in the user dashboard is guided by the model output schema, available from the DSS API for each integrated model and describes for each model the way how to build and present the results.
<figure><img src="image_8.png" /><figcaption>Fig. 7: IPM Decisions platform flowchart. Integration with DSS and Weather API.</figcaption></figure>

## 4.2. Integration of a DSS in other webservices; VIPS as a user case

The Norwegian pest prediction platform VIPS (www.vips-landbruk.no) is an online forecast and information service for decision support in integrated management of pests, diseases, and weeds. The VIPS platform is open-source, and has been authorized by the UN as a global digital public goods (Liang et al., 2023). The VIPS web, targeting Norwegian agriculture is developed and managed by NIBIO in collaboration with the Norwegian Agricultural Extension Service.

The integration of the saddle gall midge (Haplodiplosis marginata) model for use in VIPS presents an example on how a crop protection software outside the IPM Decisions platform can use these APIs to implement an individual DSS model. The main approach of the integration is to provide a model of interest for test and validation through a service already well known to the Norwegian users. The saddle gall midge is a significant pest in many cereal-growing regions of northern Europe, which makes it interesting to provide the model for testing. The user interface (Figure 8) presents an interactive form where the user can select weather data and is advised to fill out the model input data such as starting and ending date for modeling.

An existing DSS (external to the IPM Decisions platform) such as VIPS can add a DSS model from the IPM Decisions platform by using the DSS API, optionally in combination with the Weather API. The metadata for each DSS in the platform describes all the vital characteristics of the DSS in a machine-readable form. This enables client software to integrate the DSS with a minimum of code. Once the client code has been created for one DSS, adding more DSSs will take only minor additions to the client code. In addition to this example and increasing interoperability for the DSS, several VIPS models are now also shared to other users through the DSS APIs of the IPM Decisions model repository.
<figure><img src="image_9.png" /><figcaption>**Fig. 8:** Illustration of how a DSS model from the IPM Decisions Platform is integrated in the VIPSweb. Source organisation for the Saddle Gall Midge Model is ADAS, UK.</figcaption></figure>

## 4.3. Integration in Python and in the OpenAlea: research-targeted modeling platform

A set of Python packages has been implemented to interact with IPM Decisions resources directly from the Python language, without knowledge of the web services. They offer a functional Python API to access weather data and run DSS models. The library is open-source and available from github and conda. These libraries are deeply integrated within the OpenAlea modeling platform, to allow researchers to compare DSS models with their own models, develop or test models in different conditions, or combine with their own production.

The Python library consists of three packages built on top of IPM Decisions Web services. These services provide access to weather data catalog (WeatherAdapterService), weather data sources (WeatherDataSourceService) and associated meta-informations (Meta的服务), together with DSS catalog (Meta的服务 for DSS) and DSS calling endpoints (DSS-Service) The first package (Agroservice, https://github.com/H2020-IPM-openalea/agroservice) allows to use IPM Decisions web services transparently from within Python, with minimal transformation of responses returned by web services. The two other packages (WeatherData and DSS) allow to convert textual information returned by agro-services into high level Python objects, handling weather data (i.e. taking care of units, localization and meta-information) and models (i.e. taking care of meta-information and formal description). An example is presented Figure 9 through a Python script executed in a Jupyter notebook.

Both resources (WeatherData and DSS) have been further integrated in VisuAlea, a visual programming interface shipped with OpenAlea (Pradal et al., 2008), that allow using and exploring the same resource in a visual programming environment (see figure 10).
<figure><img src="image_10.png" /><figcaption>Fig. 9: A Jupyter notebook tutorial for weather data and DSS.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Fig. 10: OpenAlea and VisuAlea integration. The resources of the IPM Decision platform are available through Python and in the package manager of OpenAlea. On the left, weather data services can be added using drag and drop, and their metadata are displayed. On the middle, the user can select all the DSSs, read their metadata, drag and drop them in VisuAlea and run them. On the right, two models provided by VIPS are connected to the same weather data sources.</figcaption></figure>
## 5. Discussion and conclusions

This paper presents the development and functionalities of new APIs for crop protection models and their weather input data management. The DSS API provides model metadata, data structures, and tools that help employing the DSS models. The Weather API provides help in arranging the weather input data for the DSS models, including access to European weather services, data set conversion and management. APIs are part of the IPM Decisions platform, yet they also serve external users. The models and weather data processing are provided openly to promote the use of IPM in cultivation. Links to all resources are listed in Table 6 below.

<table><caption>**Table 6:** Links to documentation and source code for DSS and Weather APIs</caption><thead><tr><td>Resource</td><td>Link(s)</td></tr></thead><tbody><tr><td>Documentation for all endpoints in the DSS API</td><td>https://platform.ipmdecisions.net/api/dss/apidocs/resource_DSSService.html<br>https://platform.ipmdecisions.net/api/dss/apidocs/resource_MetaDataService.html<br>https://platform.ipmdecisions.net/api/dss/apidocs/resource.html</td></tr><tr><td>Documentation for all endpoints in the Weather API</td><td>https://platform.ipmdecisions.net/api/wx/apidocs/#resources</td></tr><tr><td>Source code and documentation for the DSS API on GitHub</td><td>https://github.com/H2020-IPM-Decisions/DSSService</td></tr><tr><td>Source code and documentation for the Weather API on GitHub</td><td>https://github.com/H2020-IPM-Decisions/WeatherService</td></tr></tbody></table>

The work presented here improves how these models can be found, accessed, understood, and re-used. Easily accessible and properly documented models are available for comparison and testing, which promotes cumulation of knowledge and more transparent decision support. Open access to validated DSS models can effectively support IPM. The significance of this work lies in making these DSS models available for use in standard format and supporting their use with weather input data, and while doing so, also creating a digital infrastructure others can build on. Application cases show how the APIs are usable for operational services and indeed serve hundreds of users in the EU area already in dedicated online services for crop protection. We hope that the value of these APIs will be further explored and capitalized, and new successful implementations will follow. Increasing usage is a pathway for maintaining the system and securing its existence.

In software design, APIs are essential building blocks as they allow developers to connect different systems or their components without having to deal with all the complexity involved. REST (Representational State Transfer) is an architectural style (Fielding, 2000) that REST (or RESTful) APIs such as the DSS API and Weather API follow. Fixed APIs provide a powerful way to share functionalities for other developers build on top of them. The server-client approach with REST APIs as employed in this work is already a common solution in weather data provision, and many agricultural software are equipped for easy API employment. In the pest modeling context APIs have been successfully implemented for pest development simulation and meteorological time series generation (Fortin et al., 2022). Commercial API solutions such as Agrio (https://agrio.app/Agriculture-API/) provide access to pest and disease predictions for crop advisory tools. Norwegian VIPS online plat-
form for crop protection is also one example of utilizing APIs in the context of delivering IPM DSS.
New solutions can be tested and developed effectively in an environment where the work already
done by others can be built on.

Approaches behind the decision support models for crop protection are evolving, and that may
affect the need and use patterns of these APIs. This system is not set up for machine learning mod-
els, but our focus is for empirical and mechanistic models that are reviewed and seen as trustable.
Machine learning has become very promising, as data volumes and accuracies have increased both
for on-field collected data and for remote sensing. Capability to combine approaches and models
may be prove useful – for instance prognosis models can be effective with drones that can operate
AI-driven pest or disease recognition, or outputs from diverse models can be combined to provide
more accurate prediction.

Farm management information systems (FMIS) could be key future users of these APIs from
the farmer's perspective, though we currently lack application examples. FMIS are a common way
for farm enterprises to manage, document, report and optimize their production processes (Fountas
et al., 2015; Saiz-Rubio and Rovira-Más, 2020; Tummers et al., 2019). In the EU, FMIS are highly rel-
evant for agricultural operations, offering support for documenting cultivation activities, managing
nitrogen balances, facilitating subsidy applications, and, in some instances, assisting with crop pro-
tection decisions (Melzer et al., 2023; Munz et al., 2020). The FMIS hold source data for the DSS mod-
els (fields, soils, management dates, connection to data from AWS etc.) and are already commonly
used at the farm. Integration could also streamline the documentation needed to prove compliance
to IPM-based decision making. This compliance may be requested by the Common Agricultural Pol-
icy (CAP) rules, or by the commercial supply chain. To facilitate integration to FMIS, interoperability
and integration frameworks could be potentially effective, given that they are commonly used. We
found a lack of consensus among the FMIS service providers on both the approach and the formats
used. Since there was no de facto framework to implement, it seemed like best approach to provide
fixed APIs for the interested FMIS to adapt. APIs are versatile solution also in line with the current
evolution of smart systems and devices in agriculture (Antle et al., 2017; Zhai et al., 2020).

Keeping the continuity and high standard is a challenge for years to come. There is a protocol
for offering and approving a DSS model to the repository. New open weather data sources may
become available and can be added to the weather data catalogue. We here built a system to use the
often-scattered information and brought it together to improve the use for end users across the EU.
Finally, the described system aids end users and the EU in reaching the goal of making agriculture
more sustainable.
<table><caption>**Table 7:** Characteristics of the Weather API and DSS API</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Weather API</strong></td><td></td></tr><tr><td>Name of software:</td><td>IPM Decisions weather API</td></tr><tr><td>Developers:</td><td>Tor-Einar Skog, Brita Linnestad, Markku Koistinen, Aleksi Toivanen</td></tr><tr><td>Available:</td><td>Since 2022</td></tr><tr><td>Hardware required:</td><td>No specific requirement</td></tr><tr><td>Software required:</td><td>Docker OR Java JRE ≥ 17 + JEE8 complying application server such as WildFly v26</td></tr><tr><td>Availability:</td><td>Web services</td></tr><tr><td>Website:</td><td>https://platform.ipmdecisions.net/api/wx/apidocs/</td></tr><tr><td>License:</td><td>GNU Affero GPL v3</td></tr><tr><td>Cost:</td><td>Free</td></tr><tr><td>Programming language:</td><td>Java</td></tr><tr><td><strong>DSS API</strong></td><td></td></tr><tr><td>Name of Software:</td><td>IPM Decisions DSS API</td></tr><tr><td>Developers:</td><td>Tor-Einar Skog</td></tr><tr><td>Available:</td><td>Since 2022</td></tr><tr><td>Hardware required:</td><td>No specific requirement</td></tr><tr><td>Software required:</td><td>Docker OR Java JRE ≥ 17 + JEE8 complying application server such as WildFly v26</td></tr><tr><td>Availability:</td><td>Web services</td></tr><tr><td>Website:</td><td>https://platform.ipmdecisions.net/api/dss/apidocs/</td></tr><tr><td>License:</td><td>GNU Affero GPL v3</td></tr><tr><td>Cost:</td><td>Free</td></tr><tr><td>Programming language:</td><td>Java</td></tr></tbody></table>

## References

J. Antle, J. Jones, and C. Rosenzweig. Next generation agricultural system data, models and knowledge products: Introduction. *Agricultural Systems*, 155:186–190, 2017. doi: 10.1016/j.agsy.2016.09.003. URL https://doi.org/10.1016/j.agsy.2016.09.003.

C. Barton, A. Lee, M. Janssen, S. Leeuw, G. Tucker, C. Porter, and H. Jagers. How to make models more useful. *Proceedings of the National Academy of Sciences*, 119(35):2202112119, 2022. doi: 10.1073/pnas.2202112119. URL https://doi.org/10.1073/pnas.2202112119.

M. Barzman, P. Bärberi, and A. Birch. Eight principles of integrated pest management. *Agron. Sustain. Dev*, 35:1199–1215, 2015. doi: 10.1007/s13593-015-0327-9. URL https://doi.org/10.1007/s13593-015-0327-9.

L. Båserud, C. Lussana, T. Nipen, I. Seierstad, L. Oram, and T. Aspelien. TITAN automatic spatial quality control of meteorological in-situ observations, *Adv. Sci. Res*, 17:153–163, 2020. doi: 10.5194/asr-17-153-2020. URL https://doi.org/10.5194/asr-17-153-2020.

D.-G. f. C. EC. *European green deal – Delivering on our targets*. Publications Office of the European Union, 2021. URL https://data.europa.eu/doi/10.2775/373022.
E.P.P.O. PP 1/248 (3) Harmonized system for classification and coding of the uses of plant protection products. EPPO Bulletin, 52:17-24, 2022. doi: 10.1111/epp.12789. URL https://doi.org/10.1111/epp.12789.

K. Evans, A. Terhorst, and B. Kang. From data to decisions: helping crop producers build their actionable knowledge. *Critical reviews in plant sciences*, 36(2):71–88, 2017. doi: 10.1080/07352689.2017.1336047. URL https://doi.org/10.1080/07352689.2017.1336047.

F. Fabre, M. Plantegenest, and J. Yuen. Financial benefit of using crop protection decision rules over systematic spraying strategies. *Phytopathology*, 97(11):1484–1490, 2007. doi: 10.1094/PHYTO-97-11-1484. URL https://doi.org/10.1094/PHYTO-97-11-1484.

R. Fielding. *Architectural styles and the design of network-based software architectures*. University of California, Irvine, 2000.

M. Fortin, J. Lavoie, J. Régnière, and R. Saint-Amant. A web API for weather generation and pest development simulation in North America. *Environmental Modelling & Software*, 157:105476, 2022. doi: 10.1016/j.envsoft.2022.105476. URL https://doi.org/10.1016/j.envsoft.2022.105476.

S. Fountas, G. Carli, C. Sørensen, Z. Tsiropoulos, C. Cavalaris, A. Vatsanidou, B. Liakos, M. Canavari, J. Wiebensohn, and B. Tisserye. Farm management information systems: Current situation and future perspectives. *Computers and Electronics in Agriculture*, 115:40–50, 2015. doi: 10.1016/j.compag.2015.05.011. URL https://doi.org/10.1016/j.compag.2015.05.011.

E. González-Domínguez, T. Caffi, V. Rossi, I. Salotti, and G. Fedele. Plant Disease Models and Forecasting: Changes in Principles and Applications over the Last 50 Years. *Phytopathology*®, 113:678–693, 2023. doi: 10.1094/PHYTO-10-22-0362-KD. URL https://doi.org/10.1094/PHYTO-10-22-0362-KD.

M. Jalli, J. Kaseva, B. Andersson, A. Ficke, L. Nistrup-Jørgensen, A. Ronis, T. Kaukoranta, J.-E. Ørum, and A. Djurle. Yield increases due to fungicide control of leaf blotch diseases in wheat and barley as a basis for IPM decision-making in the Nordic-Baltic region. *Eur J Plant Pathol*, 158:315–333, 2020. doi: 10.1007/s10658-020-02075-w. URL https://doi.org/10.1007/s10658-020-02075-w.

P. Lehmann, T. Ammunét, M. Barton, A. Battisti, S. Eigenbrode, J. Jepsen, G. Kalinkat, S. Neuvonen, P. Niemelä, J. Terblanche, B. Økland, and C. Björkman. Complex responses of global insect pests to climate warming. *Frontiers in Ecology and the Environment*, 18:141–150, 2020. doi: 10.1002/fee.2160.

D. Liang, H. Guo, S. Nativi, M. Kulmala, Z. Shirazi, F. Chen, G. Kalonji, D. Yan, J. Li, R. Duerler, L. Luo, Q. Han, S. Deng, Y. Wang, L. Kong, and T. Jelinek. A future for digital public goods for monitoring SDG indicators. *Sci Data*, 10:875, 2023. doi: 10.1038/s41597-023-02803-x. URL https://doi.org/10.1038/s41597-023-02803-x.

C. Lussana, E. Baietti, L. Båserud, T. Nipen, and I. Seierstad. Exploratory analysis of citizen observations of hourly precipitation over Scandinavia, Adv. *Sci. Res.*, 20:35–48, 2023. doi: 10.5194/asr-20-35-2023. URL https://doi.org/10.5194/asr-20-35-2023.

E. Lázaro, D. Makowski, and A. Vicent. Decision support systems halve fungicide use compared to calendar-based strategies without increasing disease risk. *Commun Earth Environ*, 2:224, 2021. doi: 10.1038/s43247-021-00291-8. URL https://doi.org/10.1038/s43247-021-00291-8.
R. Magarey, J. Travis, J. Russo, R. Seem, and P. Magarey. Decision Support Systems: Quenching the Thirst. *Plant Disease*, 86:4-14, 2002. doi: 10.1094/PDIS.2002.86.1.4. URL https://doi.org/10.1094/PDIS.2002.86.1.4.

M. Melzer, S. Bellingrath-Kimura, and M. Gandorfer. Commercial farm management information systems - A demand-oriented analysis of functions in practical use. *Smart Agricultural Technology*, 4:100203, 2023. doi: 10.1016/j.atech.2023.100203. URL https://doi.org/10.1016/j.atech.2023.100203.

J. Munz, N. Gindele, and R. Doluschitz. Exploring the characteristics and utilisation of Farm Management Information Systems (FMIS) in Germany. *Computers and Electronics in Agriculture*, 170: 105246, 2020. doi: 10.1016/j.compag.2020.105246. URL https://doi.org/10.1016/j.compag.2020.105246.

M. Müller, M. Homleid, K. Ivarsson, M. Køltzow, M. Lindskog, K. Midtbø, U. Andrae, T. Aspelien, L. Berggren, D. Bjørge, P. Dahlgren, J. Kristiansen, R. Randriamampianina, M. Ridal, and O. Vignes. AROME-MetCoOp: A Nordic convective-scale operational weather prediction model. *Weather and Forecasting*, 32(2), 2017. doi: 10.1175/WAF-D-16-0099.1.

T. Nipen, I. Seierstad, C. Lussana, J. Kristiansen, and O. Hov. Adopting Citizen Observations in Operational Weather Prediction. *Bulletin of the American Meteorological Society*, 101-1, 2020. doi: 10.1175/BAMS-D-18-0237.1. URL https://doi.org/10.1175/BAMS-D-18-0237.1.

L. Nistrup-Jørgensen. IPM Decisions, Deliverable 4.9: Catalogue of DSS Collated with Details on Inputs, Outputs and Functionality, 2020.

C. Pradal, S. Dufour-Kowalski, F. Boudon, C. Fournier, and C. Godin. OpenAlea: a visual programming and component-based software platform for plant modelling. *Functional plant biology*, 35(10): 751-760, 2008. doi: 10.1071/FP08084. URL https://doi.org/10.1071/FP08084.

R. R Core Team. R: A language and environment for statistical computing, 2022. URL https://www.R-project.org/. Place: Vienna, Austria.

S. Rossi, S. Caffi, and Gilioli. Critical Success Factors for the Adoption of Decision Tools in IPM. *Agronomy*, 9:710, 2019. doi: 10.3390/agronomy9110710. URL https://doi.org/10.3390/agronomy9110710.

V. Rossi, T. Caffi, I. Salotti, and G. Fedele. Sharing decision-making tools for pest management may foster implementation of Integrated Pest Management. *Food Security*, 15(6):1459-1474, 2023. doi: 10.1007/s12571-023-01402-3. URL https://doi.org/10.1007/s12571-023-01402-3.

V. Saiz-Rubio and F. Rovira-Más. From Smart Farming towards Agriculture 5.0. *A Review on Crop Data Management*. *Agronomy*, 10, 2020. doi: 10.3390/agronomy10020207. URL https://doi.org/10.3390/agronomy10020207.

T.-E. Skog. IPM Decisions DSS API (v1.1. Zenodo, 2024. doi: 10.5281/zenodo.11190912. URL https://doi.org/10.5281/zenodo.11190912.

T.-E. Skog, B. Linnestad, M. Koistinen, and A. Toivanen, 2024. URL https://doi.org/10.5281/zenodo.11190933.
R. Sutherst, F. Constable, K. Finlay, R. Harrington, J. Luck, and M. Zalucki. Adapting to crop pest and pathogen risks under a changing climate. *WIREs Climate Change*, 2:220–237, 2011. doi: 10.1002/wcc.102. URL https://doi.org/10.1002/wcc.102.

F. Tonle, S. Niassy, M. Ndadji, M. Tchendji, A. Nzeukou, B. Mudereri, and H. Tonnang. A road map for developing novel decision support system (DSS) for disseminating integrated pest management (IPM) technologies. *Computers and Electronics in Agriculture*, 217:108526, 2024. doi: 10.1016/j.compag.2023.108526. URL https://doi.org/10.1016/j.compag.2023.108526.

J. Tummers, A. Kassahun, and B. Tekinerdogan. Obstacles and features of Farm Management Information Systems: A systematic literature review. *Computers and Electronics in Agriculture*, 157: 189–204, 2019. doi: 10.1016/j.compag.2018.12.044. URL https://doi.org/10.1016/j.compag.2018.12.044.

H. Wickham. Perform HTTP Requests and Process the Responses, 2024. URL https://CRAN.R-project.org/package=httr2. Type: R package version 1.0.1.

M. Wilkinson, M. Dumontier, I. Aalbersberg, G. Appleton, M. Axton, A. Baak, and B. Mons. The FAIR Guiding Principles for scientific data management and stewardship. *Scientific data*, 3(1):1–9, 2016.

Z. Zhai, J. Martínez, V. Beltran, and N. Martínez. Decision support systems for agriculture 4.0: Survey and challenges. *Computers and Electronics in Agriculture*, 170:105256, 2020. doi: 10.1016/j.compag.2020.105256. URL https://doi.org/10.1016/j.compag.2020.105256.

## Acknowledgments

This research was undertaken as part of IPM Decisions, which received support from EU funding programme Horizon 2020 (RIA, research and innovation, grant number 817617). The authors thank Dr. Frank Thomas Tveter (MET Norway) for technological and meteorological support and Dr., biologist Edward Kluen (Ramboll Oy) for suggesting edits to the manuscript.