Geo Fertilizer
1. Through his FMIS, the farmer requests and receives the geometries of his LPIS parcels and/or fields from the LPIS and parcel registration system provided by his national government.
2. The farmer requests a farm advisory service to provide a fertilizer advice. Through the FMS a request for advice, including the parcel geometry, is sent to the system of the service provider.
2.1 The service provider sends out a request for the soil information required for the specified parcel to a soil data service provider. The soil information (which can be just plain field-level data or a map) is delivered to the farm advisory service provider.
2.2 The service provider requests LAI data for the specified field from a remote sensing data provider. He receives a LAI map covering the specified field.
2.3 An agronomic model processes the available datasets (parcel data and geometry, soil data, LAI map) and generates a fertilizer application advice for the farmers field.
2.4The fertilizer application advice is sent back to the farmers FMIS
3. The FMIS receives the fertilizer advice and processes and stores the fertilizer advice in its data repository.
4. The farmer, through his FMS, transforms the fertilizer advice to an application map that can be entered into the board computer of his machinery. He loads the dataset onto the machinery and fertilizes the field. During the operational process, the local application rates are logged and stored.
5. The farmer transfers the logged data from the machinery to his FMIS. The FMIS processes and stores the dataset in the repository.
The potential of this use case is considered to be high, especially on a larger time span (ref. FutureFarm).
In its broadest terms the use case is relevant Europe wide. Arable farmers deal with the issue of optimization of yields, considering spatial variability of the field and crop status. They also deal with legislative as well as financial drivers to efficiently use their resources and to reduce the pressure on the environment. The specific implementation of the use case described here, where data regarding parcels, remote sensing images of crop status and local soil conditions are used to generate a fertilizer advice and where the farmer applies the advice and collects and stores the documentation for future use is not common for all farmers over Europe.
Farm advisory services that advice farmers in the optimization of fertilizer application can be found throughout Europe. The situation where the whole use case and its data transaction and processing is largely or fully automated is however hardly found. Nevertheless, several experiments and pilots that explore and implement (parts of) the use case are currently running.
The use case is relevant Europe wide. Nevertheless, the relevance of the use case will differ in different countries/regions. This is not so much specifically related to administrative region (country, NUTS area etc.), but to the geographic characteristics of the area, e.g.:
• The amount of variability the occurs on the field/parcel level
• The specific regulations and legislation that apply to a region
• The general implementation grade of on-farm and inter-company automation in agriculture
I) Actors
The actors that directly play a role in this use case are:
1. Farmer
1.1 FMIS
1.2 farm machinery
2. Contractors (optional, if specific work is subcontracted by the farmer)
3. Commercial service providers:
3.1. Farm advisory services
3.2. Soil data providers
3.3. Remote sensing data providers
4. National (or regional, e.g. Germany) governments as owner and operator of the LPIS
II) Stakeholders (other than the mentioned actors)
1. Software developers / vendors / application service providers
As the parties that are involved in the development of FMIS, services and models and the implementers of automated services supporting data exchange.
2. Machine industry
Providing the farm machinery and related hardware (and often also software).
3. European Union
As the legislative body that implements regulation on food security, CAP, INSPIRE etc., thus imposing all kinds of legislative, financial and technical conditions on this use case.
4. Retail
Retail promotes and sometimes forces the agro-sector to work in a sustainable matter. They have an interest in selling products that are (proven to be) sustainable.
5. Consumer
European consumers demand that the agro-sector produces safe food and reduce pressure on the environment. It is expected however that the specific problem of (over)application of fertilizer will attract less attention than for example pesticide application.
Relevant standards
• ISO-11783
ISO-11783 or ISOBUS is a world-wide recognized and widely implemented standard for on farm data communication. It supports standardized data communication and automated process execution on farm machinery. Besides, it supports the exchange of (operational) data from FMS to farm machinery and vice versa. It defines the data elements and code lists required in on farm data communication.
• AgroXML
AgroXML is the German standard for data exchange in the agricultural sector. Although is still has a low implementation grade, it seems to be the most evolved standard in the area of pre-harvest data exchange between FMIS and other business parties. Current implementation supports FMIS to government and probably FMIS to soil data provider.
• EDI-teelt
EDI-teelt is a Dutch standard for data exchange in arable farming which is mostly used in post harvest agri-business and tracking and tracing applications. Although it’s fairly wide spread in the Netherlands, it does not support the geofertilizer use case. A new version of the EDI-teelt standard is currently developed that will support data exchange between farm and other parties for pre-harvest business processes.
• UN/Cefact
The standards developed by UN/Cefact support “electronic business”. They cover a wider range of domains (financial, administrative, technical). In the technical working group on agriculture, a few business cases are covered or in development. Although they do not directly cover (parts of) this use case, it is good practice to at least consider reuse of generic core components and of relevant code lists.
• (E-)Daplos
The Daplos standard (flat file) is widely used in France, E-Daplos is hardly used. No links exist with the geo fertilizer use case.
• OGC
In order to be able to integrate with current and future spatial applications and infrastructures, to fit with data exchange on related domains and to comply with INSPIRE practices, spatial data exchange should be compliant with OGC standards. Currently OGC standards are not supported widely in agri-business data exchange. AgroXML implements part of the OGC/GML specifications and can be considered OGC compliant. ISO-11783 uses its own, non-OGC compliant implementation for geometries (which is actually not very different from the OGC implementation). EDI-teelt and UN/Cefact standards hardly or not support spatial information, although the EDI-teelt version that is currently under development will be OGC compliant.
Current standards cover both on-farm data exchange and exchange of data between farmer and business and governmental parties. However, on-farm exchange uses different standards than inter organisations exchange, so adapters/converters are required. The different (often national oriented) standards for inter organisational data exchange are not compatible. Besides, they currently only partly or not support the geo-fertilizer use case.
Dictionaries
Required dictionaries are usually an integrated part of the standards used. If required, dictionalies like AgroVOC or GEMET could be used to derive additional code lists.
Relevant legislation and regulations
• CAP
CAP regulations and their national implementations impose conditions on the amount of fertilizer and the timing of fertilizer application.
• INSPIRE
The INSPIRE directive imposes requirements in specific domains regarding (meta)data and data exchange. This will most probably influence
• Food safety regulations
E.g. hygienic issues that restrict the application of manure on grassland. Related to restrictions regarding transport of manure.
Technologies
• EDI (Electronic Data Interchange)
Based on the exchange of specialized messages between automated systems (e.g. through e-mail). Many currently operational legacy EDI services are based on UN/EDIFACT. Currently more and more EDI is based on the exchange of XML based messages.
• SOA (Service Oriented Architecture)
Service Oriented Architecture is based on the exchange of data through web services. It is supported by a series of standards (e.g. XML, SOAP, WSDL, OGC standards). In many cases, the SOA architecture is connected to a back-end of transactional systems.
• Process automation
More in general, many business processes have been automated in the last decades. We can observe this in on-farm automation, where processes on FMIS and agricultural machinery are more and more automated and a lot of work is done on the on-farm integration of FMIS – machinery interaction. The same kind of developments can be observed on the area of inter-organisational automation of processes by governments (e.g. LPIS, exchange of field info for subsidy application) and service providers.
• GIS and location based services
Location specific application of fertilizers requires the use of spatial information (parcel boundaries, soil maps, LAI maps, application maps) and the storage and processing of spatial information through GIS. Besides location based services are required, using satellite navigation or comparable positioning systems to determine location as a basis for location based appliance of fertilizers.
The most commonly occurring variants are (probably):
• A farmer advisory service acts as the service provider that collects relevant data required to make a fertilizer advice. These relevant data are translated (usually manually and using advisors and/or farmers expert knowledge) to a fertilizing advice. The advice is subsequently translated by the farmer to his daily operational planning, either manually or by entering the advice into the FMS and generating an application map for automated application in the field.
• In the most automated variant of this use case, a large part of the data collection and advice generation by the service provider is automated, using automated data collection and agronomic models. Data are exchanged between provider and FMS through a standardized data exchange protocol and are automatically translated (possibly after editing the advice by the farmer in his FMS) to farm machinery. Documentation of field operation is collected and transferred to and stored in the FMS.
• Different parts of the use case could be implemented in a different (technical of functional) way:
- LAI data could be provided real-time in the field through LAI sensors
- Part of the role of the farmer could be performed by a contractor
- Different components (e.g. the agronomic model) could be implemented as part of the FMIS
- There are no widely accepted standards on the European level for the exchange of data required in this use case. This concerns the exchange between FMS and government, between FMS and fertilizer advice provider and the exchange between fertilizer advice provider and the providers of soil data and remote sensing data.
- Commonly used data exchange standards in agriculture (like UN/Cefact) are very limited in their support of spatial data and do not support the OGC standards.
- ISO-11783 is still not fully supported by all machine vendors, which can hamper the seamless data exchange between FMS and machinery.
| BPM reference | Description | Attributes/Data |
|---|---|---|
| A | Field parcel boundary request from FMIS to Government | Field ID |
| B | Sends field parcel boundary information from Government to FMIS |
Field ID Vector data; polygon coordinates |
| C | Request of fertilizer advise from FMIS to Advisory service |
Field ID Plant, variety Seeding date Previous plant Applied fertilizing within the growing season |
| D | Send fertilizer advise from Advisory service to FMIS |
Plan ID Field ID Application method Average application rate Application map Amount of nutrients per site (N, P) Forecast probabilities (e.g. workable time) Relevant rules for type and amount of fertiliser, timing, allowed locations, costs - choices - warnings |
| E | Request of LAI GIS data of the field parcel from Advisory service to LAI service |
Field ID Plant; variety Seeding date |
| F | Send LAI GIS data from LAI service to Advisory service |
Field ID Plant Status of the growth Type of observation; LAI Map with classified LAI zones; vector or raster Attribute values per zone |
| G | Request soil data from advisory service to Soil data service |
Field ID Plant; variety Previous plant |
| H | Send soil data from Soil data service to Advisory service | |
| I | Send task file (control settings for the fertilising machine and operation) from FMIS to Fertilization machine |
Field ID Date Worker ID Machine ID Control setting values for the specified types of settings |
| J | Send fertilizing documentation from the Fertilizer machine to FMIS |
Field ID Date and time Worker ID Machine ID Aggregated process information; type and attribute - summarised realised work performance (ha/h) - summarised amount of applied fertilisers - remaining fertilising work - summarised recorded monitoring information (e.g. soil moisture, biomass values, etc.) - notes for fertilising process adjustments |
| Z | Test |
Test (XML) ID (Integetr) |
- Fertilization advice reply (Dutch)
- Fertilization advice request (Dutch)
- Fertilization instruction delivery
- ISOBUS interface for fertilization task to and from working set
- LAI measurement delivery
- LPIS information retrieval (Dutch)
- Parcel boundary request
- Request for LAI index measurement
- Request for fertilization advice
- Request for soil data
- Soil data delivery
Although more research and interaction with the agro-community should be performed to obtain a full list of recommendations, this could be a first starting point.
• Regarding the exchange of parcel information between farmer and government, current developments on European as well as on national level should be examined. The EU sets conditions through regulations and guidelines as well as through the INSPIRE framework. A range of initiatives in various countries works on implementation of such data exchange services. Both compliance with EU developments as well as harmonization with existing initiatives are necessary to accomplish a Europe-wide harmonisation.
• In general, harmonisation and standardisation of data exchange between farmers and external parties (or between FMIS and the automated systems of these parties) should be compliant with (or at least not be incompatible with) currently operational standards. This concerns at least the following standards:
- ISO-11783
- UN/Cefact
- OGC
• One of the core requirements for harmonisation would be the harmonisation of the relevant “code lists” that are used in data exchange. Two strategies could be followed: (1) to facilitate the reference to various sets of code lists and to provide translation services or (2) to integrate existing code lists into one harmonized code list.
agriXchange project team
Facebook
LinkedIn
Comments
Former LORIS service
This use case follows the former LORIS serviceconcept provided by Kemira GrowHow in Finland.
State of implementation
This use case is not implemented at the moment.
test
test