In the field of Earth observation, the importance of in situ data was recognized by the Group on Earth Observations (GEO) in the Canberra Declaration in 2019. The GEO community focuses on three global priority engagement areas: the United Nations 2030 Agenda for Sustainable Development, the Paris Agreement, and the Sendai Framework for Disaster Risk Reduction. While efforts have been made by GEO to open and disseminate in situ data, GEO did not have a general way to capture in situ data user requirements and drive the data provider efforts to meet the goals of its three global priorities. We present a requirements data model that first formalizes the collection of user requirements motivated by user-driven needs. Then, the user requirements can be grouped by essential variable and an analysis can derive product requirements and parameters for new or existing products. The work was inspired by thematic initiatives, such as OSCAR, from WMO, OSAAP (formerly COURL and NOSA) from NOAA, and the Copernicus In Situ Component Information System. The presented solution focuses on requirements for all applications of Earth observation in situ data. We present initial developments and testing of the data model and discuss the steps that GEO should take to implement a requirements database that is connected to actual data in the GEOSS platform and propose some recommendations on how to articulate it.

A Data Space is a distributed system defined by a governance framework that enables secure and trustworthy data transactions between participants. The architecture of a data space is defined by the data space protocol and composed by several building blocks. Metadata catalogues are a fundamental building block that provides discoverability and the Data Space Connectors provide accessibility. This paper proposes an approach for the combination of geospatial standards for data discovery and the data space protocol and describes a practical implementation in the context of the AD4GD project. The presented architecture provides access to internal users via a SaaS cloud based on MinIO for data storage, GeoNetwork for data discovery, and Docker for data processing. This infrastructure constitutes an experimental data space node provided by the All Data for the Green Deal (AD4GD) project. The AD4GD project is conducting research and development for a future Green Deal Data Space.

The Green Deal Data Space is born in the big data paradigm where sensors produce constant streams of Earth observation data (remote sensing or in-situ). The traditional and manual organization of data in layers is no longer efficient as data is constantly evolving and mixed together in new ways. There is a need for a new organization of the data that favors users and in particular can be considered ready for use. The AD4GD project proposes a threefold solution: A new information model, dynamic multidimensional datacubes and OGC APIs for data query and filtering. The use of data in the context of the Green Deal is difficult due to the wide heterogeneity of data sources (many times expressed in different data models) and different semantics used to represent data, and the lack of sufficient interoperability mechanisms that enable the connection of existing data models. The solution is a framework composed by a suite of ontologies implemented in line with best practices, reusing existing standards and well-scoped models as much as possible and establishing alignments between them to enable their interoperability and the integration of existing data. This approach was successfully applied to object based data stored in a RDF triple store e.g. vector data and sensor data) in the agricultural sector. The traditional representation of static two-dimensional layers needs to be replaced by a dynamic view where time becomes an extra dimension. In addition, other dimensions emerge such as the height in atmospheric and oceanic models, the frequency in hyperspectral remote sensing data or the species in a biodiversity distribution model. These dimensions define a data cube that offers an entry to a constantly evolving world. The dimensions in the datacube as well as the values stored in the cube cells (a.k.a. attributes) should be connected to the concepts in the Information Model. In the big data paradigm access to individual layers is difficult due to the dynamic nature of the data. Instead we need a set of modern APIs as an entry point to the data in the data space. The OGC APIs offer a set of building blocks that can be combined together with other web API design principles to build the Green Deal Data Space data access APIs. Users will be able to get the necessary data for modeling and simulating the reality using the OGC APIs endpoints described in the OpenAPI description document. The OGC APIs include the concept of collections as an initial filtering mechanism but a filtering extension using CQL2 is in advanced draft status. It is fundamental that the OGC APIs are also capable of generating detailed metadata about the extracted subset including data sources, producer information and data quality estimations.AD4GD is a Horizon Europe project co-funded by the European Union, Switzerland and the United Kingdom.

When referring to Earth Observation data, we consider two sides of the same coin: space-based data and in-situ data collected on or near to the ground. While satellite-derived data benefits from a consolidated data management and sharing practices, in-situ data is more complex, highly heterogeneous by nature, involving a wide range of actors and data sources, which creates significant challenges in making this data standardised, integrated and interoperable, and ultimately, accessible and usable.Willing to address these challenges, the InCASE project —supported by the European Environment Agency and funded by the European Commission as a contribution to the Group on Earth Observations (GEO)— developed the Geospatial in-situ requirements (G-reqs) tool. Designed primarily to support GEO Work Programme activities but open to contributions beyond GEO, G-reqs acts as a database and a standard methodology to collect and manage user requirements for in-situ datasets.The development of G-reqs was done with the hope that the content generated will help in identify shared requirements across domains, detect barriers and gaps, and act as a bridge between user demands and data providers by facilitating the matchmaking between the required and the produced data, or even to prioritize new in-situ data collection strategies. During the last year, the focus was on engaging with the user community to collect as many requirements as possible trying to avoid bias in particular theme, backgrounds, or geographic regions.In this communication we analyse the content of the G-reqs and discuss to what extent it can fulfil the hopes described before via a series of showcases and statistical overalls. The presented approach demonstrates user-driven solutions and the significance of initiatives like GEO in advancing Open Science and extract new knowledge enabling cross-domain interaction for environmental research and decision-making.

The Green Deal Data Space is born in the big data paradigm where there is a variety of data formats and data models that are exposed as files or web APIs. As a result, we need to default in simple data structure that is transversal enough to be able to represent most of the more specific data models, formats and API payloads. Many data models present a structure that can be represented as tables.TAPIS stands for "Tables from APIS". It is a JavaScript code that uses a common data model that is an array of objects with a list of properties that can contain a simple or a complex value. In TAPIS offers a series of operations that use one or more arrays of objects as inputs and produce a new array of objects as an output. There are operations that create the arrays of objects from files or API queries (a.k.a. data import), others that manipulate the objects (e.g. merge two arrays in a single one) and some operations that generate visual representations of the common data structure including tabular, a map, a graph, etc.TAPIS is limited by its own data model. While many of the data models can be mapped to the common data model, a multidimensional data cube or a data tree cannot be represented in a single table in an efficient way. In the context of the Green Deal Data Space, most of the sensor data, statistical data, geospatial feature based data and administrative data can be considered object based data and can be used in TAPIS. TAPIS is able to connect to Sensor Things API (the sensor protocol selected in AD4GD and CitiObs), S3 buckets (the internal cloud repository used in AD4GD), GeoNetwork (the geospatial metadata catalogue selected in AD4GD and more4nature), and the OGC API features and derivates (the modern web API interfaces standardized by the OGC) but other data inputs will be incorporated, such as Citizen Science data sources and other popular APIs used in the more4nature project. More analytical functionalities are going to be incorporated in the CitiObs project. As part of the AD4GD Green Deal Information Model, there is an operation to associate semantics to each column of a table by linking it to a URI that defines the concept in an external vocabulary (as well as units of measure if appropriate). In order to be compatible with the data space architecture recommended by the International Data Space Association, we are working on supporting the catalogue of the Eclipse Data Connector, and to be able to negotiate a digital contract as a previous step to request access to the relevant data offered in the data space. To do so, we are working on incorporating the data space protocol as part of the TAPIS operations for data import. TAPIS is available as open source at https://github.com/joanma747/TAPIS.AD4GD, CitiObs and more4nature are Horizon Europe projects co-funded by the European Union, Switzerland and the United Kingdom.

The in-situ Earth Observation data segment is fragmented and there are significant data gaps to complete an observing system offering global datasets including series with relevant temporal depth. To identify the most urgent user needs, the InCASE project has designed a geospatial in-situ requirements database model, called G‑Reqs, aimed to collect and manage requirements emerging from the Group on Earth Observations (GEO) and the Copernicus community. The expected benefits include enabling a better reuse of in-situ data, enabling geographical upscale, identifying priorities in the needs and identifying communities with a common interest to look for synergies. Starting from the Essential Variables framework, the model offers a user-centric approach based on the expression of data needs and its translation into parametrized requirements for in-situ data. A first implementation was done in a web form and was tested by the EuroGEO community represented by volunteering pilots of the EU H2020 e-shape project, and it is open to research projects, decision-makers looking for policy indicators, remote sensing agencies in need of cal/val data, services produced by commercial companies, Earth system predictive algorithms and Machine Learning modellers, etc., interested in environmental in-situ data. The usefulness of the G-reqs model will lie in its capability to collect, share and analyse requirements, detect essential datasets, gaps, and help to make recommendations to data providers via a consensus process thus promoting the discovery of fit-for-purpose in-situ datasets. The consensus process can result in agreement on recommendations to data providers for producing products that cover emerging needs of the Earth Observation users’ community in terms of spatial, temporal coverage or quality target. In this context, the entire Earth Observation community of users is invited to use the G-reqs as a mechanism to document its in-situ data needs (https://g-reqs.grumets.cat). For example the in-situ networks of observation facilities (ENVRI, e.g. ELTER, GEOBON, among others) can then participate in the analysis, gap detection and recommendations for the creation of new products or modifications of the existing ones to better serve their users. With the G‑reqs as a tool, the In-Situ Data Working Group in GEO can act as a forum where the in-situ data barriers and gaps are discussed and addressed. This communication will present the requirements data model and the current status of the requirements collection as well as next steps to complete the G‑reqs capabilities. This work is inspired by the OSAAP (formerly NOSA) from NOAA, the World Meteorological Organization (WMO) OSCAR requirements database and the Copernicus In-Situ Component Information System (CIS2). The InCASE project is funded by the European Environment Agency (EEA) in the context of the EEA SLA on “Mainstreaming GEOSS Data Sharing and Management Principles in support of Europe’s Environment" in line with the European Strategy for Data, the Green Deal Data Space, and Destination Earth.