OGC Testbed-16: Analysis Ready Data Engineering Report

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Decision makers want to have data that help them to make informed decisions. Decision makers require data ready for direct interpretation (Interpretation Ready Data: IRD). This requirement dictates that somebody transforms the raw data into IRD before being provided to the decision makers. Analysis Ready Data is an effort to define a better way to divide the processing and transformation efforts between the producer and the user based on a common agreement on a solution independent form the domain of application. Producers will make available ARD that will be organized by the user (or by common processing facilities such as the ESA DIAS) into data cubes, regular time intervals data cubes, or another optimal data organization before executing a specific analysis such as a Land cover classification or a phenological study. These data will be analyzed by the customer organization and the results will be presented as IRD to the decision maker.

ARD is an abstract concept that can only be implemented in the context of a common domain of application. However, several definitions have been proposed and some of them are collected here:

From these definitions and the observation of the current ARD products, the Testbed participants extracted some of the common characteristics that data should have to be considered ARD:

Even the though the ARD concept originated in the remote sensing community, none of these definitions limits the concept to only satellite remote sensing data.

CEOS is adopting the following definition of ARD:

"Satellite data that have been processed to a minimum set of requirements and organized into a form that allows immediate analysis with a minimum of additional user effort and interoperability both through time and with other datasets" [5]

In principle, this definition is not limiting the use of the data to a particular domain. However, in practice this has been the case because the definition was initially formulated and adopted by the CEOS ARD for Land (CARD4L). This obviously assumes that ARD is created for the land community. However, the same definition is now being used in other emerging domains such as aquatic media or atmosphere.

During the processing required by CARD4L, the products are resampled onto a common geometric grid (for a given product) and provide baseline data for further interoperability both through time and with other datasets.

CARD4L products are intended to be suitable for time series analysis and multi-sensor application development. They are also intended to support rapid ingestion and exploitation via high-performance computing, cloud computing, and other future data architectures.

In practice, every type of sensor content could be processed to produce a type of ARD. This type of ARD represent a realization of the definition into a concrete product type. The definition of the characteristics required for theses product types are collected in Product Family Specifications.

Currently the CEOS CARD4L website offers the following PFS:

CEOS is also preparing a PFS for aquatic media:

CEOS is also considering extending the concept to the atmospheric domain.

As stated above, the ARD concept originated in the remote sensing community. In the opinion of the authors of this ER, the CARD4L definition for remote sensing can be extended to address other domains in which geospatial data is created. Indeed, the characteristics of the ARD listed above are not exclusive to satellite data and can be expressed in the following general concepts:

Every data type could have its own PFS that lists these requirements.

The CEOS definition of ARD focuses on the semantics aspects of the data but intentionally avoids mentioning technical details on how the data should be made available. The definition does not give indications about the data format or the data APIs that should be used to provide ARD. The CEOS definition focuses on content readiness instead of technical readiness. Content readiness is a necessary step for easy analysis that clarifies the semantics of the data. Some researchers are also sensitive to technical readiness and consider readiness part of what ARD should be. In this section we present two degrees of technical readiness that some actors, particularly in the private sector, consider as part of the requirements defining ARD. The implications of the technical readiness in the concept of CEOS ARD are analyzed in the CEOS Interoperability Terminology [7] document, on section Analysis, Access, and Analysis Ready Data

Research centers can also provide ARD. Production of ARD can be the result of their pre-processing of data in preparation to environmental research projects such as forest status, land cover change etc. Since they already do that for themselves, they may decide to distribute the ARD for the benefit of others.

The Global Land Analysis and Discovery (GLAD) laboratory in the Department of Geographical Sciences at the University of Maryland produces another ARD product based on Landsat. The essence of the GLAD ARD approach is to convert individual Landsat images into a time-series of 16-day normalized surface reflectance composites with minimal atmospheric contamination. The global Landsat ARD product is provided as a set of 1x1 degree tiles. Each data granule is provided as a GeoTIFF file containing observation data collected for a single 16-day interval. There are 23 intervals per year. This product is not trying to infer BOA radiation using a model of the atmosphere (as the USGS ARD does). Instead GLAD is trying to harmonize the radiation using places on the Earth where radiation is supposed to be constant (pseudo-invariant areas). In addition to that, GRAD is providing a product that is regularly distributed in time.

ARD from GDAD can be downloaded here (registration required).

Mainly companies providing ARD are looking for a niche by facilitating usage of data by their costumers. Actually, the lack of a clear existing product for Sentinel-1 and Sentinel-2 that can be considered ARD created a niche for offering products that can be branded as ARD. The following paragraphs provide some examples.

EOX IT company is a partner in the DIAS MUNDI and is helping to develop more efficient ways how to disseminate the Sentinel-1 and Sentinel-2 data and information. EOX produce land use and agricultural applications such as crop classification and crop monitoring resulting in what EOX call CAP Analysis Ready Data. More details can be found in the EO4Agri project report.

Terramonitor is another company offering ARD Terramonitor describe their ARD offering as a cloudless mosaic of preprocessed satellite data with 10-band multi-spectral data. The images used for mosaic are atmospherically corrected and radiometrically calibrated. The product is suitable for different use cases such as analyzing and monitoring land areas, vegetation, forests, and calculating indices.

Instead of offering ARD, PCI Geomatica is creating and selling a set of tools to create ARD or improve existing ARD. These tools cover areas such as intercalibration of reflectance or radiance data, topographic normalization, geometrical correlation and data quality masks. PCI Geomatica is using Open Data Cube as a repository for ARD and provide tools to direct ingestion of the data in ODC [15].

Astraea is providing a service to simplify the process of using satellite information using a facility they call EarthOnDemand to access ARD and another service called EarthAI Workflow to process ARD and extract results. In this case, the offering is more focused on providing a platform to process ARD.

The ARD phenomena has stimulated the creation of continent wide ARD platforms. These are the most well-known:

Digital Earth Africa (DE Africa) is a platform for the African nations. Users can access high-resolution satellite images from a single platform. DE Africa has made available a vast amount of data captured by ESA Sentinel-2 satellites in a format that makes the imagery accessible and suitable for general use. Satellite images captured by Sentinel-2 are particularly important for Africa because they offer 10 m resolution and are captured every 5 days, so land and water can be analyzed in unprecedented detail (https://www.digitalearthafrica.org/). DA Africa uses the Open Data Cube open source solution.

Digital Earth Australia (DEA) is a platform that uses spatial data and images recorded by satellites to detect physical changes across Australia in unprecedented detail. DEA prepares these vast volumes of Earth observation data and makes it available to governments and industry for easy use (http://www.ga.gov.au/dea/about). Not surprisingly, DEA also uses the Open Data Cube, as the Digital Earth Australia is an active part of the Open Data Cube (ODC) development.

Euro Data Cube provides a one-stop-shop for EO and a platform to analyze an event or phenomena from different perspectives, providing multiple data sources in a way that several variables can be compared and correlated at the same time in a customized data pipeline. Euro Data Cube is a combination of several services in a single platform. (https://eurodatacube.com/documentation/about). Euro Data Cube is a proprietary solution developed by a partnership between industry leading companies. However, the solution shares some similarities with the ODC such as the use of similar python libraries and XArrays numeric libraries.

Processing ARD takes time and effort. If all the areas of the data are considered equally interesting and there is an expectation that data is going to be consumed several times, an approach based on executing the processing chain to create ARD as soon as a new fragment of information is acquired is reasonable.

In this approach, the data is divided into a regular grid of big pieces (sometimes referend as granules) that are made available as files to be downloaded. The producer needs to have enough storage space to be able to offer all possible granules in an agile way.

To facilitate the process for occasional users, a data discovery facility could be setup. A web portal allows specifying the area of interest and the time period required and a list of links to access the individual granules that matched the conditions is created. Each link gives immediate access to the data at the granule level.

For recurrent users, the provider should include an API that enables machines to automatically download the needed resources. A SpatioTemporal Asset Catalog (STAC) can be used to implement a machine-to-machine download facility.

Sometimes a granule might be too big compared to the consumer’s region of interest or the region of interest could be accidentally in between four granules. In these cases, a facility that provides the capability to clip and extract the area that the users' need could be an interesting alternative to a pure file-based download system.

To facilitate the process for occasional users, a data discovery facility could be setup. A web portal allows specifying the area of interest and the time period required. Instead of a list of links to access the individual granules, an on-demand dataset is created with the data clipped to the area requested and the granules involved mosaicked.

This approach still requires preparing the ARD from the original sources and adds the need for some computational resources to process the area of interest

For recurrent users, the provider should include a web service accessed via an open API that allows machines to automatically download the needed resources. The OGC Web Coverage Service (WCS) or the emerging OGC API - Coverages can be used to implement a machine-to-machine download facility.

In this case, the ARD is not available directly and is created as part of the request process. This option addresses two possible cases: Lack of space for the provider to store the ARD and need to adjust some parameters before creating ARD.

To facilitate the process for occasional users, a data discovery facility could be setup. In this case, the web portal will allow for discovery of potential ARD products based on the existing raw data. There is the possibility of specifying parameters to condition the way the ARD will be generated (e.g. the possibility to provide a better DEM of the region of interest). The processing takes time and the actual products are delivered asynchronously. A common practice is to email the consumer when the products are ready to download.

Some asynchronous responses are difficult to automate (such as the email responses). For machine-to-machine communication it is better to use another form of notification such as an HTTP page that can be visited regularly until the products appear. This approach can be implemented as a WPS service. Other approaches may rely on a PubSub protocol such as MQTT.

This approach reduces the need for storage space but creates the need for scalable processing capabilities.

Finally, the producer can delegate to the user the production of ARD. This way, the producer provides the necessary raw data as well as a software and auxiliary data to create ARD. The consumer will have to download the raw data and create the ARD in his/her computer infrastructure. The distribution of the software can be done as executable files that are specific to an operating system. When the setup process has several dependencies, the distribution can be encapsulated in a virtual machine for easy deployment or as a Docker container. The latter is useful for a deployment in the cloud when the consumer does not have enough inhouse computing capacity.

This scenario is ideal for immediate deployment of new types of ARD without forcing the producer needing to deploy new storage or computing facilities.

The sen2cor module developed and distributed by ESA is an example of this kind of tools. Sen2cor is capable of taking a Sentinel-2 Level 1B and applying a transformation that generates ARD Surface Reflectance (Sentinel-2, Level 2A). This tool was initially distributed as part of the Sentinel Application Platform (SNAP) for anybody to download. With time, ESA was able to deploy the necessary storage capability to distribute it as a new product in its Sentinel Data Hub.

This chapter reviewed a set of approaches to provide analysis ready data to the users. In the next chapter, a set of tools to use ARD is presented.

Currently there are not many satellite products that can be considered ARD, so discovering these products is not difficult. In the future, an increase in the number of products available is expected. This trend includes the generalization of the PFS for many other data types. In the future, metadata catalogues will be needed to identify ARD products using a metadata element such as a keyword, a tag or a URI and also indicate which ARD type (i.e. PFS) the product complies with.

Satellite information (as well as remote sensing based ARD) is still distributed in large files. Imagery collected for entire satellite orbits and paths (considering the swaths they cover) are too large to be saved in a single file so they are cut into a series of scenes and granules that make the management of the files practical. Unfortunately, a pure file system is not prepared for geospatial data indexing. Therefore geospatial information in files is limited to scene identifiers and dates encoded in the file name (that is repeated in some internal metadata format). Still, the list of files necessary for the study of a region over time is very large and the names of the files are not easily queryable therefore becoming confusing and difficult to manage. This can be solved by adding an application that applies a spatial index, such as a R-Tree, on the file system. Some datacube implementation uses this solution.

Datacubes are a good alternative to a file system-based approach as they permit ingesting the files into a database that simplifies the access to the data. A data cube is a data structure that represents a multidimensional array together with metadata describing the semantics of the axes, coordinates, and cells. A data cube may have horizontal (i.e. x/y, lat/long), vertical spatial axes, temporal axes, or any other application dependent dimensions. These data structures as stored in database systems that is able to deliver data on demand. For Remote Sensing based ARD, the system will ingest the files and index the data in the multidimensional cube for fast access. Afterwards, the system is capable of handling requests for data that is inside a geospatial bounding box and a time interval and provide an agile response containing lists of elements (e.g. tiles) that comply to these constraints ([17]).

Each database system provides its own way of formulating queries and encodings to receive data. From the interoperability point of view, the Coverage Implementation Schema (CIS) specified in the OGC Web Coverage Service WCS 2.0 Standard is a good interoperable tool to both describe the datacube dimensions and values and to also retrieve the content of a multidimensional coverage stored in the datacube.

As it is designed to support consistent time series that are ready for analysis, CARD4L compatible products are populating datacubes. Unfortunately, there are still important barriers for some studies: Continuity and regularity. Optical products are frequently affected by clouds. This has two effects: Some scenes are so covered by clouds that cannot be used, others present occultations and shadows that need to be masked. Other products are not sensitive to clouds but the geometry of the revisiting periods still becomes irregular. Datacubes should incorporate some tools to fill the gaps in images with occultations and are able to create artificial products that are completely regular in time by interpolating dates. Some authors ([18]) suggest that cloud free data and regular time series of cloud free data are two other types of higher level ARD.

ARD reduces the user’s effort by providing the data in a more friendly and consistent manner. Datacubes are a solution to organize and access the data. Unfortunately, they require a significant effort in terms of hardware infrastructure, data download, data ingestion, data management etc. Every user will be forced to repeat the same process. Datacubes provide tools to automate the process. However, instead of building their own datacube and ingesting the data, users should be able rely on someone else to do that for everyone and provide a datacube as a service over the Internet.

This is precisely the objective of the ESA and EC Data and Information Access Services (DIAS). Each DIAS provides a cloud processing capability in an environment where ARD has been already organized as datacubes accessible through APIs. To analyze the data, users have two alternatives: learn a processing language provided by the system or send the code directly to the processing infrastructure to execute it. The second alternative is more interoperable because the same code will work on different processing infrastructures with minimum modifications in the way the data is access. Docker containers are one of the most popular ways of sending code to a remote processing facilities. A Docker container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. Container images become containers at runtime and in the case of Docker containers - images become containers when they run on Docker Engine. Containerized software will always run the same, regardless of the infrastructure. Containers isolate software from its environment and ensure that it works uniformly despite differences for instance between development and staging. Containers and virtual machines have similar resource isolation and allocation benefits, but function differently because containers virtualize the operating system instead of hardware.

Docker containers can be deployed in infrastructures that give access to datacubes of ARD. The code in the container can immediately start analyzing the ARD. The capacity of the analysis will depend of the type of the ARD available to the users in the infrastructure. Many, if not all DIAS, offer docker container execution. The different DIAS are trying to specialize their approach to find their markets. One specialization approach is to facilitate as many ARDs as possible to attract more users and algorithms.

Considering that the use of cloud processing environments (and Dockerized environments in particular) is not for free, the dilemma between the use of Dockerized environments versus owned datacube infrastructure is similar to the dilemma of renting versus owning a car. The decision as to which approach really depends on the intensity of usage. If an organization or user knows that they are going to use ARD from a particular area frequently for different studies, owning the infrastructure could be a good option. Conversely, if the aim is studying a large geographic region for solving a particular problem, the cloud processing environments can be a more viable solution.

A proposal for an ARD federated architecture is the focus of the next chapter. A requirement is to avoid "lock" into a particular cloud infrastructure.

The concept of federation in information technologies is broad. The OGC Testbed 15 Federated Clouds Security Engineering Report (OGC 19-024r1) [19] suggests that the concept of federation can be interpreted as four different facets:

In the OGC 19-024r1 ER, the concept of federation is interpreted as an Identity and Authorization Federation where authentication and authorization are managed in a coordinated way across a group of computing or network providers with and agreed standards of operation (such as OpenID connect).

In OGC Testbed 16, in the context of ARD, federation is interpreted as a Service Federation: A group of organizations providing their own infrastructure, analytics, and data. In this federation, elements are part of a loosely coupled solution for performing automatic analysis (ARD) across these multiple clouds. There are nodes that provide access to ARD (that can be preprocessed ARD coverages or on-demand ARD processing results) and there are nodes that provide processing capabilities that are combined together in a single infrastructure.

Currently a federation that integrates different cloud providers faces the difficulty that each provider has its own architecture and their own way to facilitate access to data and execution of analytical algorithms. There are some practical solutions to this issue available:

With some exceptions, such as Google Earth Engine, it seems that heterogeneity of alternative solutions for the cloud is converging into a common solution similar to the Terradue proposal: A Docker package based on Linux virtual machines. A virtual machine of this kind contains all the necessary elements that allow executing code written in a common languages. R and Python are interpreted languages that do not depend on specific hardware, so they are preferable in heterogeneous hardware environments. Java and C++ are also alternatives but they require some level of compilation in any new hardware environment adopted by the federation. In principle a Docker package could access data directly from files but organizing big data repositories as files is not scalable.

An alternative is to access data through an API. This is the configuration that four of the Copernicus Data and information Access Systems (Copernicus DIAS) are using: CREODIAS, MUNDI, SOBLOO and ONDA. They use a form of storage called object storage. This is the preferred storage for immutable "Big Data" (up to Petabytes). The storage is designed for write once, read often as indexed blobs. This approach is much simpler to manage and extend than file or block storage and much cheaper. An object storage cannot be requested as a normal file and requires an API to transfer the data that will then later be handled as "normal" files. CREODIAS, MUNDI and SOBLOO all use S3 (AWS, GCS standard) object storage. ONDA uses ENS (OpenStack Swift). An example is how the Wekeo API enables retrieving the data from the object storage into a "file" that becomes available.

In this situation, the starting point for a federated architecture will assume that for each node of the federation:

A Federated ARD architecture should support a broad variety of data types and analytics. The data should not be limited to remote sensing imagery and should include other forms of information such as a long time series of in-situ measurements. Handling the variety of formats and data types cannot be left to the final user. Instead, a common data model should be used. The data cube approach provides a layer of abstraction where data are sequences of values associated to a position and time (and eventually other dimensions). Products are then mapped into this data structure that defines the physical dimension of the space and the way the space is mapped into a discrete multidimensional grid. Each measurement arriving (each new remote sensing scene or each in-situ measurement data point) is mapped into the grid definition and the values are stored in cells of the grid. The data cube can be subsetted and resampled in each dimension to retrieve the information that is relevant for a study. The data is recovered in a data structure that contains the definitions of each dimension and the values available on the grid as well as the meaning of the values attached to the cells of the grid. This common data structure is very similar to the memory representation of a NetCDF/HDF format. The same data structure is directly mappable into the OGC Coverage Implementation Schema (CIS) used by the OGC Web Coverage Service (WCS) Standard. The CIS also defines a DomainSet that is equivalent to the definition of the dimensions and a RangeType that provides information about the values type and meaning.

In Python, a good data structure for representing this multidimensional data cube is the XArray. XArray is based on NumPy that provides the fundamental data structure and API for working with raw multidimensional arrays. However, the NumPy data structure lacks the necessary metadata to assign array values to locations in space, time and to describe the meaning of the values in the array.

The following example describes a multidimensional array of a matrix of 9 points in space each one with an array of thirty measurements. Each measurement contains two variables: Liquid precipitation and ice precipitation. The three coordinate values and the array of thirty values are listed.

In a federation, deploying the same application into different nodes is possible. Each node will get access to the object storage easily accessible by that node. Only the results of the process are transmitted back to the user. Ideally, results will be classifications or summaries of the data that will be smaller in size than the original data.

There are cases where this can be done easily. Let’s imagine a use case that requires the most updated imagery available to look for anomalies. A USGS cloud facility provides access to Landsat imagery and a Copernicus DIAS facility will provide access to Sentinel-2 imagery. To find the most recent imagery a process in both facilities is run to get the date of the most current product. The user only gets back two dates and compares which one is newer and determine the facility that has that content. Then the user executes the process that extracts anomalies in that facility. Only an anomalies map is sent back to the user. In terms of data traffic, the solutions resulted in a very efficient flow.

There are other use cases where distributing efforts in an optimal way in a federation is not so easy. Imagine a use case where a time series of optical data (as many points as possible) is needed for a phenological study. Phenology is the scientific study of periodic biological phenomena, such as flowering, breeding, and migration, in relation to climatic conditions. The arrival of the spring is perceived as a sudden appearance of leaf. Since most of leaves are green this change can be detected in a time series of optical remote sensing images covering the year. There is sudden increase in the green and the infrared component in one particular day of the year that will depend on weather conditions as well as in the species of plant present. A map that represents the day of the year with the sudden increase in the green and infrared components is called a greening map. Again, the USGS (with Landsat data) and Copernicus cloud facilities (with Sentinel-2 data) is available. If the user wants to analyze a single point in space, a simple request for a time series extraction of the point to both facilities is issued and the user gets back two time series: One for each sensor. The user could then combine both series and extract the start of the greening period.

Now imagine that the user wants to build a greening map at the same resolution as the original imagery. Each cell of the map will represent a date in the year where the greening starts. If the previous workflow is repeated for each pixel of the intended raster, this will result in millions of atomic requests - one for each point in space. This is going to be very inefficient. In this case, the reasonable thing to do is to request the imagery to both facilities and combine it locally. This minimizes the number of requests but requires transferring the data to the remote processing. Moving the analytics to the data seems impractical for this use case. However, the amount of data generated by the Sentinel-2 A and B tandem is about 3 times bigger than the data produced by Landsat 8. Considering that, a solution that will minimize the amount of data transmitted via the Internet would be to have the processing code in same facility as the Sentinel-2 repository and only moving (duplicating) Landsat data into the Sentinel repository. This way an enriched Landsat-Sentinel time series can be created without the need to move and duplicate the Sentinel-2 data. In this configuration, the user will generate the greening map at the Sentinel-2 processing facility and send the map back to scientists to compare the current map to previous years and eventually detect and report about interannually changes.

As a general principle, once the data was been downloaded, protecting that data by technical means is almost impossible. Only encrypted data that is shown on the screen (or reproduced as multimedia) can be protected. Data for analysis needs to be accessed and, at that instant, can be duplicated. One way to avoid the problem in the first place is to allow running processes at the premises of the provider. In this model, the remote processes access the data and produces the result. If the process serves as a proxy (shares identity and privileges) for the user, then the process will have access only to a subset of data originally agreed to. The process is remotely executed and only the result of the execution is sent back to the user.

Even if viewed as a good solution, in practice executing code in a remote facility generates all sorts of potential security problems for the provider. One can easily imagine a process that copies the data into an encrypted format that is still considered a valid result. Once the result is downloaded and decrypted in the user’s premises, the user gets the original data. To prevent this situation the amount of information extracted can be controlled. However, this limits the size and kind of results that can be extracted. For example, the process could allow for downloading a small file in a well-known vector format (e.g. a common result for an image classification process). The use case described above is common for companies trying to sustain a business model for Very High Resolution (VHR) data exploitation and, at the same time, trying to prevent costumers downloading the original raw data. This is in order to ensure that they are repeat customers.

One of the characteristics of ARD is the existence of a continuous flow of information about the same observed property in the same area. In these circumstances most of the information becomes redundant. Nevertheless, two interesting patterns could emerge: Anomalies which are significant events that are detected as uncommon values for a particular time, or gradual changes that progressively deviate from an initial measurement due to cumulative effects.

In this section the focus is on the detection of anomalies or significant events that can be extracted by a continuous analysis of new ARD detected by an ARD Access services. Such events would result in the activation of an alert that will result in the deployment of a team to fight the effects of the event in the ground.

A use case that follows the "event driven pattern" is the detection and evolution of forest fires. The US Forest Service could have a subscription to an ARD service providing imagery to detect the presence of fire and track its evolution in near real time. If the fire is big and appends in a remote area, the information extracted from remote sensing could be more comprehensive that the one obtained from a fire brigade deployed on the ground. In some cases, the addition of remote sensing data could be critical for faster, better informed and well-coordinated action.

The diagram describes a generic "emergency management" use case that can be applied also to forest fires. The use case follows these steps:

This general diagram can be applied to two more concrete scenarios that results in variations of the diagram.

Coming back to the use case example, a forest fire has been detected and a US Forest Service official subscribes to an ARD service providing imagery over the area where the fire was detected to evaluate the damage and the perimeters of the fire. Each time new raw data arrives, new ARD will be produced and a notification will be sent to a fire perimeter WPS that will estimate the perimeter of the fire.

If the image is cloud free and it is possible to extract a good perimeter, the new perimeter will be stored as IRD and the US official will get a notification. After analyzing the perimeter, the official can decide the proper course of action. If the fire progresses, the new perimeter is sent to the fire brigade. If the fire can be considered under control, a damage report is produced, and the subscription is cancelled.

The second scenario is related to the detection of illegal logging in the Amazon forest. In this scenario an IBAMA official subscribes to a land cover WPS service. Each time new ARD in the area arrives, a new land cover map is automatically generated. If variations in the forest coverage are detected, a deforestation map is produced and notified sent to the IBAMA official. The official then retrieves the information and analyzes the data. If a deforestation patch is detected and associated with illegal activities, another service for road extraction is triggered using the same ARD or other related very high-resolution data. The extracted roads are conflated with the current road information and the new map sent to the military police with an indication of the position and extend of the illegal logging with the hope that they can avoid future illegal deforestation and arrest the people responsible.

Other similar scenarios based on in-situ ARD (that replaces the satellite-based imagery used in the previous ones) could also be analyzed. One example was extracted from the OGC Critical infrastructure protection experiment (CIPI): "Pollution created by the explosion of a chemical lorry on a river span that contaminates both the water and the air". In this case, weather, air quality and river flow and velocity are the kind of ARD needed for immediate ingestion in a propagation model (WPS) that results in a prediction ready for interpretation and ulterior action.

In the first subsection of this chapter, how cloud providers are providing access to data resources through an API was explained. Data access through APIs hides the physical storage structure and format allowing provision of resources that are in any place in the cloud or even accessed from a remote cloud. This approach provides a truly federated data access system. In contrast, the Docker approach also described in the first subsection is limited to a deployment in a single node and only provides a truly federated approach if deployed in several nodes and the code deployed has some coordination and parallelization mechanism in it. A truly federated processing capability can only be achieved by a high-level processing language that offers a set of high-level processing functions. A piece of software that knows about the existence of distributed data and processing resources in the federation will be able to interpret the high-level language. The software can then decompose that language into several sets of individual instruction sequences that use the resources in several configurations and select the optimal set of instructions to be executed. Criteria for selecting the "optimal" one could be to get the result faster, to optimize computational costs, to use the most power efficient and environmentally friendly workflow, or the one that minimizes data movement for security considerations.

Once the ideal set of instructions is known, the routine becomes available and published for subscription. The system will be able to invoke it every time new data is being made available as ARD.

Most ML algorithms need training data to work. The process of exposing a ML algorithm to training data is called train or retrain ML and this creates a trained model. The model can be later used to annotate EO data automatically. Training datasets are pairs of examples of labelled data (independent variable) and the corresponding EO data (dependent variables). Together, these two variables are used to train an ML model that will be later used to make predictions on the target variable using previously "unseen" EO data. Test data is another set of paired data that is not used to train but to evaluate the performance of the model. In testing, the ML model is exposed to the EO data and the response of the model is compared with the already known expected result (the labels). Then an overall performance metric is computed. In addition to the training and test data, a third set of observations, called a validation or hold-out set, is sometimes required. The validation set is used to tune variables called hyper parameters, which control how the model learns.

The set of training data, test data, and validation data are similar in structure and are considered to be all labelled or annotated data. In the geospatial world, where things are georeferenced in space, training data is named as training areas. Creating annotated data is a manual process that is time consuming and, paradoxically, precisely what we are trying to avoid by applying ML algorithms. Fortunately, training data is created from a small subset of the original data (as representative as possible of the whole set) and the user can select areas that are well-know or relatively easier to identify. Even for a small subset, the creation of training data prior to training the ML is costly. To avoid the work load of creating the training data , a citizen science project such as picture pile can be created. Alternatively reuse of existing annotated datasets may be possible. The Testbed 14 ML ER cites some annotated data sources that can be used to train ML models.

As a consequence, defining a new concept on top of ARD is possible: ML-ARD. ML-ARD is ARD that is paired to labels (feature data) for training purposes. Note that now dataset is composed of the annotation (a feature) and an image (a coverage) and both should be correlated or geolocated. The property type of the annotations in the training areas also determine the results of the classification process. For example, if the annotations contain "land cover types", the result of the ML model is a classification of land cover classes (a land cover map). This means that there are as many ML ARD as classification results. This also means that it should be better to separate ARD from "Training Ready Data" (TRD) that could be defined as training data targeting an ARD PFS and a result type. Since there is one TRD for each result type, the collection of these TRD, can be included in a TRD catalogue.

An example of a TRD small catalogue can be found in the Radiant MLHub with some training data ready for use in any project.

Once the ML model is trained, the model is ready to be used. If the model was trained with TRD, the model will optimally run on the ARD products that are compatible with the same PFS as the TRD conforms to. Since training a ML model is a time-consuming process, the idea of a ML model catalogue [21] emerges. A ML model catalogue is a catalogue of ML trained models (eventually trained with TRD). The catalogue contains trained processes that are "compatible with" one type of ARD and have one result target.

Now, the question is how to know which process in the catalogue is compatible with one type of ARD and what is the expected result of the model. All processes are depending on the type of data applied in their inputs. Commonly, models are designed to work well at a particular resolution and with a particular type of values. ML models are even more dependent on data inputs but they have one advantage: They were trained with a type of ARD. This gives us an immediate reference to the type of ARD compatible with the ML model.

Assuming that each type of ARD (i.e. each Product Family Specification) has a URI that represents the ARD type, each model input should have the URI associated with it.

The ARD acronym has a clear meaning: Data that can be immediately used. In this study we have detected that there are three main ways of considering that the data is ready, depending on the kind of user or the expected usage. This has resulted in three main interpretations of the ARD concept:

Every actor in the RS market seems to favor the interpretation of the ARD that benefits her. Even if polysemic is a common feature in languages, this will result in confusion to the market. To avoid confusion, we recommend to use the ARD acronym accompanied by the "adjective" that helps pointing to the right meaning. For example: CARD4L ARD. This ER is not providing any new definitions to avoid creating more confusion.

The CEOS Product Family Specifications are not formal Standards. The ARD Strategy item 4.4 foresees "discussions with standards organizations (e.g. OGC) to explore whether CEOS ARD Specifications might be used as the basis for broader, official community standards, and to ensure that COES work is recognized by others including the data research community". Standards are seen as key factor in CEOS engagement with the private sector.

Standardized ARD could help in avoiding the divergence that can be caused by various groups working towards different interpretations of the concept. Standardization increases the buy-in from the broader stakeholder community, reduces confusion, establishes consistency in terminology, concepts and procedures and formalizes compliance criteria. Standards require volunteer effort to develop and must follow procedures to ensure openness and fairness.