How EO expertise powers agri-monitoring decisions (Part 3)
This blog post is the third part of a multi-post series.
# Introduction
The first and second parts of this blog post series introduced the Area Monitoring System (AMS) and the EO-WIDGET project. Furthermore, it covered user interface components, APIs (Application Programming Interface) and backend services developed in the EO-WIDGET context.
This third part describes the data pipelines integrating with paying agency systems, satellite data archives and monitoring products providers. It also gives details on how to get on board and benefit from our free demo service offer.
# Data Pipelines
Our agri workspace and user interface are no islands. They integrate in various ways with inbound and outbound data pipelines. So-called "glue code" is set up to make the workspace inter-operable with any external data interface.
# Paying Agency
The fundamental data source of the AMS are the Geo-Spatial Aid Applications (GSAA), in which farmers apply for area-based direct payments by declaring their parcels. These GSAA are provided by a paying agency to their individual secured data landing zone and imported into the agri workspace on a fixed schedule (e.g. monthly). The same may apply to other datasets like in-situ data or geo-tagged photos. While this pipeline code to transfer the data from the landing zone to the agri workspace is specific per paying agency, it leverages the agri workspace API and reusable code blocks for fast onboarding and safe code evolution. The data pipeline itself is integrated into our operations stack for monitoring, alerting and problem mitigation.
When the monitoring results are available in the agri workspace, another data pipeline is invoked for delivery to the paying agency in the desired data formats. This pipeline code is specific per paying agency and again exclusively leverages the agri workspace API to include any attributes that are useful to the paying agency, as well as manual annotations paying agency staff has made during the expert judgment routines (see first blog post (opens new window)).
Level of integration into the Integrated Administration and Control System (IACS) might vary, determining the data exchange frequency, the complexity of marker-based traffic light decisions per lane (group of parcels in the same EO-decision flow) and the share of information stored/archived in the EO-WIDGET Agri Workspace.
# Satellite Data
Viewing freely available products (Sentinel 1 & 2) mark the most basic case of our satellite data integrations -- they are simply registered by our View Server and served via WMS. For commercial satellite products, like Planet Fusion, a gate-keeper functionality is provided. This means that only those signal values and spatial extents are used and shown to the end user that have been activated by the paying agency. The advantage is that the paying agency does not have to buy entire satellite image scenes, but only pays for the area corresponding to "activated" parcels (for example all small parcels or a group of inclonclusive parcels). Phrasing it differently, Application Ready Data is distributed with a use-case-specific business model.
In general, monitoring algorithms need time series of numerical spectral values as input data. We continuously pre-process all available raw satellite imagery to speed up the training and evaluation of the monitoring algorithms and the response times in the user interface's chart widget. Several pre-processing methods can be applied, the most common being:
- cloud masking,
- harmonization along the time axis,
- generation of different spectral indexes.
Often the time series are aggregated over a parcel (object-based algorithms), but we can also make available all data points (pixel-based algorithms). Different pixel-based sampling methods can be applied before training of machine learning algorithms.
# Monitoring Algorithms & Products Providers
Since we envision an open value chain (see second blog post (opens new window)), our platform is open to any kind of monitoring algorithm and can exchange data with various product providers. If, for example, a paying agency or some external provider has developed a very well performing algorithm on a small area of interest (AOI), we can scale it up country-wide and deliver the results for each parcel declaration. The data pipeline concept introduced above is also leveraged here, ensuring that data may only enter or leave the agri workspace via a well-defined interface as provided through the agri workspace API.
Other scenarios involve potent image processing partners, who want to benefit from our interactive user interface (opens new window) and validation dashboards (opens new window). We are excited about industry collaborations, which bring maximum value to our paying agency customers.
# Free Demo Service
A free demo setup of our AMS solution is offered to interested paying agencies. All you need to provide are GSAA data (geometries & crop types) and you get your own cloud workspace and an instance of the AgriApp web interface configured with your data.
Additionally, affordable demo licenses for a defined AOI are available for processing of signals, monitoring products and compliance rules. All of these will be viewable in the AgriApp web interface and are available for internal inspection via APIs.
A live example of our services can be found at https://agri-ogd-at-public.demo.hub.eox.at (opens new window). Contact Gerhard.Triebnig@eox.at for further information!
# Conclusion
Our agri workspace offers flexible data pipelines towards the three main stakeholders of the AMS: A paying agency, satellite data providers and monitoring algorithm/product providers. There is a free demo service available for you to get on board right away and to try out the agri workspace with your own data.