**Executive Summary**

In the current version (1.2) the technical definition of datasets stemming
from the needs of the three PUCs, namely, the _PUC requested datasets_ [AD1]
has been addressed; among others, technical definition is aimed at associating
univocally the requested datasets to products available either from some
Copernicus thematic service or from some other sources, and to specify those
that will be generated in the platform; moreover, in some cases, datasets have
turned out to correspond to more than one product, so they have been split;
eventually the resulting selection of the derived EOPEN products appears to be
suitable for further usage, beyond the project PUCs.

Also, in the current version, the product FAIR characteristics are addressed,
including usage constraints as well as LTDP needs; this topic has been
included following some comments received at the first review, in view of
product usage beyond the project Consortium and its duration.

#  1 DATA SUMMARY

##  1.1 Introduction

EOPEN provides a framework in which user applications are managed and are
provided with the means to access datasets and perform processing. All of
which allow interoperability supported by the EOPEN core capabilities.

In addition, EOPEN provides Service Extensions. They are developed by the
EOPEN team and made available to all users of the EOPEN Framework typically
fulfilling data preparation tasks or scientific algorithms and processing
methodologies.

Generally speaking, the EOPEN Framework does not retain data. EOPEN is
“application agnostic”, implying that it is transparent with regards to data
characteristics, including access restrictions and data storage.

However, Service Extensions can take data, apply enhancements (processing and
data fusion) to create data used by the user applications.

The following picture depicts the high level EOPEN operational concept and
dataflow.

##  1.2 User Applications

All data collected and made available in the platform relates to user
applications. In the EOPEN project the user applications are represented by
three use cases.

In the case of PUC1-Flood Risk Assessment and Prevention, the partner involved
is a public body (AAWA), currently not using satellite data systematically,
which is interested to receive mapped information derived from EO satellite
data which can be used to improve its models, data as well as additional
meteorological forecast data; normally such datasets are open and can be made
available to identified stakeholders [AD1] or to others not yet reached.

In the case of PUC2-Food Security, several institutes, research or public
agencies, are involved - this Use Case, located outside Europe, is connected
to some national institutions of Korea; some datasets, provided by the
stakeholders, appear of restricted usage, nevertheless some datasets generated
in the platform (e.g. rice mapping) will be accessible. In addition to the
datasets identified during the requirement analysis, PUC2 can also benefit
from some meteorological data and data analyses available through the Korean
Meteorological Service.

Finally, in the case of PUC3-Monitoring Climate Change, the partner
responsible for its implementation is a national service - the identified
datasets can serve a community of users which can be extended; also, a usage
transversal to various user communities can be envisaged. Identified datasets
are mainly of non-EO type; in addition to them some "EO based" datasets are
being considered, following the 1  st  project review meeting. PUC3 datasets
are normally open.

The datasets for the use cases handled in the platform belong to the following
typologies:

1a. EO data products available from Copernicus Data Ware House (DWH),
including proprietary datasets; (ref. 6.3)

1b. EO data from the EOPEN Umbrella Hub (former Collaborative Ground Segment,
CollGS) [RD1];

  2. Datasets stemming from Copernicus Thematic Services; (ref. 6.2.3) 

  

  3. Datasets stemming from Copernicus EMS services; (ref. D1.1) 

  

  4. Datasets stemming from other EC Project (Open Data); (ref. 6.2) 

  

  5. Non-EO datasets, including meteorological data; (ref. 6.2) 

  

  6. Datasets generated in the EOPEN platform; (ref. 5) 

  

  7. Datasets available from stakeholders, including proprietary datasets, or generated by them using resources available from the EOPEN platform. (ref. 6.2) 

  

  

The needed datasets are mainly EO satellite data/products from Copernicus DWH;
some environmental variables, derived from EO data - Essential Climate
Variables (ECV) (e.g. LAI) - available from Copernicus Land Services and some
non-EO data, such as climatic data and social media data, in addition to
weather forecast (derived from models including satellite data).

EO data products from Copernicus Warehouse are mainly open data; some EO data
from the Copernicus Contributing Missions are available in limited amounts
(Quotas) during the Project lifetime (ref. 6.3).

The type of Requested Datasets, typical of the application area at the basis
of the Use Cases, depend also on the stakeholders involved in the project.
[AD3]

The FAIR paradigm is addressed in section 4, focused on the EOPEN product
description.

Whereas the current deliverable deals with a general product description and
management, other deliverables describe in detail how input data are accessed
and handled - in particular, [RD1] is focused on a unique Sentinel Data Hub
access point, which is called Umbrella Hub; in addition to it, access to DVH
data access through DIAS is addressed in [RD3] (M26); [RD4] (M26) is focused
on meteorological and climatological data acquisition; and [RD5] (M32) is
focused on social media crawlers to handle social media data.

Standardization, Interoperability and long-term data preservation aspects are
the focus of other WPs (WP6, WP8,) so they will be treated in detail in other
deliverables (D6.1, D8.6).

Some information about allocated resources and data security is provided in
the sections 2 and

3\.

#  2 ALLOCATION OF RESOURCES

Data in the EOPEN project is acquired for, used by and produced by the user
applications of the Use Cases. In many cases the data is from open and freely
available sources such as Copernicus. Data produced by the use case
applications in the EOPEN project is mainly in the public domain, however some
data, for example social media-tweets, are constrained by specific ownership
and privacy regulations.

How to proceed in making the EOPEN datasets that are not by nature of their
source already FAIR compliant is currently under evaluation.

As to costs, this will depend on the adopted solution; such topic will be
addressed in the future months; also, an aspect to be clarified is which data
can be classified as research thus chargeable to the project. Which data are
subject to FAIR is described in section 4.

Serco, as responsible of DMS, will oversee this activity with the support of
SPACEAPPS.

Some LTDP resources have been planned. Firstly, “EOPEN has the responsibility
for providing the means to produce data that will survive (i.e. standards and
formats applied)”. The concepts, design and implementation of the framework
core ensure that users create well defined processes and data exchanges.
Secondly, the EOPEN LTDP framework, deliverable of WP8.5, will ensure the
accessibility and ability to re-use EOPEN datasets, in line with the EOPEN
data management plan. “The LTDP framework will be based on the preservation by
design approach researched in the PERICLES”. (GA, Annex 1, p. 124)

LTDP is also a prerequisite for long term sustainability of EOPEN.

#  3 DATA SECURITY

Overseeing security is part of SERCO’s leading tasks.

User management, privacy and security requirements are defined to establish
procedures, software and infrastructure to ensure that the platform and its
users is protected from unauthorised access, accidental revealing of
privileged information and breaches by those with ill-intent are defined in
D6.1.

EOPEN has in place user authentication and applies protocols for communicating
with other platforms. PA/QA procedures to audit platforms used for processing
e.g. DIAS/TEPs etc. are in place; moreover, security in the tables used to
compare DIAS platforms is also in place (tbc).

The EOPEN project uses only European cloud providers that have clear defined
security policies and implement precaustions such as security solutions such
as the anti-DDos service.

DIAS-ONDA is such a provider offering an anti-DDos service with operations
designed to be security compliant with ISO/IEC 27000 and Data Protection
Directive 95/46/EC.”

[Anti-DDos (Distributed Denial of Service) protects against some informatics
attacks

(https://en.wikipedia.org/wiki/Denial-of-
service_attack#Distributed_DoS_attack)]

Hereafter some information on data security is reported, by referring to the
related deliverable. **Umbrella Hub**

[RD1] describes such Umbrella, acting as a broker of existing hubs - it does
not add any extra information value, but merely distributes existing data of
the Sentinel Access points; below some features related to security are
described.

__Database Access_ _

Establishing a database connection requires the following credentials:
database name, username, password, host IP and port. These credentials are
used by the application to interact with the database and securing them is
quite important. Therefore, the database stored credentials are retrieved in
the following ways:

  * A JSON file stored in the working directory. 

  

  * Environmental variables. 

  

__REST API Access_ _

The application allows users to retrieve resource representation/information,
only while the modification of it is restricted in every way. As GET requests
do not modify the state of the resource, these are considered to be safe
methods.

__Metadata harvesting and sharing_ _

Metadata are harvested from the hubs by sending requests to the respective
APIs. Requests are based on the hubs’ individual security policy. This policy
includes authorization via credentials for accessing the API of each hub. The
hubs’ generated credentials are stored in the database and retrieved every
time the request is constructed. In this way, Umbrella hub collects and saves
the metadata from different endpoints. As a result, the obtained metadata are
made available for downloading by any user. The download process requires
Umbrella hub users to be registered, in turn, to the different hubs connected,
as this process requires also authorization. Finally, download integrity can
be verified using the MD5 checksum provided by the Umbrella hub.

[RD2] is about setting up and providing access through the EOPEN platform to
the Big Data and HPC infrastructure located at HLRS. Data locality is of
utmost importance in order to achieve maximum performance, and thus both the
submission of new processing jobs and input data are required to be
transferred in a secure and fast manner to these systems before processing can
start. [RD2] detailed the setup of Cloudify, an orchestration tool to submit
workflows via a RESTful service, between the EOPEN platform and HLRS. Allowing
workflow submissions to the HPC system with Cloudify is achieved with
milestone MS1, where security is guaranteed by using secure communication via
SSL, meaning that all communication between client and server is encrypted.
Further, confidential information is hidden in data that is sent through
Cloudify by using Cloudify’s own secret store. Next actions include enabling a
secure and fast data transfer from and to HLRS infrastructure via Rucio. Rucio
is a scientific data management framework that is developed by CERN with the
intention to transfer very large data. EOPEN is following here best practices
for authentication and authorization, and the actual transfer will benefit
from parallel data streams such as provided by the GridFTP protocol to ensure
a fast and secure data transfer between sites.

#  4 FROM PUC DATASETS TO EOPEN PRODUCTS

The PUC requested datasets [AD1] have been further considered in view to
associate them to products available from some Copernicus service or from some
other sources, or to identify suitable products to be generated in the
platform by applying EO data analyses. In some cases, a dataset has been split
in two as it turned out to include different data typologies (ref. section 1).
A selection of EOPEN products has been derived, generalized for further usage,
beyond the project PUCs.

PUC Requested Datasets and resulting products are summarized in the tables
presented in the sections 4.1.3, 4.2.3 and 4.3.3 - a colour code has been
associated to each data type as shown in the Legend below. Products are
described in detail in sections 5 and 6.

Initially, the PUC requested datasets have been analysed in terms of dataset
scope, EO and NonEO data needs, data sources, archiving location, time scope,
and volumes. A summary of the EO data-products needed from the Copernicus DWH
is reported in section 6.3.

Normally such information is aligned to the most recent available information,
being chapters 56 the “living part” of the document.

Below is a list of the information collected by means of a google spreadsheet
- the second and third rows refer to the EO data-products, made available
through the Copernicus DWH, including data-products available under Quota
amounts restrictions (ref. section 6.3) during the project life time.  
  
<table>  
<tr>  
<th>

1\.

</th>  
<th>

EO Missions

</th> </tr>  
<tr>  
<td>

2\.

</td>  
<td>

DAP Datasets

</td> </tr>  
<tr>  
<td>

3\.

</td>  
<td>

Product

</td> </tr>  
<tr>  
<td>

4\.

</td>  
<td>

Format

</td> </tr>  
<tr>  
<td>

5\.

</td>  
<td>

Source

</td> </tr>  
<tr>  
<td>

6\.

</td>  
<td>

Access Restrictions

</td> </tr>  
<tr>  
<td>

7\.

</td>  
<td>

Storage

</td> </tr>  
<tr>  
<td>

8\.

</td>  
<td>

Area

</td> </tr>  
<tr>  
<td>

9\.

</td>  
<td>

Time Interval

</td> </tr>  
<tr>  
<td>

10

</td>  
<td>

. Data Volume

</td> </tr>  
<tr>  
<td>

11

</td>  
<td>

. Scope

</td> </tr>  
<tr>  
<td>

12

</td>  
<td>

. Notes

</td> </tr> </table>

Table 1: Requested Datasets information

PUC requested datasets and the derived products are reported in the sections
4.1-3, FAIR characteristics and LTDP needs are summarized in section 4.4.

##  4.1 PUC1 - Flood risk assessment and prevention datasets

###  4.1.1 PUC1 Requested Datasets  
  
<table>  
<tr>  
<th>

**Use case D-id**

</th>  
<th>

**Dataset Description**

</th> </tr>  
<tr>  
<td>

PUC1_DA1

</td>  
<td>

DEM/DSM 1m (e.g. Airbus Pleiades) from DWH

</td> </tr>  
<tr>  
<td>

PUC1_DA2

</td>  
<td>

Snow maps with a resolution < 20m

</td> </tr>  
<tr>  
<td>

PUC1_DA3

</td>  
<td>

Soil moisture maps with resolution < 10m

</td> </tr>  
<tr>  
<td>

PUC1_DA4

</td>  
<td>

Flood maps (*)

</td> </tr>  
<tr>  
<td>

PUC1_DA5

</td>  
<td>

Damage maps (**)

</td> </tr>  
<tr>  
<td>

PUC1_DA6

</td>  
<td>

Water presence maps

</td> </tr>  
<tr>  
<td>

PUC1_DA7

</td>  
<td>

Bathymetry of coast, lakes, rivers

</td> </tr>  
<tr>  
<td>

PUC1_DA8

</td>  
<td>

Ortho-photo with resolution of 50 cm (e.g. WorldView4)

</td> </tr>  
<tr>  
<td>

PUC1_DA9

</td>  
<td>

Vegetation presence

</td> </tr>  
<tr>  
<td>

PUC1_DA10

</td>  
<td>

Land cover

</td> </tr>  
<tr>  
<td>

PUC1_DA11

</td>  
<td>

LAI and other vegetation indexes

</td> </tr>  
<tr>  
<td>

PUC1_DA12

</td>  
<td>

Other maps (thermal or multispectral data ready to be processed) with high
resolution

</td> </tr>  
<tr>  
<td>

PUC1_DA13

</td>  
<td>

Weather forecast

</td> </tr>  
<tr>  
<td>

PUC1_DA14

</td>  
<td>

Social media

</td> </tr> </table>

Table 2: PUC1 Requested Datasets [AD1]

(*) Generated by the stakeholder at his premises or exploiting EOPEN
resources.

(**) From Copernicus EMS or generated by the stakeholder at his premises.

###  4.1.2 PUC1 Data Summary Information

Table 3: PUC1 Data Summary

###  4.1.3 PUC1 Products (*)  
  
<table>  
<tr>  
<th>

**Dataset ID.**

</th>  
<th>

**Product Name/acronym**

</th>  
<th>

**Web Location (**)**

</th> </tr>  
<tr>  
<td>

PUC1_DA2.1

</td>  
<td>

Snow Water Equivalent/ SWE_CGLS

(**)

</td>  
<td>

**_https://land.copernicus.vgt.vito.b_ ** **_e/PDF/portal/Application.html#Br_
** **_owse;Root=512260;Collection=10_ **

**_00061;Time=NORMAL,NORMAL,-_ **

**_1,,,-1_ **

</td> </tr>  
<tr>  
<td>

PUC1_DA2.2

</td>  
<td>

Snow Cover Extent/SCE_CGLS (**)

</td>  
<td>

**_https://land.copernicus.vgt.vito.b_ ** **_e/PDF/portal/Application.html#Br_
** **_owse;Root=1000101;Collection=2_ **

**_9870071;Time=NORMAL,NORMAL_ **

**_,-1,,,-1_ ** ,  ,

</td> </tr>  
<tr>  
<td>

PUC1_DA3

</td>  
<td>

Surface Soil Moisture/SME_CGLS

(**)

</td>  
<td>

**_https://land.copernicus.vgt.vito.b_ ** **_e/PDF/portal/Application.html#Br_
** **_owse;Root=71027541;Collection=_ **

**_1000282;Time=NORMAL,NORMAL_ **

**_,-1,,,-1_ ** ,  ,

**_https://land.copernicus.eu/global_ **

**_/sites/cgls.vito.be/files/products/_ **

**_CGLOPS1_PUM_SSM1km-_ **

**_V1_I1.30.pdf_ **

</td> </tr>  
<tr>  
<td>

PUC1_DA4

</td>  
<td>

EOPEN AAWA AMICO Early

Warning System Flood Forecast

/AA_EWS_FF

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC1_DA5

</td>  
<td>

EC EMS Damage Map (or others)/

EC_EMS_DM (tbc)

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC1_DA6_a

</td>  
<td>

Water Presence Map/WPM

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC1_DA6_b

</td>  
<td>

Water Presence Change

Monitoring/ WPCM

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC1_DA11.1

</td>  
<td>

Leaf Area Index/LAI_CGLS

(**)

</td>  
<td>

https://land.copernicus.vgt.vito.be /PDF/datapool/Vegetation/Propert
ies/LAI_300m_V1/2019/05/20/

</td> </tr>  
<tr>  
<td>

PUC1_DA11.2

</td>  
<td>

Fraction of vegetation Cover

/FCOVER_CGLS (**)

</td>  
<td>

https://land.copernicus.vgt.vito.be /PDF/portal/Application.html#Bro
wse;Root=512260;Collection=1000

061;Time=NORMAL,NORMAL,-1,,,-

1

</td> </tr>  
<tr>  
<td>

PUC1_DA11.3

</td>  
<td>

Normalized Difference Vegetation

Index /NDVI_CGLS (**)

</td>  
<td>

https://land.copernicus.vgt.vito.be /PDF/portal/Application.html#Bro
wse;Root=513186;Collection=1000

063;Time=NORMAL,NORMAL,-1,,,-

1

</td> </tr>  
<tr>  
<td>

PUC1_DA11.4

</td>  
<td>

Vegetation Condition Index

VCI_CGLS (**)

</td>  
<td>

https://land.copernicus.vgt.vito.be /PDF/portal/Application.html#Bro
wse;Root=513186;Collection=7287 79;Time=NORMAL,NORMAL,-1,,,-1

</td> </tr>  
<tr>  
<td>

PUC1_DA13.1

</td>  
<td>

FMI Weather Forecast

(HIRLAM_NWP)

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC1_DA14

</td>  
<td>

Tweet datasets/TD (tbc)

</td>  
<td>

</td> </tr> </table>

Table 4: PUC1 Products

(*) Copernicus DWH data-products are not included in this table

(**) CGLS => Copernicus Land Service

##  4.2 PUC2: Food Security

###  4.2.1 PUC2 Requested Datasets  
  
<table>  
<tr>  
<th>

**Use case D-**

**id**

</th>  
<th>

**Dataset Description**

</th> </tr>  
<tr>  
<td>

PUC2_DB1

</td>  
<td>

High resolution remote sensing imagery

</td> </tr>  
<tr>  
<td>

PUC2_DB2

</td>  
<td>

Meteorological observation (a) and forecasting data (b)(*)

</td> </tr>  
<tr>  
<td>

PUC2_DB3

</td>  
<td>

In field inspection data (**)

</td> </tr>  
<tr>  
<td>

PUC2_DB4

</td>  
<td>

Farmers’ claims data (**)

</td> </tr>  
<tr>  
<td>

PUC2_DB5

</td>  
<td>

Accurate yield statistics (***)

</td> </tr>  
<tr>  
<td>

PUC2_DB6

</td>  
<td>

EO based production status (****)

</td> </tr>  
<tr>  
<td>

PUC2_DB7

</td>  
<td>

Statistical data on national fertilizer usage (**)

</td> </tr>  
<tr>  
<td>

PUC2_DB8

</td>  
<td>

Social media

</td> </tr> </table>

Table 5: PUC2 Requested Datasets [AD1]

(*) It has turned out of no use in PUC2

(**) After a crosscheck with the stakeholders, it has turned out that such
data will not be available.

(***) See note Table 7.

(****) This dataset has been removed following the redefinition of PUC2_DB1
(see section 4.2.3)

**D1.4 V1.2**  
  
<table>  
<tr>  
<th>

**Dataset ID.**

</th>  
<th>

**Description**

</th>  
<th>

**Product Short Name/Acronym**

</th> </tr>  
<tr>  
<td>

PUC2_DB1_a

</td>  
<td>

Timeseries of vegetation indices and crop growth indicators

</td>  
<td>

Rice Status Indicator (RSI)

</td> </tr>  
<tr>  
<td>

PUC2_DB1_b

</td>  
<td>

Timeseries of rice maps at 10 m spatial resolution

</td>  
<td>

Paddy Rice Mapping (PRM)

</td> </tr>  
<tr>  
<td>

PUC2_DB2_a

</td>  
<td>

Meteorological observation

</td>  
<td>

KMA Open API

</td> </tr>  
<tr>  
<td>

PUC2_DB2_b

</td>  
<td>

Weather forecast

</td>  
<td>

KMA Open API (No longer considered)

</td> </tr> </table>

###  4.2.2 PUC2 Data Summary Information

Table 6: PUC2 Data Summary

###  4.2.3 PUC2 Products

Regarding PUC2 some requested datasets, originally indicated, have been
modified in accordance with [AD3] – below is the resulting product list.

**D1.4 V1.2**  
  
<table>  
<tr>  
<th>

PUC2_DB3

</th>  
<th>

In field inspection data

</th>  
<th>

NA

</th> </tr>  
<tr>  
<td>

PUC2_DB4

</td>  
<td>

Farmers’ claims data

</td>  
<td>

NA

</td> </tr>  
<tr>  
<td>

PUC2_DB5

</td>  
<td>

Accurate yield statistics (*)

</td>  
<td>

Rice Yield Estimation (RYE)

</td> </tr>  
<tr>  
<td>

PUC2_DB6

</td>  
<td>

removed

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC2_DB7

</td>  
<td>

Statistical data on national

fertilizer usage

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC2_DB8

</td>  
<td>

Social media

</td>  
<td>

Tweet datasets/TD (tbc)

</td> </tr> </table>

Table 7: PUC2 Products

(*) Ultimate product is considered “high risk high gain”. The product refers
to the national scale rice yield estimation for South Korea. Since, ground
truth data, such as fertilization usage, cultivating practices, high
resolution meteorological or soil data, are not freely available we will only
make use of Sentinel data. We will attempt to use advanced machine learning
and regression techniques for the estimation of yield based on multi-year time
series of Sentinel data, correlated with the freely available district-level
yield statistics. Nonetheless, the accuracy and overall usefulness of the
ultimate product is not guaranteed.

**Dx.x**

##  4.3 PUC3: Monitoring Climate Change

###  4.3.1 PUC3 Requested Datasets  
  
<table>  
<tr>  
<th>

**Use case D-**

**id**

</th>  
<th>

**Dataset Description**

</th> </tr>  
<tr>  
<td>

PUC3_DC1

</td>  
<td>

Snow cover observations

</td> </tr>  
<tr>  
<td>

PUC3_DC2

</td>  
<td>

Ground (soil) temperature data

</td> </tr>  
<tr>  
<td>

PUC3_DC3

</td>  
<td>

Air temperature at 2 m height

</td> </tr>  
<tr>  
<td>

PUC3_DC4

</td>  
<td>

Snow accumulation maps

</td> </tr>  
<tr>  
<td>

PUC3_DC5

</td>  
<td>

Climatological data for meteorological observations

</td> </tr>  
<tr>  
<td>

PUC3_DC6

</td>  
<td>

Social media

</td> </tr>  
<tr>  
<td>

PUC3_DC7

</td>  
<td>

Climate change scenario projections

</td> </tr>  
<tr>  
<td>

PUC3_DC8

</td>  
<td>

Weather observation time-series

</td> </tr>  
<tr>  
<td>

PUC3_DA9

</td>  
<td>

Numerical weather prediction model forecasts

</td> </tr>  
<tr>  
<td>

PUC3_DC10

</td>  
<td>

Region and municipality borders

</td> </tr>  
<tr>  
<td>

PUC3_DC11

</td>  
<td>

Herding area borders

</td> </tr>  
<tr>  
<td>

PUC3_DC12

</td>  
<td>

Road maintenance classification

</td> </tr> </table>

Table 8: PUC3 Requested Datasets

**1.4**

###  4.3.2 PUC3 Data Summary Information

Table 9: PUC3 Data Summary

###  4.3.3 PUC3 Products  
  
<table>  
<tr>  
<th>

Dataset ID.

</th>  
<th>

Product Name / acronym

</th>  
<th>

Web Location

</th> </tr>  
<tr>  
<td>

PUC3_DC1

</td>  
<td>

GlobSnow Snow Water Extent (GlobSnow_SWE)

</td>  
<td>

http://nsdc.fmi.fi/data/data_globsnow_swe

</td> </tr>  
<tr>  
<td>

PUC3_DC2.1

</td>  
<td>

SMOS Level 3 Soil Freeze and Thaw Service (SMOS_L3FT)

</td>  
<td>

http://nsdc.fmi.fi/data/data_smos  
</td> </tr>  
<tr>  
<td>

PUC3_DC2.2

</td>  
<td>

Sentinel-3 SLSTR Level-2 LST (Sentinel3_LST)

</td>  
<td>

https://sentinels.copernicus.eu/web/sentinel/userguides/sentinel-3-slstr/product-
types/level-2-lst  
</td> </tr>  
<tr>  
<td>

PUC3_DC3

</td>  
<td>

Air Temperature (FMIClimGrid_Tair)

</td>  
<td>

https://etsin.fairdata.fi/dataset/63b58d1a-dc23-

44eb-87e6-d3c31b9a57f9

</td> </tr>  
<tr>  
<td>

PUC3_DC4

</td>  
<td>

Snow depth

(FMIClimGrid_Snow)

</td>  
<td>

https://etsin.fairdata.fi/dataset/d72b6068-9ff24e82-90b3-057d145a274f  
</td> </tr> </table>

**1.4**  
  
<table>  
<tr>  
<th>

PUC3_DC5

</th>  
<th>

Climatological data for meteorological observations

(AWS_CLIM_FIN)

</th>  
<th>

https://en.ilmatieteenlaitos.fi/open-data-setsavailable  
</th> </tr>  
<tr>  
<td>

PUC3_DC6

</td>  
<td>

Tweet collections

</td>  
<td>

</td> </tr>  
<tr>  
<td>

PUC3_DC7

</td>  
<td>

Climate change scenario projections (CCS_FIN)

</td>  
<td>

https://en.ilmatieteenlaitos.fi/open-data-setsavailable  
</td> </tr>  
<tr>  
<td>

PUC3_DC8

</td>  
<td>

Historical and current weather observations from Finnish automatic weather
stations (AWS_OBS_FIN)

</td>  
<td>

https://en.ilmatieteenlaitos.fi/open-data-setsavailable  
</td> </tr>  
<tr>  
<td>

PUC3_DC9

</td>  
<td>

HIRLAM Weather Forecast (HIRLAM_NWP)

</td>  
<td>

https://en.ilmatieteenlaitos.fi/open-data-sets-

available

</td> </tr>  
<tr>  
<td>

PUC3_DC10

</td>  
<td>

Finnish regions and municipalities

</td>  
<td>

https://kartta.paikkatietoikkuna.fi/?lang=en  
</td> </tr>  
<tr>  
<td>

PUC3_DC11

</td>  
<td>

Reindeer herding districts

</td>  
<td>

N/A

</td> </tr>  
<tr>  
<td>

PUC3_DC12

</td>  
<td>

FTIA Road Maintenance

Classification

(FTIA_RoadMC)

</td>  
<td>

https://julkinen.vayla.fi/oskari/  
</td> </tr> </table>

Table 10: PUC3 Products

##  4.4 EOPEN Products - FAIR (Findable, Accessible, Interoperable, Re-usable)

##  characteristics and LTDP needs

In the following EOPEN Products FAIR characteristics are briefly summarized.
They have been derived, based on the EC DMP guidelines - as an example,
Twitter datasets analysis is reported in Appendix C.

EOPEN Products are normally open data, also, Copernicus DWH data used in the
platform is regulated through ESA Data User Licence (see Appendix A). The FMI
research Data Policy is illustrated in Appendix B. The data policy for
Copernicus Emergency Management Service and Land Service products accessed
through the platform are presented in the Appendix D2.

EOPEN Product specifications, including accessibility and archiving, are
reported in sections 5 and 6.

###  4.4.1 PUC1 products vs FAIR characteristics

PUC1 products are mainly open, derived from Copernicus DWH open data or
available through Land Services and from FMI.

Products generated in the platform for the stakeholder (AAWA) usage or
generated by AAWA by exploiting EOPEN resources are also open, as stemming
from a public authority; hereafter some information related to the AAWA
product, namely the AAWA AMICO Early Warning System Flood Forecast (ref.
6.2.5) codification and accessibility is provided.

Normally AAWA (AMICO) products follow AAAWA internal codification as well as
European codification (for basin, river): metadata can be generated upon
request - they include information on the environment and date of generation;
search keywords can be provided if needed.

AAWA products will be made available and open (openGL license) in the platform
without time limitations; moreover, they will be also available through AAWA
website in a dedicated repository; several formats are available, namely, PDF,
geo-tiff and ASCII, as needed in GIS software.

Open readable format (not compiled) and standard vocabulary make them re-
usable.

###  4.4.2 PUC2 products vs FAIR characteristics

PUC2 products are mainly open, either derived from Copernicus DWH data or from
the Korean Meteorological Service; some crop data collected locally can be
proprietary data.

In-field inspection data is open only for domestic researchers; Korean land
cover data can be accessed only by logging in to the Ministry of Environment
web site (one needs Korean phone number for user authentication); farmers’
claims data are not accessible; Korean rice yield data is open access, but
only city level in-situ data; statistical data on national fertilizer usage is
available only at national level.

PUC2 products, namely, Rice Status Indicators and Paddy Rice mapping (ref.
5.2) are FAIR compliant.

###  4.4.3 PUC3 products vs FAIR characteristics

PUC3 products are normally open data provided by FMI; they are available from
three different sources: FMI Open Data; GlobSnow from the Sodankylä National
Satellite Data Centre, and gridinterpolated temperature and snow depth maps.
The GlobSnow and the SMOS level 3 Freeze/thaw products are officially
unlicensed open data and their usage is unrestricted. The FTIA road
maintenance classification is open and unrestricted data, and can be obtained
from the FTIA Open Data API. The datasets are provided as NetCDF archives. At
the moment, these datasets are available from an ftp server, but, in the near
future they can also be obtained from the GeoServer. If needed, metadata for
these datasets can be obtained from the Sodankylä National Satellite Data
Centre portal and later from the GeoServer.

The grid-interpolated maps are part of the FMI ClimGrid dataset and can be
obtained from the Paituli data portal (https://etsin.fairdata.fi/). Metadata
for these can also be obtained from the portal. They adhere to the Creative
Commons Attribution 4.0 International (CC-BY 4.0) license similarly to the FMI
Open Data.

All these datasets can be re-used and modified in the EOPEN platform by third
parties. They are fully compliant with the FAIR paradigm.

###  4.4.4 Twitter products vs FAIR characteristics

Twitter data product FAIR characteristics are reported in Appendix C.

###  4.4.5 EOPEN LTDP data needs

As discussed in 1.2 all data collected and made available in the platform
relates to user applications. EOPEN LTDP needs have therefore been analysed
with reference to PUCs.

Based on the data the following guidelines have been established.  
  
<table>  
<tr>  
<th>

**Data description**

</th>  
<th>

**Category**

</th>  
<th>

**FAIR and LTDP considerations**

</th> </tr>  
<tr>  
<td>

Data from Copernicus sources (Data Warehouse, Thematic Services, Emergency
Management Services) that are free to access and managed by Copernicus.

</td>  
<td>

1

</td>  
<td>

At source. No action required in EOPEN other than to identify the data

</td> </tr>  
<tr>  
<td>

Data from other services or EC projects providing open data

</td>  
<td>

2

</td>  
<td>

At source. No action required in EOPEN other than to identify

</td> </tr>  
<tr>  
<td>

Public domain non-EO data sets

</td>  
<td>

3

</td>  
<td>

Evaluation of the access rights and utilisation required

</td> </tr>  
<tr>  
<td>

Non-Public domain non-EO data sets

</td>  
<td>

4

</td>  
<td>

Evaluation of the access rights and utilisation required

</td> </tr>  
<tr>  
<td>

Data generated in EOPEN and shared to all users

</td>  
<td>

5

</td>  
<td>

Responsibility of EOPEN

</td> </tr>  
<tr>  
<td>

Data generated in EOPEN by stakeholders (Use

Cases)

</td>  
<td>

6

</td>  
<td>

Responsibility of the stakeholder

</td> </tr>  
<tr>  
<td>

Proprietary datasets

</td>  
<td>

7

</td>  
<td>

Restricted and dependent on the stakeholder

</td> </tr> </table>

Normally EO data from Copernicus DWH are not archived (only metadata are
saved); also, LTDP is not considered in the case of non-EO data provided by
FMI and coming from Twitter; in particular, in the case of FMI, they have
already in place their own procedures whereas CERTH is taking care of twitter
archiving.

LTDP needs are limited to PUC1 (AAWA) which is exploiting the platform
resources for generating some products of theirs although archiving is also
foreseen at their premises.

About 250 GB have been estimated for LTDP of high resolution EO data, obtained
from Copernicus DWH, in limited amounts, under Quota restrictions (including
possibly Copernicus EMS data-products on flood event occurrence during the
second half of the project as rush datasets) as well as weather forecast data
(not archived at FMI) and AAWA products, generated on the platform as EOPEN
Products.

#  5 EOPEN PRODUCTS GENERATED IN THE PLATFORM

EOPEN products generated in the platform refer, in particular, to PUC1 and
PUC2 as PUC3 products are provided by FMI (ref. 6.2.1).

PUC products specifications are presented through a table such as that shown
below, suitable for describing Geospatial layers.  
  
<table>  
<tr>  
<th>

**Dataset ID.**

</th>  
<th>

</th> </tr>  
<tr>  
<td>

**Dataset Name**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Purpose**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Description (Content Specification)**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Output Layers**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Measurement Unit**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Temporal/spatial applicable domains** 1  
</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Temporal coverage**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Spatial Coverage / Area**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Spatial Resolution / Scale (Data Grid)**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Geographic projection /** **Reference system**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Input Data/Sources**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Input Data Archiving and rolling policies**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Frequency of update (refresh rate)**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Format**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Naming convention**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data sharing**

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Standards and metadata**

</td>  
<td>

</td> </tr> </table>