#  Introduction

The SHEER database gathers a large amount of interdisciplinary data collected
from seven independent episodes, research data and data for the project
results dissemination process. In order to properly manage such a large volume
and variety of data, a Data Management Plan (DMP) for the SHEER project has
been prepared.

A data management plan describes the data management life cycle for all
datasets to be collected, processed or generated by a research project. It
must cover: 1) the handling of research data during and after the project, 2)
what data will be collected, processed or generated, 3) what methodology and
standards will be applied 4) whether data will be shared /made open access and
how, 5) how data will be curated and preserved.

When significant changes arise during the project (e.g. new data sets, changes
in consortium policies, external factors), the Data Management Plan should be
updated.

In this deliverable document the following issues are presented: description
of data types gathered within SHEER project, schedule of data sharing,
standards for data format and content, polices for data stewardship and
preservation and procedures for providing access to data. The document
presents information from the current state of project realization, therefore
it can be expected to evolve together with the project state.

#  Type of data and information created

One of the main objectives of the SHEER project is to develop a probabilistic
methodology to assess and mitigate the short- and the long-term environmental
risks associated with the exploration and exploitation of shale gas. To this
end, the SHEER project will use monitoring data available in the literature
together with the monitoring data acquired during the project in the Wysin
shale gas exploration site in Poland.

From the perspective of the _Data Management Plan_ the following types of
SHEER data will be created during the project:

2.1 _Site data_ \- database consisting of seismicity, data on the state of
water and air and operational data collected from a shale gas site during the
project and respective type of data gathered from past case studies. The
database will include also data from conventional hydrocarbon exploration and
enhanced geothermal fields involving fluid injection that will be used as a
proxy;

2.2 _Research data_ \- developed methodology to assess environmental impacts
and risks across the different operational phases of shale gas exploitation;
proposal of best practices for the monitoring and assessment of environmental
impacts associated with shale gas exploration and exploitation; guidelines for
risk management of shale gas exploitation induced environmental impacts;

2.3 _Data for the SHEER results dissemination process_ – papers, leaflets,
posters, presentations, interviews, reports, photos, newsletters, etc.

Due to the multidisciplinary nature of the problem undertaken in the SHEER
project, the data collected will be heterogeneous. Furthermore, the data
gathered from past case studies do not conform to a single format. Therefore,
one of the objectives of this task is to homogenize and harmonize data coming
from different research fields (geophysical, geochemical, geological,
technological, etc.) and create and provide access to an advanced database of
environmental impact indicators associated with shale gas exploitation. This
requires the development of an over-arching structure for higher-level data
integration. Further, descriptive and readable metadata should be added as a
support to the database.

##  Site data

During the SHEER project a new multidisciplinary environmental database from
the on-site monitoring of shale gas exploration operation at the Wysin Site in
Poland will be created. Moreover, the SHEER database will compile existing
multidisciplinary data from past shale gas exploitation test sites, processing
procedures, results of data interpretation and recommendations, as well as
other documents describing the state of the art. The database is planned to
include also data from proxy sites, from conventional hydrocarbon exploration
and enhanced geothermal fields that used fluid injection.

Following the EPOS WG10 nomenclature (Lasocki et al., 2014), the basic unit of
the SHEER database is the _episode_ . The episode is a comprehensive data
description of a geophysical (e.g. deformation) process, induced or triggered
by human technological activity in the field of exploration and exploitation
of georesources, which under certain circumstances can become hazardous for
people, infrastructure and/or the environment. Each episode consists of a
timecorrelated collection of geophysical data representing the geophysical
process, technological data representing the technological activity (which is
the cause of this process) and all other relevant geo-data describing the
environment, in which the technological activity and its result or by-product,
the geophysical process take place.

The SHEER episodes are:

  1. Unique data sets from shale gas operation sites in Lubocino (Poland) and Preese Hall (UK); 

  

  2. Conventional oil and gas production sites (the Groningen site in the Nederland and the Beckingham site in UK); 

  

  3. Sites where stimulation for geothermal energy production and geothermal experiments took place. They will be included into the SHEER database due to their close analogy to the mechanisms of shale gas stimulation and induced seismicity problems. For this reason these data will be used as a proxy (The Geysers site in California, USA and Gross Schönebeck experimental site in Germany); 

  

  4. A unique component of the SHEER database is represented by the monitoring activity performed during the project in one active shale gas exploration site in Wysin, Pomerania, Poland. In this site, the seismicity, water conditions and air pollution are being monitored in the direct vicinity of newly drilled wells with horizontal stimulation. The monitoring activity commenced in the pre-operational phase, in order to determine the key baseline of the monitored parameters. Afterwards, the assessment of both the exploratory vertical drillings and the horizontal fracking phases will be performed. Finally, in order to assess experimentally protracted environmental effects, the monitoring activity will continue after the end of the exploration and appraisal operation phases. 

  

  

The list of the SHEER episodes is provided in Table 1. Types of data, which
are planned to be integrated within the SHEER database, are summarized in
Table 2.

**Table 1 List of the SHEER database episodes.**  
  
<table>  
<tr>  
<th>

**Inducing technology**

</th>  
<th>

**Name**

</th>  
<th>

**Case type**

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

**Unconventional hydrocarbon extraction**

</td>  
<td>

WYSIN Shale Gas

</td>  
<td>

Present case study

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

LUBOCINO Shale Gas

</td>  
<td>

Past case study

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

PREESE HALL Shale Gas

</td>  
<td>

Past case study

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

**Conventional hydrocarbon extraction**

</td>  
<td>

BECKINGHAM SITE conventional hydrocarbon production

</td>  
<td>

Past case study

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

GRONINGEN FIELD conventional hydrocarbon production

</td>  
<td>

Past case study

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

**Geothermal energy production**

</td>  
<td>

GROSS SCHÖNEBECK geothermal

energy production experiment

</td>  
<td>

Past case study

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

THE GEYSERS geothermal energy production

</td>  
<td>

Past case study

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

**Table 2 List of data types which are planned to be integrated within SHEER
database.**  
  
<table>  
<tr>  
<th>

**Episode Name**

</th>  
<th>

**Section Type**

</th>  
<th>

</th>  
<th>

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

**Data relevant for the considered hazards**

</th>  
<th>

**Industrial data**

</th>  
<th>

**Geodata**

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

**Seismic data**

</th>  
<th>

**Water**

**quality data**

</th>  
<th>

**Air quality data**

</th>  
<th>

**Satellite data**

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

**LUBOCINO**

**Shale Gas**

</td>  
<td>

</td>  
<td>

**X**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

**PREESE HALL**

**Shale Gas**

</td>  
<td>

**X**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

**X**

</td>  
<td>

**X**

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

**BECKINGHAM**

**SITE conventional hydrocarbon production**

</td>  
<td>

**X**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

**X**

</td>  
<td>

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

**GRONINGEN FIELD**

**conventional hydrocarbon production**

</td>  
<td>

**X**

</td>  
<td>

</td>  
<td>

</td>  
<td>

**X**

</td>  
<td>

</td>  
<td>

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

**GROSS**

**SCHÖNEBECK**

**geothermal energy production experiment**

</td>  
<td>

**X**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

**X**

</td>  
<td>

**X**

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

**THE GEYSERS**

**geothermal energy production**

</td>  
<td>

**X**

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

**X**

</td>  
<td>

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

**WYSIN Shale Gas**

</td>  
<td>

**X**

</td>  
<td>

**X**

</td>  
<td>

**X**

</td>  
<td>

**X**

</td>  
<td>

**X**

</td>  
<td>

**X**

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

During the first phase of the SHEER project, the SHEER database inquiries were
sent to the data owners in order to collect information about the data
availability and the comprehensiveness. The information required are:

  * availability verification of data planned to be integrated; 

  

  * completeness verification of episode data (mandatory availability of data relevant for the considered hazards and technological data); 

  

  * completeness verification of seismic data (mandatory availability of catalogue and signals); 

  

  * assessment of available data in terms of additional processing and preparation; 

  

  * assessment of available data formats in terms of format homogenization. 

  

Data providers are also obligated to prepare information about the observation
network as an inventory.xml file (SeisComp standard).

Ground subsidence as the satellite data will be collected for Wysin and
Groningen Field episodes in determined time window.

##  Research data

The processed, organized, structured or presented data in a given context, are
generated through different processes and they can be divided into different
categories. The categories considered in the SHEER project are:

  1. Simulations: data generated from test models where model and metadata are also important; 

  

  2. Derived or compiled information: e.g. text and data mining, compiled database, 3D models; 

  

  3. Reference data: methodologies to assess environmental impacts and risks across the different operational phases of shale gas exploitation and exploration, best practices. This type of data will include: text or word documents, spreadsheets, questionnaires, photographs, slides, samples, collection of digital objects acquired and generated during the research process, data files, models, algorithms, scripts, contents of an application such as input, output, log files for analysis software, simulation software, schemas, methodologies and workflows; standard operating procedures and protocols. 

  

  

The document repository of the Local Data Center of IG PAS (see Section 2.4),
which will be available through TCS AH at the end of the project, is ready to
collect the research data produced during the project as well as they will be
partially available on SHEER website.

##  Data for the dissemination process of SHEER results

This group of data will include a SHEER communication strategy and tools for a
comprehensive policy of dissemination and integration in the following areas:
inside the SHEER Consortium, to the wider scientific and technical community
and to external stakeholders.

All the information are uploaded on the SHEER website (
_http://www.sheerproject.eu/_ )  in the specific “Dissemination” section,
where external users can download: presentations, scientific publications and
media articles, Figure 1.

**Fig. 1 SHEER website and Dissemination section.**

The information are also communicated through: social media tools (Twitter and
Facebook), newsletters and blogs, leaflets (available in eleven languages),
interviews, photos, newsletters, etc.

All the aspects related to the SHEER communication strategy and tool are
detailed in the deliverable D8.4 “Dissemination plan and guidelines for SHEER
reports”.

Dissemination data produced during the project will be also stored in the
document repository (see Section 2.4) of the Local Data Center of IG PAS.

##  SHEER database

All the data collected and produced within the SHEER project are stored in the
Local Data Centre (LDC), which operates in IG PAS. Additionally, during the
project data will be systematically published on the TCS AH research platform
(see Chapter 3).

The LCD has been constructed using the CIBIS software – the system created to
store, manage, configure, verify and describe data in IS-EPOS project. CIBIS
has separate modules to manage:

  * Users (which allows to set authorities to the groups of users); 

  

  * Episodes (which allows to group directories into episodes disregarding to which storage they are assigned); 

  

  * Storages (which allows to place directories physically in the server); 

  

  * Directories, with internal structure created on the basis of a data scheme (which allows not only to add files and directories but also to copy, download, compress, unpack, rename, move or view file contents. All versions of uploaded files are being stored in the system and it is possible to manage these versions.); 

  

  * Schemes (which are used to create structure trees inside directories and to define metadata rules and values); 

  

  * Configurations (which are used to manage validators and converters). Raw data can be easily converted to the chosen format using created converters, e.g. ASCII to miniSEED converter. Format of integrated data can be easily validated using chosen validators. There is also the possibility to add new converters or validators to the system; 

  

  * Data for publication (which is used to set metadata values for selected directories basing on various schema and rules files, which are defined in the ‘Schemes’ module). 

  

Modules arranged for the SHEER database are:

  * Storage (Figure 2), 

  

  * Episodes according to SHEER proposal (Figure 3), 

  

  * Schema supporting accepted data structure and rules for metadata (Figure 4),  Document repository (Figure 5). 

  

**Data storage from past case studies**

Raw data delivered by data providers are stored in separate directories named:
“buffer + name of the institution providing data”. Complete, verified and
homogenized data are stored in final directories listed in Figure 2.

**Data storage from Wysin site**

Currently, raw data and documents from WYSIN episode are stored in SHEERWER,
which is a local server operating in IG PAS, dedicated to the SHEER project
and open for external users (sheerwer.igf.edu.pl). Processed data in
homogenized formats, except waveforms, are available in LDC.

Waveforms, which are stored in SeisComp system on SHEERWER, are available via
Arclink protocol for registered users only (see Chapter 5).

**Fig. 2 Screenshot of CIBIS service of Local Data Centre for SHEER data
collection and management. This service enables to load, delete, copy and
upload data, validate and run conversions of data, set or change source of the
data.**

**Fig. 3 Screenshot of CIBIS service of Local Data Centre for episode data
management.**

**Fig. 4 Screenshot of CIBIS service of Local Data Centre for schemes.
Metadata are created for files and directories using xml format.**

**Fig. 5 Screenshot of CIBIS service of Local Data Centre for document
repository.**

##  Data collection

**Past case studies**

The collection and preparation of data from past case studies was carried out
in five stages:

  1. **Revision of the data:** The data providers were asked to fill inquiries in the SHEER database, in order to evaluate the content and the quality of data for each episode. 

  

  2. **Determination of data accuracy and limitations:** This stage compromises: analysis of the SHEER database inquiries; definition of the type of available and necessary data for the database compilation; evaluation of the comprehensiveness and completeness of the datasets. 

  

  3. **Data delivery:** The data providers of each episode uploaded data to temporary directories in LDC (names: “buffer + name of the institution providing data”). Each data provider has an access only to a buffer directory assigned to the native institution (see Chapter 5). 

  

  4. **Homogenization of data formats:** Delivered data were standardized according to .mat and .xlsx formats (see Chapter 3) and placed in the episode data structure of the final directories (Figures 2, 5). 

  

  5. **Metadata preparation:** Metadata were prepared following the XML standard format for metadata developed within the IS-EPOS  1  project. 

  

  

**Present case study (Wysin Site)**

The collection and preparation of air and water quality data from Wysin Site
to LDC is continuously carried on according to the following stages:

  1. **Data delivery:** Data providers update raw data files available on SHEERWER with most recent registrations. 

  

  2. **Homogenization of data formats:** Delivered data are standardized according to .mat and .xlsx formats (see Chapter 3) and placed in the episode data structure of LDC final directories (Figures 2, 5). 

  

  3. **Metadata preparation:** Metadata are prepared following the XML standard format for metadata developed within the IS-EPOS project. 

  

  

As mentioned above, seismic data are transmitted on-line in real-time from 16
short period stations to SHEERWER and stored in the SeisComp system.

#  Expected schedule for data sharing

All data gathered within the SHEER project are available for all Consortium
members via CIBIS (past case studies) and SHEERWER (Wysin site) in both
standard .mat and .xlsx formats (see Chapter 3). In the meantime, data are
being prepared to be integrated on TCSAH  2  platform developed in IS-EPOS and
EPOS IP projects. All episodes will be available on TCS-AH platform within the
30/04/2018. Before that, SHEER episodes will be accessible only to SHEER
project members. The discrimination will be on the basis of affiliation
assigned to the platform user. After the 30/04/2018, SHEER episodes will be
accessible to all registered platform users according to data and services
policy document, which is going to be prepared during the project. This
document will be based on and completely consistent with data and services
policy developed within IS-EPOS project and implemented to TCS AH platform and
EPOS IP  3  project.

TCS AH is a research platform which integrates distributed research
infrastructures (RI) to facilitate and stimulate research on anthropogenic
hazards (AH) especially those associated with the exploration and exploitation
of georesources. The innovative element is the uniqueness of the integrated RI
which comprises two main deliverables:

  * Exceptional datasets, called ’episodes’, which comprehensively describe a geophysical process; induced or triggered by human technological activity, posing hazard for populations, infrastructure and the environment; 

  

  * Problem-oriented, bespoke services uniquely designed for the discrimination and analysis of correlations between technology, geophysical response and resulting hazard. 

  

These objectives will be achieved through the Science - Industry Synergy built
by WG10 in EPOS PP  4  , ensuring bi-directional information exchange,
including unique and previously unavailable data furnished by industrial
partners. The Episodes and services to be integrated have been selected using
strict criteria during the EPOS PP. The data are related to a wide spectrum of
inducing technologies, with seismic/aseismic deformation and production
history as a minimum dataset requirement, and the quality of software services
is confirmed and referenced in literature.

All data from past case studies gathered in LDC are already available for all
Consortium members via CIBIS. Data uploaded by data providers are verified,
prepared and homogenized within two weeks from the delivery date and published
in final directory for all project members.

_Availability of data from Wysin site:_

  * waveforms: available in real-time via Arclink protocol for registered users, 

  

  * processed air and water quality data: data in standard format available after maximum 2 weeks from data update via CIBIS, 

  

  * raw data and documents: available via SHEERWER for all Consortium members. 

  

#  Standards for format and content

All format and content standards used in the SHEER project have been adopted
from solutions developed within IS-EPOS and EPOS-IP projects in order to
preserve consistency of all data integrated on TCS AH platform and ensure its
compatibility with already implemented IT solutions.

##  Database structure

Verified and homogenized data in LDC are gathered within final episode
directories (Figure 2). Each directory has the same internal structure of
subdirectories (Figure 6):

  * **Data relevant for the considered hazards:**

    * Seismic data (e.g. catalogue, signals, seismic / ground motion network); o Water quality data (e.g. physicochemical water properties, piezometric levels and abstraction rates); 

  

    * Air quality data (e.g. air properties, air stations); o Satellite data; 

  

  

  * **Industrial data** (e.g. drilling data, fracture data); 

  

  * **Geodata** (e.g. velocity model). 

  

**Fig. 6 Structure of data for an episode. Green rectangle represents the
episode and the blue ones directories.**

###  Other data

The main aim of the SHEER project is to develop methodologies to assess the
environmental impacts/risks associated with the exploitation and exploration
of shale gas.

The possible impacts of a shale gas project may include _primary impacts_
associated mainly with environmental issues (such as groundwater, air and
surface water), and _secondary impacts_ related mainly with the _disruption_
caused specifically to the community (that includes the built environment and
society) or the ecosystem localized in the surroundings of a shale gas
development project. The pathways resulting in primary impacts can be almost
fully considered from a physical point of view, whereas those considering the
secondary impacts do not pertain only to the physical domain but also to the
socio-economic domain. For this reason, parallel to the assessment of effects
in physical elements, secondary impacts can also embrace the socio-economic
effects.

Therefore, the assessment of secondary impacts requires the collection of
“other” types of data needed to characterize both the vulnerability and the
exposure of a community surrounding a shale gas site.

For example to assess the potential damage to the built environment due to the
seismicity induced by shale gas exploration and exploitation requires the
typological characterization of the portfolio of buildings and infrastructures
characterizing the site. Building and (and elements of an infrastructure)
typologies are defined based on an expected common seismic behaviour, i.e the
probability of reaching a certain damage state for a given seismic input can
vary depending on construction material, structural configuration and other
several constructive details. A convenient way for defining typological
seismic vulnerability is the use of fragility curves that provide the
probability of exceeding a certain damage state threshold conditional to a
selected seismic input parameter.

Fragility curves may be defined for selected building typologies, grouping
together structures, which are expected to have a similar seismic behaviour.
When developing a building classification the choice is between usability and
accuracy. An overly detailed subdivision may lead to very specific results but
mat be impractical due to both the use (i.e. needing much information to
assign a building class) and the derivation (many curves to develop). On the
other hand, an overly simplistic classification may group together buildings
with completely different seismic behaviour. Geometry, material properties,
morphological features, age, seismic design level, anchorage of the equipment,
soil conditions, and foundation details are among usual typology
descriptors/parameters and represents the most important factors affecting the
seismic response of a building.

The knowledge of the inventory of a specific structure in a region and the
capability to create building classes are among the main challenges when
carrying out a seismic risk assessment at a city scale, where it is
practically impossible to perform this assessment at building level. Thus, the
derivation of appropriate fragility curves for any type of structure depends
entirely on the creation of a reasonable taxonomy that is able to classify the
different kinds of structures in any system exposed to seismic hazard. There
are different taxonomies developed in past research projects, in Europe (e.g.
RISK-UE and LESSLOSS EU projects) and USA (e.g. HAZUS or ALA), that have been
reviewed and updated in the SYNER- G project in order to develop a unique
typology for all elements at risk. In SYNER-G a great effort was paid to
create a coherent and comprehensive taxonomy from which European typologies
for the most important elements at risk are defined (Pitilakis et al., 2014).
The main categories of this classification scheme proposed for buildings are:
force resisting mechanism (FRM), force resisting mechanism material (FRMM),
plan regularity (P), elevation regularity (E), cladding (C), detailing (D),
floor system (FS), roof system (RS), height level (H), and code level (CL) as
summarized in the following table.

**Table 3 Data inventory for the vulnerability characterization of buildings
of a specific site**  
  
<table>  
<tr>  
<th>

**Buildings (SYNER-G taxonomy)**

Localization

Age

Type of construction

</th> </tr> </table>

Yes

Write a file format, e.g. GIS. Select yes or no.

Select yes or no  
  
<table>  
<tr>  
<th>

Force resisting mechanism Force resisting mechanism

material

Plan Regularity

Elevation Regularity

Cladding

Detailing

Floor system

Roof system

Height Level

Code level

</th> </tr> </table>

Select yes or no Select yes or no

Select yes or no

Select yes or no

Select yes or no

Select yes or no

Select yes or no

Select yes or no

Select yes or no

Select yes or no

Up to now, such information is not available for the case studies of the SHEER
project. Therefore standards and formats have not been specified for this kind
of data.

However if they should become available for the case studies, specific
information regarding data inventory, format and standards will be provided
and specified in the case study deliverables (WP7) and specific folders will
be added to the platform for the dissemination of the data.

##  Data formats

There are seven categories of data in LDC respect to the standard format
(Table 3).

**Table 4 Standard formats of different data categories.**  
  
<table>  
<tr>  
<th>

**Data category**

</th>  
<th>

**Standard format**

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

Seismic / ground motion catalogue

</td>  
<td>

mat

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

Seismic signals

(seismogram / accelerogram)

</td>  
<td>

miniSEED / SEED

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

Seismic / ground motion network

</td>  
<td>

SeisComp inventory xml

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

Water quality, air quality, industrial data and geodata*

</td>  
<td>

GDF (mat), xlsx

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

Other geodata

</td>  
<td>

geotiff / shapefile

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

Satellite data

</td>  
<td>

proposed: GDF, shapefile, geotiff

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

Documents

</td>  
<td>

pdf / graphic and video formats / presentation formats / other formats

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

* Water quality, air quality, industrial data and geodata are stored in Local Data Centre in two formats: Generic Data Format: GDF (mat structure) and xlsx. The structure of GDF files depends on data type and its complexity. Xlsx files are created automatically from GDF files and stored in zip packages with the same names as corresponding GDF files. 

###  Seismic / ground motion catalogue

Seismic and ground motion catalogues are stored in LDC in standard .mat
format. Catalogue .mat file contains only one variable with no predefined
name. The variable is a structure array with 3 defined fields:

  * **field** – name of the field in the catalogue (text value); consists of 123 predefined values (Table 4, Appendix 1) 

  

  * **type** – type of the field in the catalogue and the way of displaying it (numeric value, Appendix 1); 

  

  * **val** – column array of values. For text the column is a cell array with text fields. For other values the column is a numeric column. 

  

If some values of catalogue fields are not calculated, they are filled with:
NaN (if the column should contain a numeric value) or null [] (if the column
should contain a text value). Obligatory fields for catalogue are: "ID",
"Time" and "Mw" or "ML".

**Table 5 Names of first 15 seismic catalogue fields with short description.
The rest of the list together with ground motion catalogue fields list are
available in Appendix 1.**  
  
<table>  
<tr>  
<th>

**Name of**

**field**

</th>  
<th>

**Description of the field**

</th>  
<th>

**Data format**

</th>  
<th>

**Number**

**of data type** 3

</th>  
<th>

**Unit**

</th>  
<th>

**Comments**

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

**ID**

</td>  
<td>

Event ID

</td>  
<td>

text

</td>  
<td>

3

</td>  
<td>

</td>  
<td>

required field

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

**Time**

</td>  
<td>

Matlab serial numerical time

</td>  
<td>

double

</td>  
<td>

5

</td>  
<td>

days

</td>  
<td>

required field

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

**Lat**

</td>  
<td>

Latitude

</td>  
<td>

double

</td>  
<td>

24,25

</td>  
<td>

[o] – North positive

</td>  
<td>

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

**Long**

</td>  
<td>

Longitude

</td>  
<td>

double

</td>  
<td>

24,25,34,

35

</td>  
<td>

[o] – East positive

</td>  
<td>

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

**Depth**

</td>  
<td>

Hypocentre depth measured from the ground level

</td>  
<td>

double

</td>  
<td>

11-13

</td>  
<td>

[km]

</td>  
<td>

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

**Elevation**

</td>  
<td>

Hypocentre elevation measured over the see

level

</td>  
<td>

double

</td>  
<td>

10

</td>  
<td>

[m]

</td>  
<td>

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

**X**

</td>  
<td>

Original Coordinate

</td>  
<td>

</td>  
<td>

10

</td>  
<td>

</td>  
<td>

Original coordinates if other than geographical.

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

**Y**

</td>  
<td>

</td>  
<td>

10

</td>  
<td>

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

**Z**

</td>  
<td>

</td>  
<td>

10

</td>  
<td>

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

**EPI_err**

</td>  
<td>

epicentral error

</td>  
<td>

double

</td>  
<td>

10

</td>  
<td>

[m]

</td>  
<td>

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

**Depth_err**

</td>  
<td>

depth error

</td>  
<td>

</td>  
<td>

10

</td>  
<td>

[m]

</td>  
<td>

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

**Nl**

</td>  
<td>

No of stations used in the localisation

</td>  
<td>

</td>  
<td>

2

</td>  
<td>

</td>  
<td>

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

**M0**

</td>  
<td>

Scalar moment

</td>  
<td>

</td>  
<td>

7

</td>  
<td>

[Nm]

</td>  
<td>

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

**Mw**

</td>  
<td>

moment magnitude

</td>  
<td>

double

</td>  
<td>

4

</td>  
<td>

</td>  
<td>

Mw or ML is required

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

**Name of**

**field**

</td>  
<td>

**Description of the field**

</td>  
<td>

**Data format**

</td>  
<td>

**Number of data type5**

</td>  
<td>

**Unit**

</td>  
<td>

**Comments**

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

</td>  
<td>

</td>  
<td>

0.1  4

</td>  
<td>

</td>  
<td>

</td>  
<td>

field

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

**ML**

</td>  
<td>

local magnitude

</td>  
<td>

double

0.1

</td>  
<td>

4

</td>  
<td>

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

###  Seismic signals

There are two standard formats allowed for seismic signals storage in SHEER
database:

  * SEED format: used to store triggered seismic signals in LDC, 

  

  * miniSEED format: used to store seismic signals from continuous registration in SeisComp structure. It is possible to receive signal also in SEED format if Arclink protocol is used for data transfer. 

  

The Standard for the Exchange of Earthquake Data (SEED) is a data format
intended primarily for the archival and exchange of seismological time series
data and related metadata. The format is maintained by the  _International
Federation of Digital Seismograph Networks_ and documented in the  SEED Manual
(PDF format). Originally designed in the late 1980s, the format has been
enhanced and refined a number of times and remains in widespread use. A so-
called full SEED volume is the combination of time series values along with
comprehensive metadata. In essence a full SEED volume is the combination of
miniSEED with a matching dataless volume in a single file.

###  Seismic / ground motion network

Seismic and ground motion networks are saved in standard SeisComp inventory
xml files.  SeisComP  is a seismological software for data acquisition,
processing, distribution and interactive analysis that has been developed by
the GEOFON Program at Helmholtz Centre Potsdam, GFZ German Research Centre for
Geosciences and gempa GmbH.

###  GDF

GDF format is universal and easy to use. It contains information about
coordinate system in which data are stored, the time zone in which the time is
determined, and information about the stored data, such as: unit, data type,
names of variables with descriptions. The proposed format is based on data
structures that can be easily saved to a file and are easy to manipulate. This
structure contains nine variables, where d is the most essential one, because
it contains the data which can be further processed. The other variables are
used for complete data description – units, coordinate system, fields etc.
General GDF description is provided in Table 5.

**Table 6 Main structure of Generic Data Format (GDF).**  
  
<table>  
<tr>  
<th>

**Variable name**

</th>  
<th>

**Type**

</th>  
<th>

**Description**

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

**FormatName**

</td>  
<td>

char

</td>  
<td>

Name of data format GDF (Generic Data Format).

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

**FormatVersion**

</td>  
<td>

real

</td>  
<td>

When changing/expansion of the format change its version. It can have one
number after the decimal point.

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

**CRS**

</td>  
<td>

char

</td>  
<td>

Coordinate Reference System

EPSG code (or local) mapping surveying (http://epsg.io), standard WGS84 (EPSG:
4326)

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

**TimeZone**

</td>  
<td>

char

</td>  
<td>

Acronym of Time Zone

(http://en.wikipedia.org/wiki/List_of_time_zone_abbreviations), normally UTC

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

**Description**

</td>  
<td>

char

</td>  
<td>

The text description of the data contained in the file

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

**FieldDescription**

</td>  
<td>

cell array

</td>  
<td>

Description of the fields. An array contains two columns: the first contains
the name of the field/column of data, the second contains a description of
them. All data must be specified

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

**FieldUnit**

</td>  
<td>

cell array of char

</td>  
<td>

Description of units for individual data, e.g. m/s. An array contains two
columns: the first contains the name of the field/column of data, the second
contains the unit. All data must be specified.

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

**FieldType**

</td>  
<td>

cell array of char

</td>  
<td>

Description of data type e.g. real. An array contains two columns: the first
contains the name of the field/column of data, the second contains the data
type description. All data must be specified. time - matlab serial numerical
time deg - angle in degrees, as for geographical coordinates, positive values
for N and E. int – integer number real – the real number char –
variable/parameter name

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

**d**

</td>  
<td>

struct array or cell array char

</td>  
<td>

The variable containing the data. The data may be as a single variable, a
vector or an array.

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

GDF files can be easily opened with both Matlab and open source Octave
software and converted to ASCII (CSV) format with homogenous structure.

The following data types are currently available in LDC in the form of GDF
files:

  * hydrochemical data – site visit 

  

  * hydrochemical data – continuous measurement 

  

  * hydrochemical data 2– site visit 

  

  * barometric data 

  

  * well path 

  

  * station network 

  

  * water table 

  

  * air quality 

  

  * radon 222 concentration 

  

  * proppant concentration 

  

  * injection rate 

  

  * cumulative injection 

  

  * wellhead pressure 

  

  * bottomhole pressure 

  

  * flowback bottomhole pressure 

  

  * flowback rate 

  

  * flowback volume 

  

  * injected volume 

  

  * velocity model 

  

Detailed structures of all GDF files listed above are presented in Appendix 2.

###  Xlsx files

Xlsx files are created automatically from GDF files and stored in zip packages
with the same names as original GDFs. Xlsx files are created in order to make
data available for people who are not used to operate in Matlab or Octave
software. Each zip package contains at least two xlsx files:

  * info file, where each worksheet presents information from different GDF variable except variable d. There is always one info file in each zip package. 

  

  * data file, where all data from GDF d structure is stored. Depending on d variable complexity each zip package can include one or more xlsx data files. 

  

Date and time in xlsx files is determined as numeric value according to Excel
rules and can be easily converted to time format.

###  Geotiff / shapefile

Geodata, which is frequently available in the form of maps and therefore
cannot be converted into GDF format, is stored as geographically orientated
data in geotiff (raster) or  shapefile  (vector) formats.

###  Satellite data

Satellite data will be available in LDC in three various formats: GDF,
shapefile and geotiff.

###  Documents

Documents, which are stored in Document Repository of LDC, are provided in
various data formats depending on their contents: pdf, graphic formats, video
formats, presentation formats or other formats.

##  Metadata

###  Episodes, directories and files

SHEER database metadata are prepared according to the guidelines of the IS-
EPOS project. Various metadata fields are required depending on the object
type (episode, directory or file). Values of metadata are inherited down
through the structure of data in the episode. For example, it is enough to set
the value of metadata field ‘episode name’ for episode and then all
directories and files belonging to this episode will have the same value of
field ‘episode name’ as this episode. The same rule applies to directories. Of
course it is possible to change inherited metadata value if needed. Metadata
set for each file is saved in LDC in xml format. The detailed description of
metadata are prepared separately for each object type: episode, directory and
file (Tables 6-8). Apart from metadata presented in the tables metadata ‘date’
is always published. All dataTypes available within the SHEER project are
presented in Table 9.

**Table 7 Detailed description of episode metadata.**  
  
<table>  
<tr>  
<th>

**Metadata Name**

</th>  
<th>

**Description and option**

</th>  
<th>

**Required metadata**

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

**episodeName**

</td>  
<td>

Name of episode

</td>  
<td>

x

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

**episodeCode**

</td>  
<td>

Code of episode

</td>  
<td>

x

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

**path**

</td>  
<td>

Episode path

</td>  
<td>

x

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

**itemType**

</td>  
<td>

Type of object = ‘episode’

</td>  
<td>

x

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

**episodeOwner**

</td>  
<td>

Owner of episode

list: ‘IG PAS’, ‘KeU’, ‘KNMI’, ‘AMRA’

</td>  
<td>

x

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

**description**

</td>  
<td>

Long episode content description

</td>  
<td>

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

**text**

</td>  
<td>

Short episode content description

</td>  
<td>

x

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

**country**

</td>  
<td>

Episode localization (country) list: ‘Poland’, ‘United Kingdom’,
‘Netherlands’, ‘Germany’, ‘USA/California’

</td>  
<td>

x

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

**region**

</td>  
<td>

Episode localization (region) list: ‘Pomerania’, ‘Lancashire’, ‘Beckingham’,
‘Groeningen’, ‘Gross Schoenebeck’, ‘Geysers’

</td>  
<td>

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

**positionType**

</td>  
<td>

Type of positioning of the episode list: ‘point’, ‘polygon’

</td>  
<td>

x

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

**coordinateSystem**

</td>  
<td>

Coordinate system of positioning of the episode (e.g. ‘WGS-84’)

</td>  
<td>

x

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

**longitude**

</td>  
<td>

Episode localization (longitude)

</td>  
<td>

x

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

**latitude**

</td>  
<td>

Episode localization (latitude)

</td>  
<td>

x

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

**start**

</td>  
<td>

Start time of episode

</td>  
<td>

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

**end**

</td>  
<td>

End time of episode

</td>  
<td>

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

**impactingFactor**

</td>  
<td>

Technology impacting the environment – one of: conventional hydrocarbon
extraction, unconventional hydrocarbon extraction, geothermal energy
production

</td>  
<td>

x

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

**allowedDownload**

</td>  
<td>

Permission to download the data

list: ‘SHEER’, ‘EPOS-IP’,’SHEER, EPOS-IP’, ‘all’, ‘affiliated’

</td>  
<td>

x

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

**allowedVisibility**

</td>  
<td>

Permission to see the data

list: ‘SHEER’, ‘EPOS-IP’,’SHEER, EPOS-IP’, ‘all’, ‘affiliated’

</td>  
<td>

x

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

**dataPolicy**

</td>  
<td>

Data policy (e.g. ‘embargo_20180431’)

</td>  
<td>

x

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

**Table 8 Detailed description of directory metadata.**  
  
<table>  
<tr>  
<th>

**Metadata Name**

</th>  
<th>

**Description and option**

</th>  
<th>

**Required metadata**

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

**name**

</td>  
<td>

Name of directory

</td>  
<td>

x

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

**path**

</td>  
<td>

Directory path

</td>  
<td>

x

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

**itemType**

</td>  
<td>

Type of object = ‘directory’

</td>  
<td>

x

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

**text**

</td>  
<td>

Short directory content description

</td>  
<td>

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

**description**

</td>  
<td>

Long directory content description

</td>  
<td>

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

**type**

</td>  
<td>

Type of data section

list: ‘data relevant for the considered hazards’, ‘seismic’, ‘water

quality’, ‘air quality’, ‘satellite’, ‘industrial’, ‘geodata’

</td>  
<td>

x

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

**region**

</td>  
<td>

Directory localization (region) list: ‘Pomerania’, ‘Lancashire’, ‘Beckingham’,
‘Groeningen’, ‘Gross Schoenebeck’, ‘Geysers’

</td>  
<td>

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

**start**

</td>  
<td>

Start time of directory

</td>  
<td>

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

**end**

</td>  
<td>

End time of directory

</td>  
<td>

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

**dataType**

</td>  
<td>

Type of data

</td>  
<td>

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

**coordinateSystem**

</td>  
<td>

Coordinate system of positioning of the directory (e.g. ‘WGS84’)

</td>  
<td>

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

**Table 9 Detailed description of file metadata.**  
  
<table>  
<tr>  
<th>

**Metadata Name**

</th>  
<th>

**Description and option**

</th>  
<th>

**Required metadata**

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

**name**

</td>  
<td>

Name of file

</td>  
<td>

x

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

**path**

</td>  
<td>

File path

</td>  
<td>

x

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

**itemType**

</td>  
<td>

Type of object = ‘file’

</td>  
<td>

x

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

**text**

</td>  
<td>

Short file content description

</td>  
<td>

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

**description**

</td>  
<td>

Long file content description

</td>  
<td>

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

**dataType**

</td>  
<td>

Type of data

</td>  
<td>

x

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

**start**

</td>  
<td>

Start time of data

</td>  
<td>

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

**end**

</td>  
<td>

End time of data

</td>  
<td>

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

**eventID**

</td>  
<td>

ID number of seismic event

</td>  
<td>

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

**region**

</td>  
<td>

File localization (region) list: ‘Pomerania’, ‘Lancashire’, ‘Beckingham’,
‘Groeningen’, ‘Gross Schoenebeck’, ‘Geysers’

</td>  
<td>

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

**coordinateSystem**

</td>  
<td>

Coordinate system of positioning of the file (e.g. ‘WGS-84’)

</td>  
<td>

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

**auxiliary**

</td>  
<td>

Auxiliary type of data: if auxiliary then = ‘1’

</td>  
<td>

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

**allowedVisibility**

</td>  
<td>

Permission to see the data: list: ‘SHEER’, ‘EPOS-IP’, ‘SHEER, EPOS-IP’, ‘all’,
‘affiliated’

</td>  
<td>

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

**Table 10 List of dataTypes available within SHEER project.**  
  
<table>  
<tr>  
<th>

</th>  
<th>

**dataType name**

</th>  
<th>

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

**air measurement points**

</td>  
<td>

flowback rate

</td>  
<td>

physicochemical water properties

</td>  
<td>

stratigraphy

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

**barometric data continuous**

</td>  
<td>

geotiff

</td>  
<td>

production parameters

</td>  
<td>

tectonics

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

**barometric measurement points**

</td>  
<td>

ground motion catalogue

</td>  
<td>

proppant inf

</td>  
<td>

underground water level

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

**bottomhole pressure**

</td>  
<td>

ground motion network

</td>  
<td>

radon 222 content

</td>  
<td>

velocity model

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

**catalogue**

</td>  
<td>

hydro borehole path

</td>  
<td>

ray tracing angles

</td>  
<td>

water lab analyses

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

**chemical air properties**

</td>  
<td>

injection parameters

</td>  
<td>

rock parameters

</td>  
<td>

water level

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

**chemical water properties**

</td>  
<td>

injection pressure

</td>  
<td>

seismic network

</td>  
<td>

water measurement points

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

**episode image**

</td>  
<td>

injection rate

</td>  
<td>

seismic profile

</td>  
<td>

waveform

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

**episode logo**

</td>  
<td>

injection volume

</td>  
<td>

shear modulus

</td>  
<td>

well path

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

**episode xml**

</td>  
<td>

physical air properties

</td>  
<td>

shp file

</td>  
<td>

well position

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

**flowback bottomhole pressure**

</td>  
<td>

physical water properties

</td>  
<td>

signal

</td>  
<td>

wellhead pressure

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

**flowback volume**

</td>  
<td>

physical water properties continuous

</td>  
<td>

signal accelerogram

</td>  
<td>

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

###  Documents

All documents stored in the document repository have to be described with
metadata. Each document type is described with different set of metadata.
Currently, two types of documents are defined: articles and reports. Together
with project development and according to appearing needs, more document types
will be added. Detailed description of metadata set for each document type is
presented in Table 10.

**Table 11 Metadata sets for articles and reports stored in document
repository.**  
  
<table>  
<tr>  
<th>

Metadata field

</th>  
<th>

Metadata field description

</th>  
<th>

Required metadata

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

Article

</th>  
<th>

Report

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

Abstract

</td>  
<td>

</td>  
<td>

x

</td>  
<td>

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

Additional information

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Corporate creators

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Creators

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Creators e-mail

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Creators Family Name

</td>  
<td>

</td>  
<td>

x

</td>  
<td>

x

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

Creators Given Name/Initials

</td>  
<td>

</td>  
<td>

x

</td>  
<td>

x

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

Creators Name

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Data of document

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

DOI

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

id

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Institution

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

ISSN

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Journal or Publication Title

</td>  
<td>

</td>  
<td>

x

</td>  
<td>

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

Keywords

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Number

</th>  
<th>

</th>  
<th>

</th>  
<th>

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

Owner of document

</td>  
<td>

</td>  
<td>

x

</td>  
<td>

x

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

Page range

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Place of publication

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Publication Details

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Publisher

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Title

</td>  
<td>

</td>  
<td>

x

</td>  
<td>

x

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

Type

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

URL

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Volume

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

#  Policies for stewardship and preservation

All data gathered within SHEER database are stored on the servers of Local
Data Centre (LDC) which belong to IG PAS. The software used for data storage
is CIBIS, which was developed within IS-EPOS project. It is software dedicated
for storage and management of big datasets. Two big advantages of CIBIS are:
(1) it enables ordered storage and management of all uploaded data versions
together with detailed information about each version, (2) it offers a wide
range of authorities which can be used to easily manage different users
profiles. The second point is discussed in detail in Chapter 5.

Data backup is being stored in CYFRONET Computer Centre of AGH University of
Science and Technology in Krakow and is updated every day. Only backup of
files is provided. Raw data from data providers is verified and homogenized by
Episode Adaptation Centre (EAC) staff working in IG PAS. For data quality
control of the SHEER database task a management system based on the open-
source  Redmine application  is used. The following path of data gathering,
verification, homogenization and quality control for SHEER database has been
established in EAC (Figure 7):

  * Data upload: Raw data are uploaded to proper ‘buffer’ subdirectory by data provider. Each data provider has an access to dedicated buffer directory in CIBIS. 

  

‘Administrator’ for this episode and its ‘Control group’ in EAC are assigned.

  * QC1: Administrator sets episode as a new task in SHEER database task management system. The Control group roles are distributed and the workflow Observer is appointed (20%). 

  

  * Data conversion and validation: Data are verified, converted (if needed) and homogenized by people assigned by Administrator. 

  

  * QC2: The completeness and quality of prepared data are checked (50% of workflow). 

  

  * Data transfer, metadata preparation and publication: Correct data are placed in final directories (Figure 3) according to episode data structure (Figure 6). Now data are visible to all SHEER database users who have permission to see this episode. All data files are described with sets of metadata prepared according to rules described in Chapter 3\. Episode can be published to TCS AH platform if needed. Metadata are also visible for SHEER database users. 

  

  * QC3: Administrator checks metadata sets and accepts episode as correct (100%). 

  

**Fig. 7 Episode Quality Control Workflow.**

#  Procedures to provide access

##  During the project

All data gathered within SHEER are currently available for project members via
CIBIS or SHEERWER. As mentioned earlier (see Chapter 2) during the project,
data will be systematically uploaded on the TCS AH platform and they will be
also available only for the affiliated SHEER members.

This will enable users to analyse gathered data using services already
implemented on TCS.

###  SHEER database

SHEER database is protected by IG PAS firewall. However, in order to provide
access to LDC for SHEER project members, the firewall needed to be opened for
external IP addresses used by institutions which build SHEER Consortium.

The access to LDC, for each separate SHEER project member, has been provided
by EAC staff by the creation of personal CIBIS account with relevant
authorities. Two classes of users has been defined for each institution:

  * Data downloader: user in this class can read and download data from all episodes (final directories – Figure 2). Additionally, user can browse document repository and download all published documents. User can read databases in ‘Data for publication’ module where all metadata assigned to episodes is visible (Figures 8, 10). 

  

  * Data provider: user in this class has the same authorities as data downloader and additionally he has the access to the buffer directory of his institution where he can upload and manage raw data. Data provider can also read and run ‘Configurations’ module where he can validate and convert raw data (Figures 9, 11). 

  

In each institution only 1-2 persons have authorities of Data provider. The
rest of project members are assigned to Data downloader group in order to
avoid database disorders.

EAC staff, who is responsible for data verification, validation, conversion
and homogenization, is assigned to the **Data manager** group. Members of this
group have all authorities available in CIBIS (Figure 12).

**Fig. 8 Authorities of users in Data downloader class (CIBIS: Admin Panel).**

**Fig. 9 Authorities of users in Data provider class (CIBIS: Admin Panel).**

**Fig. 10 The view of SHEER database for user from Data downloader class.**

**Fig. 11 The view of SHEER database for user from Data provider class.**

**Fig. 12 The view of SHEER database for user from Data manager class.**

###  SHEERWER

Each institution which is a part of the SHEER Consortium has unlimited access
to SHEERWER via dedicated account. Data available on SHEERWER can be browsed
and downloaded via internet browser interface (Figure 13).

Especially for seismic data download Arclink protocol can be used. Using
Arclink it is possible to download seismic data from any predefined time
period and station group in miniSEED or SEED format. For every user interested
in continuous seismic data separate login and password has been prepared in
order to safely download data from SeisComp.

The detailed instruction of the use of Arclink protocol for seismic data
download is available in Appendix 3.

**Fig. 13 The view of SHEERWER for every user.**

##  After the project

After the end of the project all SHEER episodes will be integrated on TCS AH
platform and will become available for all registered platform users.
Therefore, data quality control, maintenance and safety will be fully provided
by TCS. The rules of TCS maintenance and operational costs funding will be
prepared in the cooperation with EPOS-ERIC.