Medspiration â System Requirements Document - Data User Element

Medspiration 

System Requirements Document 

Customer : 

Contract No : 

WP No : 

ESA / ESRIN 

AO/1-4362/03/I-LG 

2100 

Document Ref : 

Issue Date : 

Issue : 

MED-SOC-RS-001_1 


22 February 2004 

F 

Issue F 

Title : 

Medspiration – System Requirements Document 

Abstract 

: This document defines the System Requirements for the Medspiration SST data 

processing system. It translates the User Requirements and the GHRSST-PP Data 

Processing Specification into a Reference Baseline for designing the Medspiration 

system. 

Author : Approval : 

Ian Robinson 

SOC-LSO 

Peter Challenor 

SOC-LSO Deputy Head 

Accepted : 

Distribution 

: Olivier Arino, ESRIN 

Dino Di Cola, ESRIN 

Craig Donlon, GHRSST-PP International Office Director 

Ian Robinson, SOC, Project Manager 

James Rickards, VEGA, DPM 

Medspiration Project Team 

Filename: 

med-soc-rs-001_1_f.doc 

Copyright © 2004 Southampton Oceanography Centre 

All rights reserved. 

SOC Laboratory for Satellite Oceanography 

European Way, Southampton, SO14 3ZH, UK 

Tel: +44 (0)23 8059 3438 Fax: +44 (0)23 6059 3059 

www.soc.soton.ac.uk 

© 2004 SOC Page 1 of 193




Issue F 

© 2004 SOC Page 2 of 193




Issue F 

This Page Is Intentionally Blank 

© 2004 SOC Page 3 of 193




Issue F 

TABLE OF CONTENTS 

1. INTRODUCTION ....................................................................................................................... 9 

1.1 Purpose and Scope .............................................................................................................. 9 

1.2 Structure of the Document.................................................................................................... 9 

1.3 Applicable and Referenced Documents ............................................................................. 10 

1.4 Definitions of Terms............................................................................................................11 

1.5 System Requirement Format.............................................................................................. 11 

2. SYSTEM OVERVIEW ............................................................................................................. 14 

2.1 System Context ..................................................................................................................14 

2.1.1 The importance of SST definitions used in Medspiration ............................................ 14 

2.1.2 Medspiration SST Products ......................................................................................... 16 

2.2 Overall structure of the Medspiration Processing System.................................................. 18 

2.3 Outline of the individual processes at each facility............................................................. 21 

2.3.1 L2P processing at CMS ............................................................................................... 21 

Ingest 21 

Quality Check ....................................................................................................................... 21 

Merging with ancillary data................................................................................................... 22 

Generate confidence data.................................................................................................... 22 

Generate L2P products ........................................................................................................ 22 

2.3.2 Processing at IFREMER .............................................................................................. 22 

Archive 23 

L4 UHR data production at IFREMER ................................................................................. 23 

Match-up data records production at IFREMER .................................................................. 24 

Dissemination of data from IFREMER ................................................................................. 24 

Control of Medspiration Processing at IFREMER................................................................ 24 

2.3.3 Processing at SOC....................................................................................................... 25 

AATSR Ingestion.................................................................................................................. 25 

Diagnostic data set generation at SOC................................................................................ 25 

3. FUNCTIONAL REQUIREMENTS ........................................................................................... 26 

3.1 System Requirements ........................................................................................................ 26 

3.1.1 General.........................................................................................................................26 

3.1.2 Input data ..................................................................................................................... 26 

3.1.3 Data products............................................................................................................... 26 

3.1.4 Archive and dissemination ........................................................................................... 27 

3.1.5 Overall system structure .............................................................................................. 28 

© 2004 SOC Page 4 of 193




Issue F 

3.2 CMS Facility ........................................................................................................................30 

3.2.1 Scheduler......................................................................................................................31 

3.2.2 Ingestion .......................................................................................................................31 

3.2.3 Quality Check ...............................................................................................................32 

3.2.4 Merging auxiliary data with SST ...................................................................................34 

3.2.5 Confidence value derivation .........................................................................................36 

3.2.5.1 Microwave sensor case ...........................................................................................37 

3.2.5.2 Infrared case............................................................................................................39 

3.2.6 SSES Assignation.........................................................................................................42 

3.2.7 L2P evaluation ..............................................................................................................42 

3.3 Ifremer Facility.....................................................................................................................43 

3.3.1 Archive..........................................................................................................................44 

3.3.1.1 Reference data ........................................................................................................44 

3.3.1.2 Online storage..........................................................................................................44 

3.3.1.3 Offline storage..........................................................................................................45 

3.3.1.4 Backup .....................................................................................................................45 

3.3.2 Generate L4 analysed products ...................................................................................45 

3.3.3 Matchup Data Base ......................................................................................................48 

3.3.3.1 Collecting the in-situ data ........................................................................................49 

3.3.3.2 Colocating the in-situ and satellite data...................................................................49 

3.3.3.3 Generating the MDB records ...................................................................................51 

3.3.4 Dissemination ...............................................................................................................52 

3.3.4.1 Ftp push/pull ............................................................................................................52 

3.3.4.2 DODS.......................................................................................................................52 

3.3.4.3 Live Access Server ..................................................................................................52 

3.3.5 System controller at Ifremer..........................................................................................53 

3.3.5.1 Dataflow control .......................................................................................................53 

3.3.5.2 Processing flow control............................................................................................54 

3.3.5.3 Triggering the processing ........................................................................................54 

3.3.5.4 Chaining the processes ...........................................................................................55 

3.3.5.5 Operation log system...............................................................................................55 

3.3.5.6 System monitoring ...................................................................................................55 

3.3.5.7 Synchronization with GHRSST-PP..........................................................................55 

3.3.5.8 Exchange MMR .......................................................................................................56 

3.3.5.9 Exchange error messages......................................................................................56 

3.3.5.10 Exchange data...................................................................................................57 

3.4 SOC Facility ........................................................................................................................57 

© 2004 SOC Page 5 of 193




Issue F 

3.4.1 AATSR Ingestion.......................................................................................................... 57 

3.4.2 HR-DDS Generation .................................................................................................... 58 

3.4.3 HR-DDS Archiving........................................................................................................ 59 

3.4.4 HR-DDS Dissemination................................................................................................ 59 

3.4.5 HR-DDS Controller....................................................................................................... 59 

4. INTERFACE REQUIREMENTS.............................................................................................. 60 

4.1 Internal................................................................................................................................ 60 

4.1.1 Interfaces within the CMS processing facility............................................................... 60 

4.1.2 Interfaces between L2P production and archiving systems......................................... 60 

4.1.3 Interfaces between archiving and dissemination systems........................................... 61 

4.1.4 Interfaces between archiving and MDB generation systems....................................... 61 

4.1.5 Interfaces between archiving and L4 generation system............................................. 61 

4.1.6 Interfaces within the archiving system ......................................................................... 62 

4.1.7 Interfaces between HR-DDS production and dissemination systems ......................... 62 

4.1.8 Interfaces between IFREMER system controller and other systems........................... 63 

4.2 External............................................................................................................................... 64 

4.2.1 Satellite data providers................................................................................................. 64 

4.2.2 In situ data provider...................................................................................................... 65 

4.2.3 GDAC ........................................................................................................................... 65 

4.2.4 GDAC MDB.................................................................................................................. 65 

4.2.5 Master Metadata Repository ........................................................................................ 66 

4.2.6 GDS error log system................................................................................................... 66 

4.2.7 User interfaces ............................................................................................................. 67 

4.2.8 DDS external interfaces ............................................................................................... 67 

5. PERFORMANCE REQUIREMENTS ...................................................................................... 69 

5.1 Scenario Definitions............................................................................................................69 

5.2 Characterisation of L2 input data........................................................................................ 70 

5.2.1 Satellite SST................................................................................................................. 70 

5.2.2 Auxiliary satellite data .................................................................................................. 71 

5.2.3 NWP model outputs ..................................................................................................... 72 

5.2.4 Reference data sets ..................................................................................................... 72 

5.3 Characterisation of in situ data ........................................................................................... 73 

6. EXPANDABILITY REQUIREMENTS...................................................................................... 76 

6.1 General ............................................................................................................................... 76 

6.2 Generation of L2P...............................................................................................................76 

© 2004 SOC Page 6 of 193




Issue F 

6.3 Diagnostic data set..............................................................................................................77 

7. SECURITY REQUIREMENTS.................................................................................................78 

8. DESIGN REQUIREMENTS .....................................................................................................79 

9. RELIABILITY, AVAILABILITY AND MAINTAINABILITY REQUIREMENTS ........................80 

10. TESTING REQUIREMENTS....................................................................................................81 

11. SAFETY REQUIREMENTS.....................................................................................................82 

12. CUSTOMER FURNISHED ITEMS ..........................................................................................83 

13. GLOSSARY .............................................................................................................................84 

APPENDIX A TRACE BETWEEN USER REQUIREMENTS AND SYSTEM 

REQUIREMENTS...........................................................................................................................88 

© 2004 SOC Page 7 of 193




Issue F 

AMENDMENT POLICY 

This document shall be amended by releasing a new edition of the document in its 

entirety. The Amendment Record Sheet below records the history and issue status of 

this document. 

AMENDMENT RECORD SHEET 

ISSUE DATE DCI No REASON 

A 19 Jan 2004 N/A Initial Issue 

B 15 Feb 2004 Extensive addition of detailed requirements from 

Ifremer, CMS / Avel Mor, and SOC. 

Addition of figures 

Note the addition of extra categories of SR. 

C 18 Feb 2004 Editing by ISR to harmonise the requirements, 

some additions to meet the needs of the GDS, 

corrections from CMS /Avel Mor and SOC 

D 19 Feb 2004 Addition of material from CLS and figure from 

SOC. Additions to section 2. 

E 20 Feb 2004 Corrections from CMS and SOC. 

F 22 Feb 2004 Final corrections from Ifremer. Added appendix 

with requirements trace matrix 

© 2004 SOC Page 8 of 193




Issue F 

1. INTRODUCTION 

1.1 Purpose and Scope 

The purpose of this document is to define all the System Requirements (SR) that are 

applicable to Medspiration. The SRs are arranged in a number of categories that will aid 

access to them. An associated method for validation of each SR has been identified. 

The SRs have been defined to ensure full verification of the User Requirements (UR) 

expressed in the Statement of Work (SOW), the Medspiration User Requirements 

document and the GHRSST-PP Data Processing Specification (GDS). Throughout this 

document the SRs are identified and inter-spaced with explanatory text (italicised) to aid 

the readability of the document. 

Referencing of the system requirements to the user requirements is documented in the 

Appendix. 

1.2 Structure of the Document 

After this introduction, the document is divided into a number of major sections that are 

briefly described below: 

SYSTEM OVERVIEW 

Provides an overview of the system. 

3 FUNCTIONAL REQUIREMENTS 

Defines the functional system requirements, uniquely numbers them and states 

the method of verification. 

4 INTERFACE REQUIREMENTS 

Defines the interface system requirements, uniquely numbers them and states 

the method of verification. This includes two sub-sections for internal and 

external interfaces. In this context external interfaces are defined as being 

external to the Medspiration system (i.e. not inter-module interfaces which are 

defined as internal). 

© 2004 SOC Page 9 of 193



5 PERFORMANCE REQUIREMENTS 


Issue F 

Defines the performance and capacity system requirements, uniquely numbers 

them and states the method of verification. 

6 EXPANDABILITY REQUIREMENTS 

Defines the expandability system requirements, uniquely numbers them and 

states the method of verification. 

7 SECURITY REQUIREMENTS 

Defines the security system requirements, uniquely numbers them and states the 

method of verification. 

8 DESIGN REQUIREMENTS 

Defines the design system requirements, uniquely numbers them and states the 


9 RELIABILITY, AVAILABILITY AND MAINTAINABILITY REQUIREMENTS 

Defines the reliability, availability and maintainability system requirements, 

uniquely numbers them and states the method of verification. 

10 TESTING REQUIREMENTS 

Defines the testing system requirements, uniquely numbers them and states the 


11 SAFETY REQUIREMENTS 

Defines the safety system requirements, uniquely numbers them and states the 


GLOSSARY 

This defines any acronyms used through this document. 

1.3 Applicable and Referenced Documents 

The following is a list of documents with a direct bearing on the content of this report. 

Where referenced in the text, these are identified as RD.n, where 'n' is the number in the 

© 2004 SOC Page 10 of 193



list below: 


Issue F 

RD.1 

Medspiration Statement of Work. 

RD.2 

Medspiration User Requirements Document 

RD.3 The Recommended GHRSST-PP Processing Specification GDS Version 1 

revision 1.1, 7 th January, 2004 

1.4 Definitions of Terms 

The following terms have been used in this report with the meanings shown. 

Term 

Definition 

External Interface 

An interface external to the Medspiration system 

Internal Interface 

An interfaces contained entirely within the system e.g. 

inter-module interfaces. 

1.5 System Requirement Format 

Each SR has been identified with a unique identifier of the form: 

SR.[CLA.]MOD.NUM.V 

where: 

SR = System Requirement, 

CLA = Class of requirement (see Table 1-2 for definitions). This field is 

absent in the label for functional requirements. 

MOD = Functional Module or Class (see Table 1-1 for definitions), 

NUM = Requirement number and 

V = Version. Initially this is not required. However any subsequent 

versions are labelled A… Z. 

Note: the method of requirement validation is not included in the actual 

identifier, but rather separated by “/”. Validation methods include: T – 

Test, I – Inspection & A – Analysis. 

© 2004 SOC Page 11 of 193




Issue F 

The functional requirements are differentiated according to the module to which they 

refer. Table 1-1 shows the decomposition of the System into modules, and defines the 

SR reference which documents the module Sub-system Requirements. Requirements 

are also differentiated by class, as identified in Table 1-2. In this case the part of the 

system constrained by the requirement is also specified 

Table 1-1 – Functional requirements distinguished by Module 

MOD 

SYS 

ING 

QLC 

MRG 

CFD 

L2P 

CTR 

ARC 

L4A 

MDB 

DIS 

DDS 

Name of functional module 

System Level Requirements 

Ingestion of input SST and auxiliary data 

Quality check of ingested data 

Merging of auxiliary data 

Confidence derivation 

Level 2-P Processor 

System controller (Ifremer) 

Archive 

Level 4 analysis processor 

Match-up database processor 

Dissemination processor 

High Resolution Diagnostic data set 

© 2004 SOC Page 12 of 193



Table 1-2 Other classes of requirements 


Issue F 

CLA 

INT 

EXT 

PER 

EXP 

SEC 

DES 

REL 

TST 

SAF 

CFI 

Class of requirement 

Internal Interface requirement) 

External Interface requirement 

Performance requirement 

Expandability requirement 

Security requirement 

Design requirement 

Reliability, availability and maintainability requirement 

Testing requirement 

Safety requirement 

Customer furnished items 

© 2004 SOC Page 13 of 193




Issue F 

2. SYSTEM OVERVIEW 

2.1 System Context 

The purpose of the Medspiration sea surface temperature (SST) processing system is to 

fulfil the role of the European regional data assembly centre (RDAC) for the Global 

Ocean Data Assimilation Experiment (GODAE) High Resolution Sea Surface 

Temperature Pilot Project (GHRSST-PP). The primary aim of GHRSST-PP is to develop 

and operate an operational demonstration system that will deliver global coverage SST 

data products for the diverse needs of GODAE and the wider scientific community, at 

high resolution (better than 10 km and resolving the diurnal cycle) and within a short 

interval (~24 hours) from real-time acquisition. In parallel with RDACs serving other parts 

of the world, Medspiration will produce in near real time a new generation of SST data 

products for Europe, based on the combination of existing SST products from both 

infrared and microwave radiometers (nominally level 2 although some are level 3) already 

being generated and served by several different agencies. The ingested SST data are 

referred to generically as L2 SST inputs 

The function of the Medspiration processing system is threefold: 

• To generate specific combined SST products (described in 2.1.2) in near-real time 

and to serve them to the GDAC and to European operational ocean models. 

• To populate an off-line archive in which to curate them. 

• To provide a data product dissemination service for all types of users. 

2.1.1 The importance of SST definitions used in Medspiration 

In its search for accuracy and rigour in calibration when combining SST detected by 

different classes of instrument, the GHRSST-PP processing model [RD.1] has had to 

take into account the thermal structure of the near-surface layers of the ocean. Since this 

has significant consequences for a number of the data processing stages, it is 

appropriate to provide a brief explanation at this stage. Figure 2-1 illustrates 

schematically how temperature varies in the upper few metres of the water column. Five 

different expressions of SST are shown. 

• SSTint is the hypothetical concept of the temperature of the interfacial layer of water 

and air molecules at the sea surface. It is not measurable and not used in GHRSST- 

PP. 

• SSTskin is defined within GHRSST-PP as the radiometric temperature of the surface 

© 2004 SOC Page 14 of 193




Issue F 

measured by an infrared radiometer operating in the 10 – 12 µm waveband. 

Physically it represents the temperature of the water at a depth of approximately 10 – 

20 µm. 

• SSTsubskin represents the temperature at the base of the thermal skin layer. The 

thermal skin layer is a region less than 1 mm deep in which the convective exchange 

of heat by turbulent mixing is inhibited by the proximity of the sea surface, so that the 

net outward flow of heat through the surface creates a steep reduction of temperature 

towards the surface. Below the skin layer, turbulent processes ensure that the 

temperature is nearly uniform over a depth of at least a few centimetres. By 

definition within GHRSST-PP this corresponds to the SSTsubskin temperature. In 

practice SSTsubskin is assumed to be approximately equal to the radiometric 

temperature measured by a microwave radiometer operating in the 6-11 GHz 

frequency band, although the relationship is not exact or fully known. 

• SSTdepth is the generic term used to represent the temperature measured by a 

contact thermometer within the upper few metres of the water column and generally 

referred to as the “bulk” SST. If the water column below the skin layer is uniform 

(typically the case at night and when wind mixing is strong) then SSTdepth is the 

same as SSTsubskin, irrespective of the actual depth of the measurement (see 

Figure 2-1a). However, when daytime solar shortwave radiation penetrates to heat 

the water below the skin layer, and if wind mixing is weak, stable stratification 

develops in the upper few metres of the water column, in which the temperature 

increases towards the sea surface (apart from the cool skin layer which lies right at 

the surface - see Figure 2-1b). This phenomenon is called a diurnal thermocline. 

When it occurs a measurement of SSTdepth, made from a buoy or ship-mounted 

thermometer which does not precisely specify the sampling depth, is of limited value. 

A diurnal thermocline almost always collapses to a uniform temperature some time 

after sunset when surface cooling removes the excess heat. Under calm conditions, 

however, it may take several hours for the diurnal thermocline to decay entirely. 

• SSTfnd is defined within GHRSST-PP as the temperature at the base of the diurnal 

thermocline. It is so named because it represents the foundation temperature on 

which the diurnal thermocline develops during the day. SSTfnd changes only 

gradually along with the upper layer of the ocean, and by definition it is independent 

of skin SST fluctuations due to wind- and radiation-dependent diurnal stratification or 

skin layer response. It is therefore updated at intervals of 24 hrs. SSTfnd 

corresponds to the temperature of the upper mixed layer which is the part of the 

ocean represented by the top-most layer of grid cells in most numerical ocean 

© 2004 SOC Page 15 of 193




Issue F 

models. It is never observed directly by satellites, but it comes closest to being 

detected by a microwave radiometer which penetrates the skin, at dawn when the 

previous day’s diurnal stratification can be assumed to have decayed and 

SSTsubskin, SSTdepth and SSTfnd are equal. 

Figure 2-1 Schematic diagram showing (a) idealised night-time vertical temperature 

deviations from SSTfnd and (b) idealised day-time vertical temperature deviations 

from SSTfnd in the upper ocean. 

Although the distinctions between the different definitions of SST may seem arcane, they 

are very significant when uncertainties of temperature measurement less than 0.3ºC are 

being sought. 

2.1.2 Medspiration SST Products 

The Medspiration processing system (MPS) will adhere closely to the data processing 

model and product specifications defined by the GHRSST-PP [RD.1]. It will produce the 

following data products: 

• L2P SST products for the European RDAC area which spans from 70S to 90N (to the 

ice limit) and from 100W to 45E and contains the whole Atlantic and the adjacent 

European seas (see Figure 2-2). Parts of the Pacific Ocean within these limits are 

expressly excluded. L2P products consist of the L2 SST data in their native sampling 

grid as ingested, with the addition of a quantitative confidence value attached to 

every data point. The confidence value will be based on the sensor specific error 

© 2004 SOC Page 16 of 193




Issue F 

statistics (SSES) to be supplied by GHRSST-PP and ancillary data such as wind 

speed and solar radiation, which can influence the diurnal variability of SST. The 

L2P data will be provided in near-real time to the GHRSST-PP global data assembly 

centre (GDAC) and to selected operational users in Europe for assimilation into 

ocean forecasting models. They will also be archived and served widely to general 

European users. 

Figure 2-2 The GHRSST-PP EURDAC product grid domain (Note that the Pacific 

areas are not included) 

• Available in situ measurements of SST will be matched with coincident samples 

within the L2P SST data, in order to prepare records for delivery to the GHRSST-PP 

match-up data base (MDB). This is required by GHRSST-PP to determine the 

sensor specific error statistics (SSES) needed when assigning quality values for the 

L2P data. The geographical scope of the MDB records to be delivered is the same 

European area as defined for the L2P products. 

• A L4 SST product will be produced at ultra-high resolution (UHR) on a 2 × 2 km grid 

for the Mediterranean Sea (see Figure 2-3). Optimal interpolation (OI) techniques will 

be used to combine coincident L2P measures of SST from different types of sensor 

and to fill gaps where no observations are available. Whereas L2P data essentially 

represent the skin or sub-skin SST, the L4 SST product is defined to represent 

SSTfnd (as explained in 2.1.1) and is updated only once every 24 hr. Using 

GHRSST-provided parameterisations of the skin layer and diurnal thermocline 

thermal structure, L2P products will be converted to SSTfnd before applying OI. The 

© 2004 SOC Page 17 of 193




Issue F 

L4 product also contains an estimate of the skin temperature and its diurnal variation 

derived from the analysed SSTfnd. 

Figure 2-3 The Medspiration Mediterranean Sea product grid domain (30N to 46N 

and 6W to 36.5E at 2 km spatial resolution). 

• Entries to the GHRSST-PP diagnostic data set (DDS) will be compiled by extracting, 

and resampling onto a 0.01º grid, full resolution sub scenes for a set of predefined 

small areas (typically 2º × 2º) from every L2P SST and L4 dataset generated by the 

Medspiration processor. The DDS sites are defined by GHRSST-PP. The purpose 

of the DDS is to allow intercomparison of the characteristics of the SST derived from 

different sensor types, in order to facilitate the research needed to test and improve 

the data merging methods used in GHRSST-PP. 

2.2 Overall structure of the Medspiration Processing System 

Figure 2-4 outlines schematically the main processing tasks required to produce the four 

types of SST products described in 2.1.2. The figure shows the main classes of inputs 

and outputs, and assigns distinct processing stages to different boxes. The whole 

system is distributed across the facilities of three contractors, CMS, Ifremer and SOC, as 

indicated in the figure. 

The underlying data flow through the system is basically simple. Level 2 SST data 

products generated from different sensors and produced by the mission ground segment 

or agency responsible for each are obtained by Internet and ingested into the first main 

processing centre. This is hosted in CMS where use will be made of the fact that CMS is 

already an operational provider of processed AVHRR data, which is a key SST input 

stream for the L2P product. Consequently one of the major sources of input data will be 

provided internally. At the same time the CMS processing facility will ingest auxiliary 

satellite data, such as wind speed, needed for the quality assessment. The SSES, 

reference data fields and any other necessary information will be supplied by the 

© 2004 SOC Page 18 of 193




Issue F 

GHRSST-PP International project office (IPO) so that quality values can be assigned to 

each ingested data point, applying the rules set out by the GHRSST data processing 

plan, and the new L2P dataset can be generated with the quality flags attached. This 

completes the involvement of CMS. 

As soon as each L2P data set is generated in near real time the products are pushed to 

the core processing centre. This is at IFREMER, where use will also be made of existing 

operational capability in processing, archiving and distributing satellite data. The 

IFREMER computing facility will support a number of tasks. First is the onward 

dissemination of the L2P data to GHRSST and to any operational users requiring them. 

Second is the archiving of the L2P data. Third is the use of the L2P data in the 

production of the level four interpolated products, using an OI scheme configured to 

match the local variability statistics for the region in question. The resulting L4 products 

for the Mediterranean Sea will then be disseminated to users and also placed in the 

Medspiration archive. 

The L4 processor is required to accomplish two processes whose detailed specification 

by the user (GHRSST-PP) is still under review. These are the conversion of the L2P 

data from skin and subskin to foundation temperature, and the subsequent optimal 

interpolation that merges SST data from all sources to generate the L4 SST product. The 

system requirements for the L4 processor must be defined in such a way that there is no 

uncertainty attached to the design of the fundamental functional architecture, and that 

any remaining uncertainties in the user specification are confined to the content of 

configuration files. 

The fourth module in the IFREMER facility is the use of the L2P data to generate entries 

for the GHRSST-PP match-up data base (MDB). IFREMER is well placed to handle the 

extraction of satellite data from the L2P inputs that are collocated with in situ 

observations of SST to form the MDB records. That is because the focal point for the 

collection, processing, dissemination and archiving of many of Europe’s operational 

measurements of SST from buoys and other platforms is already based at IFREMER in 

the CORIOLIS project. 

© 2004 SOC Page 19 of 193




Issue F 

L2 SST data 

from several 

sensors 

Auxiliary 

data (wind, 

waves etc.) 

In situ 

SST data 

CMS 

Ingest input 

and apply 

quality control 

Generate L2P 

data products 

Sensor 

specific error 

statistics 

Reference 

data fields 

Generate 

MDB 

records 

L2P data 

Generate 

analysed SST 

L4 products 

MDB 

records 

IFREMER 


Final Archive 

L4 SSTfnd 

UHR 

Disseminate 

L2P data to 

GHRSST-PP 

GDAC & users 

Disseminate 

L4 UHR data 

to EU users 

GHRSST 

MDB 

Archive 

Extract DDS 

L2P granules 

SOC 

Extract DDS 

L4 granules 

L2P DDS 

granules 


DDS Archive 

L4 DDS 

UHR 

granules 

Figure 2-4 Flow diagram for data processing, showing the distribution between 

facilities. Note that the flow of AATSR data through SOC is omitted for simplicity. 

© 2004 SOC Page 20 of 193




Issue F 

The remaining task is the extraction of the diagnostic data sets (DDS) granules from 

every L2P and L4 dataset located in the EURDAC area of responsibility. This is the 

responsibility of SOC which will serve as a node for the GHRSST-PP DDS. Data will be 

regridded to a standard 0.01º grid base defined by the GDS. It will be archived and made 

accessible through a distributed oceanographic data system (DODS) server. The DDS is 

an important resource for the GHRSST-PP task of reviewing and improving its 

processing model. 

SOC has one other detailed operational role which is not marked on the high level Figure 

2-4. Medspiration has the task of obtaining the full resolution AATSR data for the DDS 

sites globally. SOC will download the globally complete near-real time AATSR SST 

product from Envisat as it is made available on the ESA server. The DDS sites will be 

stripped out for archive and the non-EUDAC sites will be provided for GHRSST-PP. At 

the same time the Mediterranean Sea and Atlantic Ocean data will also be extracted and 

gridded, for all orbits which overlap the EURDAC region. These will then be provided to 

CMS for ingestion into the L2P processor. 

2.3 Outline of the individual processes at each facility 

2.3.1 L2P processing at CMS 

Figure 3-1 shows the processing tasks that must be performed to generate the L2P 

products as defined by GHRSST-PP. 

Ingest 

The ingestion module must communicate with the diverse providers of the L2 SST data, 

ice, wind speed, aerosol optical depth (AOD) and surface solar irradiance (SSI) data. It 

must be scheduled regularly to download new data as they become available. A 

successful download results in the generation of a data set description (MMR-DSD) 

which is sent to the GHRSST-PP master metadata repository (MMR). A failed download 

triggers an error message to the data provider. 

Quality Check 

The data are given a gross quality check to confirm the integrity of the files, and pixel-bypixel 

quality tests to ensure that only SST data with quality above a minimum standard 

are entered into the system. The quality checks require regularly updated information 

about the status of particular SST sensors systems to be provided by GHRSST-PP and / 

or the data providers. The data sets are reformatted and renamed at this stage. They 

© 2004 SOC Page 21 of 193




Issue F 

will be extracted over the Medspiration EURDAC and UHR areas as appropriate. Data 

are not resampled and remain in their native grid throughout the L2P processing. Failure 

of the quality checks triggers a message to the provider and to GHRSST-PP.. 

Merging with ancillary data 

The SST datasets which successfully pass the quality checks are merged with 

corresponding ancillary data required for the subsequent L2P processing. This includes 

an estimate of the sea ice fraction, wind speed, aerosol optical depth and the SSI at the 

time and location of each SST sample. Wind speed is expected to come from NWP 

models if not produced simultaneously with the SST value. At the same time information 

on location, viewing angle and sun illumination angle are attached to each pixel, if not 

already in the data. 

Generate confidence data 

Confidence values are then generated for each pixel, based on the ancillary data now 

attached to the SST for each pixel. This requires a number of tests following a set of 

rules defined by GHRSST-PP. Two distinct pathways are followed, one for SST data 

obtained from infra red sensors and one for data from microwave radiometers. Within 

these paths all data follow the same set of tests, but these may be evaluated differently 

for different sensors, following criteria contained in configuration files to be supplied and 

updated by GHRSST-PP. The most complex of these tests are concerned with 

generating the microwave or infrared proximity confidence values (MPCV or IPCV) which 

depend on the spatial structure of the data, for example how far a pixel is away from the 

nearest ice or cloud (for infrared) or rain (for microwave). 

Generate L2P products 

An estimate of bias and standard deviation must be assigned to each pixel. These may 

be either derived from the data provider or based on GHRSST-PP sensor specific error 

statistics (SSES) using the IPCV or MPCV. In the last stage of processing at CMS all the 

additional data generated for each pixel by the foregoing processes are written into the 

final L2P data product, in netCDF format. The finished file is sent to the Medspiration 

archive in IFREMER, records are sent to the MMR and the successful completion is 

logged. 

2.3.2 Processing at IFREMER 

The overview of the whole Medspiration processing structure at IFREMER is outlined in 

© 2004 SOC Page 22 of 193




Issue F 

Figure 3-4. The Archive is at the core, receiving data input from CMS and providing the 

source of DDS data for SOC. The archive supplies data to the dissemination function. 

Periodically the L4 processor uses L2P data from the archive to generate L4 products 

which are entered into the archive. Periodically the match-up dataset processor 

operates, drawing L2P data from the archive and in situ data from the CORIOLIS facility 

at IFREMER to generate MDB records for GHRSST-PP. 

Archive 

The archive receives L2P data as soon as they are produced at CMS. It receives L4 data 

products generated at IFREMER by the L4 processor. It also receives ancillary datasets 

of wind speed fields and surface solar irradiance required for the diurnal variability 

module of the L4 processor. The archive may receive data that are too old to meet the 

operational timeliness requirements of GHRSST-PP. Data are registered when they 

enter the archive, MMR records are sent to GHRSST-PP, and the location and timing of 

each dataset is entered into a database to facilitate searching. The archive is partitioned 

between on-line and off-line storage, and daily back-ups are made. 

L4 UHR data production at IFREMER 

The L4 UHR data production is performed on a daily cycle. All the L2P and ancillary data 

acquired by sensors between 00:00 to 23:59 on day T, which is available in the archive at 

06:00 UTC on day T+1, is used to generate L4 product to be delivered by 11:59 on day 

T+1. The L4 processor has four modules as shown in Figure 3-6. 

The first identifies the measured SST data available for each location and selects 

according to quality criteria, defined in a configuration file. All the measured SST data 

correspond to skin or subskin observations. 

The second module estimates the diurnal variation (DV) of the difference between 

SSTskin and SSTfnd, or SSTsubskin and SSTfnd, making use of ancillary data contained 

within the L2P products, additional wind speed or SSI data if available, and any regional 

factors that are supplied in a configuration file. By this means every L2P SST 

measurement is converted to an estimate of SSTfnd. 

The third module applies an optimal interpolation (OI) process to all the selected data, 

now converted to estimates of SSTfnd, in order to produce an analysed, gridded field of 

SSTfnd. It also attaches error estimates to each pixel in the field. This forms the core of 

the L4 SST product. 

© 2004 SOC Page 23 of 193




Issue F 

The fourth module uses an appropriate DV model to estimate the SSTskin associated 

with each SSTfnd in the analysed field, evaluated every two hours through the 24 h 

period represented by the final L4 product. 

While the overall structure of the L4 processor is well defined, the detailed criteria and 

models used in each of the four models are not yet optimized by the user (GHRSST-PP). 

Indeed it is expected that experience with operating the processor is needed before the 

OI and DV models can be finally chosen. For this reason the L4 processor must be 

designed in a highly modular way, with the specifications of the internal functions of each 

module contained in configuration files. 

Match-up data records production at IFREMER 

The functions within the MDR production are shown in Figure 3-7. In situ measurements 

of SST are obtained form the CORIOLIS system in IFREMER. This provides a 

convenient single point access to data from a number of different networks of buos and 

other measurement platforms. In situ data can be expected to be up to several days old 

when they are finally made available by CORIOLIS. Therefore the MDR production cycle 

is operated periodically to find matches for all the in situ data that have come available 

since the previous run, irrespective of their actual age. 

The in situ data are matched with any available satellite data within prescribed spacetime 

overlap windows. A number of conditions are attached to the complexity of 

matching discrete point samples to spatially distributed satellite data, and these are 

contained in several system requirements. The MDR are then sent to the GHRSST-PP 

MDB. 

Dissemination of data from IFREMER 

IFREMER provides access to the archive of L2P and L4 products through the 

dissemination module. This provides three different services, an ftp push-pull server, a 

DODS server and a live access server (LAS). 

Control of Medspiration Processing at IFREMER 

Management of the various different Medspiration processing functions being carried out 

at IFREMER requires a controller to ensure that they operate smoothly. This gives rise to 

the requirements presented in 3.3.5. While many of these are not directly traceable to 

the user requirements documents, they are inherently implied by the need for an 

autonomously operating system. This system controller also acts as a central log for all 

© 2004 SOC Page 24 of 193




Issue F 

relevant error and operation messages provided by the various Medspiration systems 

wherever they are located. A selection of these log messages is then redirected to the 

GHRSST-PP central error log system. 

2.3.3 Processing at SOC 

Figure 3-10 shows the part of the Medspiration processing system located at SOC. 

There are two main tasks to be performed, handling the ingest of the AATSR L2 global 

data, and extracting the diagnostic data set (DDS) granules of data from the main 

Medspiration archive at IFREMER. 

AATSR Ingestion 

Medspiration has a responsibility to extract the DDS granules from the AATSR for the 

whole world. This is in contrast with all the other data in Medspiration which cover 

European and Atlantic waters only. For this reason, and also to expedite AATSR data 

exchange between Medspiration and the ESRIN server, SOC will operate a mirroring 

function for AATSR data. From the AATSR data downloaded from ESRIN in Envisat 

format, the global DDS sites will be extracted and converted to netCDF format. Also the 

full data coverage of the EURDAC area will be extracted to provide the L2 input to the 

ingestion module at CMS. To avoid duplication of effort, the pixel location, viewing angle 

and sun angle information that is provided at a few tie points will be interpolated and 

attached to each pixel before transmission to CMS. 

Diagnostic data set generation at SOC 

The DDS granule generation for all sensors other than AATSR extends only to the 

European area DDS sites. As soon as data are entered into the IFREMER server the 

DDS granules will be extracted and MMR records sent to GHRSST-PP. Since the 

GHRSST-PP DDS is a distributed dataset, relying on the RDACs to house the data, it is 

implicit in the provision of DDS granules to GHRSST-PP that Medspiration should 

establish a DDS archive for the European DDS sites. This will be located at SOC. 

Associated with the DDS archive is an obligation of dissemination, leading to a 

requirement to serve the DDS data freely to external users. 

© 2004 SOC Page 25 of 193




Issue F 

3. FUNCTIONAL REQUIREMENTS 

3.1 System Requirements 

3.1.1 General 

SR.SYS.0010/I Medspiration shall implement a finite demonstration service of GHRSST- 

PP products for the European area. 

SR.SYS.0015/I Medspiration shall demonstrate, and sustain for a 12 month period, an 

operational service able to ingest, process and disseminate large volumes of satellite 

data in near real time. 

SR.SYS.0020/I Within the scope set out by [RD-1], the Medspiration System shall 

conform to the GHRSST data processing specification (GDS) as defined in Version 1 

Revision 1. [RD-3] 

SR.SYS.0021/I If later versions of the GDM provided by the User contain significant 

differences from the version specified in SR.SYS.0010, those changes will be adopted by 

Medspiration only with the agreement of both the Contractor and the Customer. 

3.1.2 Input data 

SR.SYS.0030/I The system shall be capable of ingesting those level 2 SST, wind speed 

and surface solar irradiance (SSI) data products available in real time that are identified 

in 5.2.1, 5.2.2 and 5.2.3. 

SR.SYS.0040/I The system shall be capable of protecting the conditions of use (if any) 

imposed upon input data by the provider. 

3.1.3 Data products 

SR.SYS.0050/I Medspiration shall deliver GHRSST-PP L2P products for the Atlantic 

Ocean in near-real time (as defined by the GDS) to the GHRSST-PP GDAC and to 

selected operational users. 

SR.SYS.0051/I The Atlantic product shall encompass the area 70S to 90N (to the ice 

limit) and from 100W to 45E at a resolution of 1/12º (~10km) 

SR.SYS.0052/I The L2P products shall conform to the specification in [RD.1], [RD.2] and 

[RD.3] and detailed in 3.2.7 

© 2004 SOC Page 26 of 193




Issue F 

SR.SYS.0055/I For every L2P file that is generated, a L2P MMR_FR shall be created and 

registered under the appropriate MMR_DSD at the GHRSST-PP MMR system. 

SR.SYS.0060/I Medspiration shall be able to produce records for the GHRSST-PP 

match-up data base (MDB) of in situ measurements of SST coincident in space and time 

with L2P data for the European area. 

SR.SYS.0061/I The MDB products shall conform to the specification in [RD.1], [RD.2] 

and [RD.3] and detailed in 3.3.3 

SR.SYS.0070/I Medspiration shall be able to extract GHRSST-PP Diagnostic Data Set 

(DDS) granules [RD-4] for the European area. 

SR.SYS.0071/I The DDS shall conform to the specification in [RD.1], [RD.2] and [RD.3] 

and detailed in 3.4 

SR.SYS.0080/I Medspiration shall be capable of delivering L4 UHR products for the 

Mediterranean Sea in near-real time to selected operational users. 

SR.SYS.0081/I The Medspiration Mediterranean Sea product grid domain shall cover 

from 30N to 46N and from 6W to 36.5E at 2 km spatial resolution. 

SR.SYS.0082/I The system for generating L4 products shall be based on an optimal 

interpolation (OI) procedure that can be adapted to widely differencing conditions through 

the use of configuration files. 

SR.SYS.0083/I The L4 products shall conform to the specification in [RD.1], [RD.2] and 

[RD.3] and detailed in 3.3.2 

3.1.4 Archive and dissemination 

SR.SYS.0090/I Medspiration shall archive all L2P and L4 products in a static archive so 

that they can be available for any future reprocessing, and for the GHRSST-PP 

reanalysis project. 

SR.SYS.0100/I Medspiration shall provide a dissemination service for data products 

including the operational delivery of SST products to specific European operational users 

and to the GHRSST-PP GDAC. 

SR.SYS.0110/I Medspiration shall provide access to all its data products as an ftp push 

service for registered clients and ftp pull service for all users. 

© 2004 SOC Page 27 of 193




Issue F 

SR.SYS.0120/I Medspiration shall conduct an evaluation of data products and service by 

solicited user feedback including a proper validation of SST data products. 

3.1.5 Overall system structure 

SR.SYS.2010/I There shall be a processing facility at CMS that will interface with the L2 

providers to ingest the required input SST products and auxiliary files required for 

Medspiration (detailed in 3.2), that will produce quality values for each SST data point, 

and will append these to produce L2P products 

SR.SYS.2020/I L2P products generated at CMS shall be served immediately to the 

processing facility at Ifremer 

SR.SYS.2030/I There shall be a UHR/L4 product generation system at IFREMER that will 

produce UHR SSTfnd interpolated grids. 

The detailed requirements are set out in 3.3.2. 

SR.SYS.2040/I There shall be an archiving system at Ifremer for all L2P, UHR/L4 

products. 

The requirements for this are detailed in 3.3.1. 

SR.SYS.2050/I There shall be a dissemination system at IFREMER that will provide 

access to L2P and UHR/L4 products for GHRSST and Medspiration users 

The detailed requirements are set out in 3.3.4. 

SR.SYS.2060/I There shall be a MDB records production system at IFREMER that will 

interface with the CORIOLIS in-situ data provider and deliver match-up database records 

to the GHRSST-PP MDB. 


SR.SYS.2070/I There shall be a system controller at IFREMER that controls, monitors 

and logs the processing flow and the data flow within Medspiration. 


SR.SYS.2080 There shall be a facility at SOC to generate the DDS using L2P and L4 

data from Ifremer. 

© 2004 SOC Page 28 of 193



The detailed requirements are presented in 3.4.2. 


Issue F 

SR.SYS.2081/I There shall be an archiving system in SOC for all HR-DDS granules 

generated by Medspiration. 

SR.SYS.2082/I There shall be a dissemination service at SOC for the Medspiration HR- 

DDS granules. 

SR.SYS.2090 The facility at SOC shall ingest global high resolution AATSR data from 

ESA and serve selected subsets to GHRSST-PP and to the L2P processor at CMS, as 

detailed in 3.4.1. 

© 2004 SOC Page 29 of 193




Issue F 

3.2 CMS Facility 

Data informations 

SCHEDULER 

query order 

PROVIDERS 

Query 

UPLOAD 

INGEST 

RAISE ERROR 

SEND MMR_DSD 

SST + ANC FILE 

RAISE ERROR 

CHECK 

PARAMETERS 

QUALITY 

CHECK 

ANC FILE 

CONFIG FILE 

IR 

CONFIDENCE 

SST FILE 

ANC FILES 

MERGING 

MERGED FILE 

CONFIG FILE 

MW 

CONFIDENCE 

CONFIDENCED FILE 

SSES DATA 

SSES 

ASSIGNATION 

L2P FILE 

L2P 

EVALUATION 

REPORT 

L2P FILE 

Figure 3-1 Schematic of the L2P processing system at CMS. 

SR.L2P.0010/I Data processing flow shall be designed to Ingest SST and auxiliary data 

sets. 

SR.L2P.0020/I Data processing flow shall be designed to control quality of input SST 

data sets. 

SR.L2P.0030/I Data processing flow shall be designed to assign auxiliary data (wind 

© 2004 SOC Page 30 of 193




Issue F 

speed, Surface Solar Irradiance (SSI) and, Aerosol Optical Depth (AOD)) to each SST 

measurement. 

SR.L2P.0040/I Data processing flow shall be designed to assign pixel confidence data to 

each SST measurement. 

SR.L2P.0050/I Data processing flow is designed to assign error estimates (called 

Sensor Specific Error Statistics, SSES) to each SST measurement. 

SR.L2P.0055/I Optional fields shall only be included prior to a cut-off time at which point 

the L2P data will be shipped ‘as is’. 

Comment: Optional fields are not described in GDS. 

SR.L2P.0060/I Data processing flow shall be designed to format a netCDF GHRSST-PP 

L2P output data file. 

SR.L2P.0070/I There shall be L2P products for every L2 satellite SST data file. 

Comment: 0 to 2 per L2 data file. 0 if rejected, 2 when ascending and descending orbits 

are included in the same data file. 

SR.L2P.0080/I L2P products shall have the spatial resolution of input data. 

SR.L2P.0090/I In the case of 1km input SST data streams, averaging of these data is 

permitted to provide data at a resolution of no greater than 1/12° latitude x longitude. 

3.2.1 Scheduler 

SR.ING.1010/I There shall be a scheduler that orders ingestion of the data streams. 

SR.ING.1020/I The scheduler shall be specifically programmed for each data stream, by 

a delay or a fixed time. 

3.2.2 Ingestion 

SR.ING.0010/I Ingestion of data streams shall establish operational access to data 

streams. 

SR.ING.0020/I If data are rejected by the GDS then an appropriate error message 

should be generated stating why the data have been rejected. 

SR.ING.0030/I Ingestion of data streams shall create a Master Metadata Repository 

© 2004 SOC Page 31 of 193




Issue F 

Data Set Description (MMR_DSD) record within the GHRSST-PP MMR for each data 

stream. 

SR.ING.0040/I Ingestion of data streams shall rename the data file by prefixing the 

RDAC identification code to the filename, as defined in Appendix 2 of [RD-3]. 

Comment: A time stamp may be used to avoid ambiguity in original naming. 

SR.ING.0050/I The MMR implementation and delivery of MMR_DSD shall be performed 

as defined in GDS appendix A6. 

SR.ING.0060/I The data file integrity should be evaluated by identifying a data delivery/a 

data format problem. 

SR.ING.0070/I The ingestion operation shall compute pixel measurement time. 

SR.ING.0080/I The time of the earliest SST measurement within this data set should be 

coded as a continuous time coordinate specified from 00:00:00 UTC January 1, 1981 

(start of the useful AVHRR SST data record). 

SR.ING.0090/I The time of SST measurement should be coded as the deviation in 

minutes from the time of the earliest SST measurement. 

SR.ING.0100/I In case of bad data file integrity, a dialog with the data provider shall be 

initiated, by sending error message, to establish a solution as soon as possible. 

SR.ING.0110/I Ingestion must evaluate the timeliness of each data file. 

SR.ING.0120/I The MMR_DSD records contains the data provider contact details and 

point of contact for error reports. 

SR.ING.0130/I L2 data will be extracted over the EURDAC and MEDSPIRATION UHR 

areas, as appropriate. 

3.2.3 Quality Check 

SR.QLC.0010/I Generation of L2P shall determine if SST data are suitable for further use 

in the GDS. If not inform the data provider and generate an error message for the 

GHRSST-PP ERRLOG explaining why these data have not been used in the GDS. 

SR.QLC.0020/I A configuration file, that will be revised as required, is used to store all 

QC parameter limits and thresholds (see SR.EXT.ING.0040). 

© 2004 SOC Page 32 of 193




Issue F 

SR.QLC.0030/I For each data stream controlled, a rejection rate shall be compute. 

SR.QLC.0035/I Rejection rate above a threshold will lead to rejection of the file. 

SR.QLC.0040/I A data rejected shall be replaced by a missing value depending on the 

data format. 

SR.QLC.0045/I Each input data file is assessed pixel by pixel, using gross error checking 

rules. 

SR.QLC.0050/I If an input SST data stream includes information that indicates that a 

pixel value is cosmetic rather than measured, these data should be rejected from the L2P 

data file. 

SR.QLC.0060/I If an input SST pixel data value or associated confidence data indicate 

the pixel to be cloudy, these data should be rejected from the L2P data file. 

SR.QLC.0065/I If a (microwave) measurement is identified as rain contaminated in the 

native data input file, this measurement should not be included in a L2P data file. 

SR.QLC.0070/I A valid SST observation must lie within a temperature range of 

LowSSTLimit < SST < HighSSTLimit. If the pixel SST value is out of these limits, the 

observation must be rejected from the final L2P data file. 

SR.QLC.0080/I The difference DT_min between the pixel SST value (SSTobs) and the 

reference SST field (derived as a 10 day coldest climatology from Pathfinder SST data 

products) shall be computed and inserted in the L2P confidence data record. 

SR.QLC.0090/I A valid wind speed observation must lie within a wind speed range of 0 < 

u < HighWindSpeed. Wind speed values that fall outside this range are considered 

erroneous and should not be used within the GDS. 

SR.QLC.0100/I A valid 6 hourly integrated SSI observation/forecast must lie within a SSI 

range of 0 < SSI < HighSSIValue. SSI values that fall outside this range should not be 

used within the GDS. 

SR.QLC.0110/I A valid AOD observation/estimate must lie within a range of 

LowAODLimit 

considered erroneous and should not be used within the GDS. 

SR.QLC.0120/I LowSSTLimit, HighSSTLimit, HighWindSpeed, HighSSIValue, 

© 2004 SOC Page 33 of 193




Issue F 

LowAODLimit, HighAODLimit and the corresponding maximum rejection rates will be set 

in a configuration file. 

3.2.4 Merging auxiliary data with SST 

SR.MRG.0010/I Generation of L2P shall extract auxiliary data (wind speed, surface solar 

irradiance and aerosol optical depth) and collocate with SST data. 

SR.MRG.0020/I The merging of auxiliary data (L2P-PP) must consist of a common preprocessing 

pixel based operation for Infra-red and microwave data. 

SR.MRG.0030/I The merging operation shall assign a fractional sea ice value if required 

(if no previous fractional sea ice exist in the data file). 

SR.MRG.0040/I The merging operation shall assign a wind speed value. 

SR.MRG.0050/I The merging operation shall assign a surface solar irradiance (SSI) 

value. 

SR.MRG.0060/I The merging operation shall assign an Atmospheric Optical Depth (AOD) 

value if required (if no previous AOD exist in the data file). 

SR.MRG.0070/I If an input data set pixel fractional sea ice estimate exists, this should be 

used to set the FractionalSeaIce flag of the L2P confidence data record. 

SR.MRG.0080/I If an input data set pixel sea ice flag exists (i.e. indicating sea ice but not 

the fractional amount of coverage), this should be used to set the FractionalSeaIce flag of 

the L2P confidence data record to 100%. If the flag is a binary flag, a check should be 

made against the reference fractional sea Ice data set to determine if the pixel is likely to 

be 100% contaminated and the fraction reported by the reference data set should be set 

if it is < 100%. 

SR.MRG.0090/I If an input data set pixel sea ice flag does not exist, and the pixel is 

located in or close to a region that may be ice contaminated, the reference sea ice data 

sets (NISE) or auxiliary (AMSRE-ICE) or NWP (NWP-ICE) fractional sea ice field should 

be used to determine the value of the L2P confidence flag FractionalSeaIce. 

SR.MRG.0110/I The L2P confidence variable FractionalSeaIce_source shall be set to 

indicate the data source used to set FractionalSeaIce. The code values are defined in 

[RD-3] Table 2.1.3. 

© 2004 SOC Page 34 of 193




Issue F 

SR.MRG.0120/I If the SST input data set is derived from a microwave sensor and a sea 

ice flag is present in the data stream, bit 4 of the L2P confidence data variable 

MW_SST_flags should be set for this pixel. 

SR.MRG.0130/I A 10m surface wind speed value should be assigned to each SST 

measurement pixel. As a general rule for the GDS v1.0, only simultaneous wind speed 

measurements should be used otherwise NWP analyses should be used. 

SR.MRG.0150/I In the case of microwave SST measurements, the use of a simultaneous 

microwave 10m wind speed measurements obtained from the same instrument providing 

the SST measurement may be used. 

SR.MRG.0160/I In the absence of a simultaneous surface wind speed measurement, an 

NWP estimated 10m surface wind speed should be used to set the L2P confidence data 

variable Wspd_value. 

SR.MRG.0170/I The difference in time expressed in hours between the time of SST 

measurement and the time of wind speed measurement should be provided. 

SR.MRG.0180/I A 6 hourly integrated downwelling SSI measurement (e.g., derived from 

satellite measurements) should be assigned to each SST pixel. The SSI measurement 

nearest in space and time before the input pixel SST value should be used. 

SR.MRG.0190/I If no SSI measurement is available, a 6 hourly integrated SSI value 

derived from an NWP system (See Appendix A3) nearest in space and time to the SST 

measurement should be used instead. 

SR.MRG.0200/I The source of data used to set the L2P confidence data variable should 

be provided. Code values are defined in [RD-3] Table 2.1.5. 


measurement and the mean time of SSI measurement/data validity should be provided. 

SR.MRG.0220/I A L2P AOD measurement (e.g., derived from satellite measurements) 

should be assigned to each SST pixel value using the AOD_value L2P confidence data 

variable. The AOD measurement nearest in space and time to the input pixel SST value 

should be used. 

SR.MRG.0230/I If no AOD measurement is available, an AOD value derived from an 

NWP system or aerosol forecast nearest in space and time to the SST measurement 

should be used instead. 

© 2004 SOC Page 35 of 193




Issue F 

SR.MRG.0240/I The source of data used to set the L2P confidence data variable should 

be provided. Code values are defined in [RD-3] Table 2.1.6. 


measurement and the time of AOD observations/analysis should be provided. 

SR.MRG.0260/I If no AOD measurement is available, an AOD value derived from NWP 

nearest in space and time to the SST measurement should be used. 

Comment: There is no AOD estimates in NWP outputs for the time being. When NAAPS 

are available, it is suggested they are given priority over the AVHRR-AOD. 

3.2.5 Confidence value derivation 

SR.CFD.0010/I A “confidence value”, having a value spanning 0 (no data, measurement 

is sea ice) to 5 (highest confidence in the SST measurement), is derived for each pixel. 

Comment: In GDS, figure 2.2.1.4.1 is not consistent with table 2.2.1.4. A confidence 

value should identify a cloudy case. That would enlarge the range of confidence values 

from 0 to 6. 

SR.CFD.0020/I The confidence value is to be used when assigning appropriate bias and 

rms error estimate to each measurement. 

SR.CFD.0030/I Confidence data are extracted from native SST data streams if present 

and they are derived using auxiliary and reference data streams and sensor specific error 

statistics. 

Comment: We may adopt native bias and sdtdev, but not confidence value. There is a 

risk of inconsistency. It is suggested to admit also native confidence values (flagged as 

such, by a L2_native_confidence_value flag). 

SR.CFD.0050/I There shall be separate schemes to derive Proximity_Confidence values 

for infrared and microwave SST data streams. 

© 2004 SOC Page 36 of 193



3.2.5.1 Microwave sensor case 


Issue F 

MW 

SST 

(Input) 

contaminati 

on map 

sidelobe 

contaminated 

y 

raise flag 

raise flag 

y 

rain 

contaminated 

TSanal 

TSanal-SST > 

threshold 

n 

TMISST 12ms-1 

y 

raise flag 

LANDMSK 

calculate distance to 

rain (Drain), ice (Dice) 

and land (Dland) 

Use wsp , TMI flag 

and 

min(Drain,Dice,Dland) 

to determine MPCV 

MW SST 

(output) 

Figure 3-2 Schematic of procedure to set the microwave proximity confidence 

value (MPCV). 

As Figure 3-2 shows, several different pieces of information are needed to perform the 

tests leading to evaluate the MPCV which is to be added to the data quality information in 

the L2P products derived from microwave sensors. This is the basis for the following 

system requirements. 

© 2004 SOC Page 37 of 193




Issue F 

SR.CFD.0100/I Data in close proximity to rain, land, sea ice and at high wind speeds are 

flagged as suspect. 

SR.CFD.0110/I If a pixel is located within an area of known side lobe contamination as 

defined by sensor specific side lobe contamination maps, bit 0 of the L2P confidence 

data variable MW_SST_flags should be set. 

SR.CFD.0120/I If a side lobe contamination map is not available, any pixel within 

sidelobe_distance_threshold (specified in the L2P configuration file in km) from land 

should flagged as contaminated. 

Comment: A contamination map will be derived from the LPDAAC/LANDMASK at the 

mw SST field resolution till the appropriate map is made available by GHRSST. 

SR.CFD.0140/I If a pixel lies within a radius of relaxed_MW_rain_distance specified in 

km of a clearly flagged rain contaminated pixel, bit 1 of the L2P confidence data variable 

MW_SST_flags should be set. 

SR.CFD.0150/I If the difference between the most recent GHRSST-PP analysis SST and 

the potentially contaminated pixel is greater than relaxed_rain_threshold (K), the pixel 

should not be included in a L2P data file. 

Comment 1: A most recent analysis map will be derived from the CMS (Faugère eet al.) 

climatology until available from GHRSST. 

Comment 2: sidelobe_distance_threshold, relaxed_MW_rain_distance and 

relaxed_rain_threshold should be included in the configuration file. 

SR.CFD.0160/I If a TRMM TMI SST measurement value is less than 285K, bit 2 of the 

L2P confidence data variable MW_SST_flags should be set 

SR.CFD.0170/I If a microwave wind speed measurement contemporaneous with a 

microwave SST measurement is greater than 12 ms -1 , the wind flag which is the bit 3 of 

the L2P confidence data variable MW_SST_flags should be set. 

SR.CFD.0180/I If a contemporaneous microwave wind speed measurement is 

unavailable, the nearest NWP analysis in space and time to the SST measurement 

should be used to evaluate the wind flag defined above. 

SR.CFD.0190/I The distance (Dice) to the nearest Sea ice shall be computed. 

© 2004 SOC Page 38 of 193




Issue F 

SR.CFD.0200/I The distance to the nearest problem (Dpb=min(Dcont, Dice, Drain)) shall 

be computed 

SR.CFD.0210/I Derive MPCV value from Dpb and wspd on the scale shown in Table 3-1, 

using thresholds MPCV_wind1, MPCV_wind2 and MPCV_proximity. 

Table 3-1 Microwave proximity confidence value (MPCV) scale definitions. 

MPCV Value 

Description 

10 Unprocessed: Data that have not been classified (measurement indicates sea 

ice) 

11 Questionable: Data that are may be contaminated by land, rain, sea ice, RF 

interference, degraded due to uncertainty in seawater emissivity at higher 

wind speeds, and/or are below a low SST threshold. 

12 Acceptable: Data that are far from land, rain, sea ice, RF interference and are 

within a favourable wind speed regime. 

13 Diurnal: Data are far from any rain or land flags but are within a low wind 

speed regime where a cool skin or warm layer may influence the observed 

SST. 

SR.CFD.0220/I The threshold values MPVC_wind1, MPVC_wind2 and MPVC_proximity 

are in a configuration file. 

3.2.5.2 Infrared case 

SR.CFD.0300/I If an indication of sun-glint is provided with an input SST pixel value, this 

should be used to set the SunGlint flag of the corresponding L2P confidence data record. 

SR.CFD.0310/I If an indication of sun-glint is not provided with an input pixel value, an 

appropriate method should be used to set the SunGlint flag of the L2P confidence data 

record that is based on the geometry of sun and satellite position and surface roughness 

(e.g., Gardashov and Barla, 2001) 

© 2004 SOC Page 39 of 193




Issue F 

IR SST 

(Input) 

sunglint 

raise flag 

calculate distance to 

cloud (Dcloud) 

Use DT_min and 

Dcloud to calculate 

IPCV 

IPCV=6 

n 

upwelling 

map 

y 

Upwelling 

y 

n 

assign 

IPCV to 1 

(cloudy) 

IR SST 

(output) 

Figure 3-3 Procedure for determining infrared proximity confidence value (IPCV) 

The proximity confidence value for SST measurements derived from infrared sensors 

(IPCV) flags the likelihood of cloud contamination of pixels which have already passed 

the cloud screening of the system which generated the ingested L2 products. It is based 

(see Figure 3-3) on the proximity to known cloudy pixels, and on comparison with 

expected (reference) SST values, but also needs information about the likelihood of 

upwelling. The process of deriving it gives rise to the following system requirements. 

© 2004 SOC Page 40 of 193




Issue F 

SR.CFD.0320/I Infrared proximity confidence value (IPCV) must be determined on the 

scale given in Table 3-2. 

Comment: In GDS, figure 2.2.1.4.1 is not consistent with table 2.2.1.4. A confidence 

value should identify a cloudy case. 

Table 3-2 IPCV value definitions 

IPCV Value 

0 

Description 

Unprocessed: Data that have not been classified (measurement indicates sea 

ice) 

1 Erroneous cloudy. 

2 Bad: Data that are probably contaminated by cloud. 

3 Suspect: Data that may be contaminated by cloud. 

4 

5 

6 

Acceptable: Data that are reasonably distant from cloudy areas and in good 

agreement with the expected reference SST threshold. 

Excellent: Data that are far from any cloudy areas and in good agreement with 

the expected reference SST threshold. 

Cool skin: Data are far from any clouds but significantly cooler than the 

expected reference SST threshold. This could be isolated cloud, upwelling or 

other dynamical feature or a strong cool skin deviation. 

SR.CFD.0330/I The system shall calculate the distance to the nearest cloudy pixel 

Dcloud 

SR.CFD.0340/I Use Dcloud and DT_min to determine Infrared Proximity Confidence 

Values IPCV. Two threshold values are set by the GDS, IPCV_D1 and IPCV_D2, for 

each L2P data stream. The distance IPCV_D2 is set on the assumption that cloudy pixels 

beyond this distance do not influence the SST measurement. The distance IPCV_D1 is 

set assuming that cloudy pixels where IPCV_D1 < nearest_cloudy_pixel < IPCV_D2 have 

a reasonable probability of being cloud contaminated. Pixels within a distance less than 

IPCV_D1 from the nearest cloud flagged pixels are assumed to have a high probability of 

cloud contamination. 

SR.CFD.0350/I The second IPCV test uses the deviation from a minimum SST 

climatological value defined in the L2P confidence data record variable DT_min. Three 

© 2004 SOC Page 41 of 193




Issue F 

threshold values for DT_min will be set by the GDS L2P configuration file IPCVThresh1 - 

IPCVThresh3. 

SR.CFD.0360/I A static map of upwelling regions may be used to decide if a pixel is 

cloud contaminated in the case of IPCV value 6. Maps will be developed by RDAC as 

appropriate for each region of interest. 

Comment: No upwelling maps exists. Upwelling maps EUR/ATLUPW and 

EUR/MEDUPW): will be derived from the Landmask (LPDAAC/LANDMASK) at 10 km 

resolution over the Atlantic and 2 km resolution over the mediterranean. A coastal area 

will be defined as upwelling_distance (km) away from coastline, upwelling_distance 

should be distinct in the Atlantic and in the Mediterranean . 

SR.CFD.0370/I IR only: The values IPCV_D1, IPCV_D2, IPCVThres1, IPCVThres2, 

IPCVThres3 used in the above procedure are expected to vary for each sensor. These 

values are maintained by GHRSST-PP and stored in the L2P configuration file. (see 

SR.EXT.ING.0040) 

Comment: This implies the use of tables of values. 

3.2.6 SSES Assignation 

SR.L2P.6010/I If pixel bias error and standard deviation error statistics are provided by a 

data provider, these values may be assigned to the L2P bias and standard deviation 

variables respectively. In this case, the L2_native_bias and L2_native_sd flags of the 

corresponding L2P confidence data record should also be set as these error estimates 

are independent of GHRSST-PP methods. 

SR.L2P.6020/I If pixel bias error and standard deviation error statistics are not available 

for SST measurements, these values should be assigned the most recent SSES bias and 

sd values for each data stream and L2P confidence data record Proximity_Confidence 

value. In addition, the L2_native_bias and L2_native_sd. flags of the corresponding L2P 

confidence data record should be set to zero. 

3.2.7 L2P evaluation 

SR.L2P.7000 The L2P data will be assembled from the L2 SST, the ancillary data, the 

mean and sd, and the confidence values. Only those datasets with quality above a given 

threshold will be accepted. Files will be written in netCDF format. 

SR.L2P.7010/I The L2P evaluation shall build a report about the L2P data files 

© 2004 SOC Page 42 of 193




Issue F 

SR.L2P.7020/I The L2P evaluation report shall contain the rejection rates of the data 

sources used 

SR.L2P.7030/I The L2P evaluation report shall contain status of the confidence values 

calculation 

SR.L2P.7040/I The L2P evaluation report shall contain the list of the missing parameters 

3.3 Ifremer Facility 

EU 

GHRSST- 

L2P, UHR/L4 

L2P 

dissemination 

MDB records, 

MMR-FR 

L2P producer 

(CMS) 

L2P 

ancillary data 

L2P, UHR/L4 

System 

controller 

HR-DDS 

producer(SOC) 

L2P 

archiving 

UHR/L4 

L2P 

L2P 

ancillary data 

MDB records 

L4 

generation 

MDB records 

generation 

In situ 

In situ provider 

(CORIOLIS) 

Figure 3-4 Outline of the Medspiration processing structure at IFREMER 

© 2004 SOC Page 43 of 193



3.3.1 Archive 


Issue F 

archiving 

Reference data Online storage Offline storage backup 

Figure 3-5 The Medspiration archiving function at IFREMER 

SR.ARC.0010/I The archiving system shall ingest all valid L2P (received from CMS) and 

UHR/L4 products (generated at IFREMER). Data rejected at some stage of their 

processing or of their control shall not be archived. 

SR.ARC.0020/I Ancillary surface solar irradiance and wind speed fields (received from 

CMS) may also be archived if needed to compute the SSTskin to be included in the 

L4/UHR product. 

SR.ARC.0030/I L2P or UHR/L4 products received by the archiving system beyond the 

delivery time limits defined by the GHRSST-PP shall be registered anyway for users not 

constrained by real time needs. 

SR.ARC.0040/I L2P or UHR/L4 products shall be ingested in the archiving system as 

soon as they are generated by the related production system (or received, in case of a 

remote production system). 

3.3.1.1 Reference data 

SR.ARC.0110/I Each L2P and L4 data file ingested in the archiving system shall be 

referenced in a database (inventory). 

SR.ARC.0120/I Spatio-temporal characteristics of each Medspiration product registered 

to the archiving system shall be extracted and stored within a database to facilitate and 

make faster product search and restoration. 

3.3.1.2 Online storage 

SR.ARC.0210/I The archiving system shall provide online storage for the most recent 

© 2004 SOC Page 44 of 193




Issue F 

data. These storage capability shall be fully scalable depending on the available 

hardware and the occupation rate of each storage device. 

3.3.1.3 Offline storage 

SR.ARC.0310/I The archiving system shall provide an offline storage facility for historical 

data (data files removed from the online storage space). This offline storage shall rely on 

the mass storage facility available at IFREMER. 

SR.ARC.0320/T The archiving system shall move data files from the online storage 

space to the offline storage space on a selective basis, for instance when the occupation 

rate of the online storage space is getting critical. This operation shall be initiated by a 

human operator as a maintenance task. 

SR.ARC.0330/T The archiving system shall be able to restore any offline data to the 

online storage space in reasonable delays (less than a few hours). 

3.3.1.4 Backup 

SR.ARC.0410/I Changes in the online storage space (new or updated data files) shall be 

saved every night using the IFREMER backup facility. 

3.3.2 Generate L4 analysed products 

Select/collate L2P observations 

SSTskin or SSTsubskin 

Diurnal cycle estimation (DV) 

SSI 

Wind speed 

SSTfnd 

Optimal interpolation (OI) 

Analysed SSTfnd 

L4 products generation 

SSTfnd 

SSTskin 

Figure 3-6. The four functional sub-modules of the L4 processor 

© 2004 SOC Page 45 of 193




Issue F 

SR.L4A.0010/I The UHR/L4 product generation subsystem shall be operated only over 

the Mediterranean sea during the two years of Medspiration. 

SR.L4A.0015/I The L4 module shall be decomposed into 4 sub-modules: L2P 

collation/selection ; diurnal cycle estimation ; optimal interpolation ; products generation 

SR.L4A.0020/I The UHR/L4 product generation shall be triggered daily at the cut-off 

time (defined as day T + 1 at 6:00 UTC). A latency delay may be added to complete 

ongoing L2P data uploads from CMS to IFREMER. 

SR.L4A.0025/I The computation time necessary to generate the L4 UHR SST fnd shall be 

6 hours maximum. 

SR.L4A.0030/I The UHR/L4 product generation system shall take as inputs to the OI 

scheme all L2P data file covering day T available at the cut-off time, a L4 data processor 

configuration file and reference data files (ancillary data) 

SR.L4A.0035/I The configuration file will contain flags to activate the estimation of diurnal 

cycle, the parameters of the correlation function, parameters that characterise the 

analysis (time, grid, sensors selected, sensors bias and errors coming from SSES ) 

SR.L4A.0040/I The UHR/L4 product generation system shall take as additional inputs to 

the diurnal cycle computation ancillary surface solar irradiance and wind speed fields 

covering day T. 

SR.L4A.0050/I The UHR/L4 product grid shall be that specified in Table 2.4.7.3 of [RD- 

3] 

SR.L4A.0051/I The L4 processor shall provide error estimates for each analysed grid 

cell, 

SR.L4A.0052/I The L4 processor shall account for differences in spatial and temporal 

sampling characteristics of each data stream, 

SR.L4A.0053/I The L4 processor shall account for gaps in coverage due to the presence 

of cloud, rain or lack of data, 

SR.L4A.0054/I The L4 processor shall account for SST diurnal variability and retrieve an 

estimate of the subsurface temperature field (SSTfnd), 

© 2004 SOC Page 46 of 193




Issue F 

SR.L4A.0055/I The L4 processor shall provide a measure of diurnal variability of the skin 

deviation from SSTfnd within the data product time domain to accompany the SSTfnd 

estimate 

SR.L4A.0060/I The L2P data shall be selected/collated before the OI analysis 

The rules proposed for the collation of L2P data have to be more defined because they 

are completely correlated to the OI method. In particular, the rules proposed to collate the 

L2P data induce an averaging of them that is inconsistent with the formalism of the 

interpolation method. Consequently, the only collation possible will be into a 0.02° grid 

without any averaging. However, in most optimal analysis systems, the analysis itself will 

optimise the re-gridding of data although re-gridding prior to interpolation provides a more 

straightforward processing system (p 85 of the GDS, line410 of UR-IFREMER ). 

SR.L4A.0070/I The activation of the DV depends on the validation of the DV 

parameterisation in the Mediterranean sea that will be undertaken by the CNR team 

CNR will perform a study to verify the accuracy of the A Stuart-Menteth DV 

parameterisation in the Mediterranean sea. If results are satisfying, we will activate the 

DV parameterisation through the configuration file. 

SR.L4A.0080/I The L4A interpolation sub-module shall be based on the optimal 

interpolation scheme proposed by the GHRSST-PP (Reynolds et al., 2002, Guan and 

Kawamura, 2003) 

SR.L4A.0090/I OI scheme is expected to evolve as more experience is gained, therefore 

the L4 analysis system will be built in a modular manner 

SR.L4A.0095/I The regional parameters used by the OI scheme (correlation functions, 

spatial and temporal correlation radius) will come from the correlation study led by the 

CNR team in the frame of the Medspiration project. 

SR.L4A.0100/I The sub-module “products generation” will generate L4 SST fnd that 

contains SST fnd , 12 values of SST skin and associated errors. The SST skin values will be 

filled if the DV parameterisation is activated. 

© 2004 SOC Page 47 of 193



3.3.3 Matchup Data Base 


Issue F 

MDB records 

generation 

Collect in situ 

data 

Colocate in situ 

with satellite 

data 

Generate MDB 

records 

Figure 3-7 The functions of the MDB records generation module at IFREMER 

SR.MDB.0010/I The MDB records generation shall be triggered on a periodic basis 

related to the delivery frequency of in situ data. They should be produced within the 24 

hours from when the in situ data are made available by the in-situ data provider. 

SR.MDB.0020/I The MDB records generation system shall take both in situ and satellite 

data as inputs. 

SR.MDB.0030/I The MDB records generation system shall take as input the relevant in 

situ data collected by the in situ data provider since their last delivery. It is admitted that 

due to delivery and quality control constraints, a minimum delay of 24 hours from 

acquisition is to be expected for in-situ data availability. However, all MDB records are 

admissible irrespective of their timeliness for use by the GHRSST-PP reanalysis project. 

Therefore all incoming in-situ data shall be ingested in the MDB records production 

system regardless of their age, in the limit of one month. 

This limitation of one month is introduced to avoid using historical L2P data which may 

not be available online anymore. Using offline data would add heavy and time consuming 

operations with respect of the expected amount of involved in situ data. 

SR.MDB.0040/I The MDB records generation system shall take as satellite input all the 

latest L2P products archived in the limit of one month of data. 

See comment above. 

SR.MDB.0050/I The MDB records shall contain in situ SST (and other associated oceanatmosphere 

measurements) that are matched to L2P satellite SST measurements 

according to specified time and space constraints (referred to as colocation criteria). 

© 2004 SOC Page 48 of 193




Issue F 

No MDB records shall be generated for the UHR/L4 products since they are not referred 

to as GHRSST-PP products and thus shall not appear in the MDB. 

3.3.3.1 Collecting the in-situ data 

SR.MDB.0110/I The main source of in situ observations used in this system will be those 

available from the GTS supplied through international in situ data centres (e.g., MEDS, 

CORIOLIS, FNMOC) at which QC procedures are used to filter out poor quality data. 

In the frame of MEDSPIRATION, the CORIOLIS data center will be considered as the 

only source of in-situ data. However, CORIOLIS is a gateway to GTS data and MEDS 

data. 

SR.MDB.0120/I The MDB shall be open to all other source of in situ observations that are 

deemed of sufficient quality by the Medspiration team. 

Taking advantage that the CORIOLIS data centre is located, funded and operated by 

IFREMER, the MEDSPIRATION team will rely on the CORIOLIS team for ingesting new 

in-situ data streams within its easily extendable database, before delivering them to the 

MDB records production system. Keeping a single interface for in-situ data will make it 

easier to maintain and expend the system. In its first month of operation, Medspiration 

may for instance benefit from the in situ data collected by MFSTEP that will be ingested 

in CORIOLIS database. 

SR.MDB.0130/I All in-situ data shall be quality controlled before being ingested within the 

MDB records production system, using local ocean/atmosphere knowledge and 

experience. The MDB records production system will use only quality-controlled data 

(uncontrolled data will be rejected). The Medspiration system will rely on the CORIOLIS 

data centre for quality control procedures. 

3.3.3.2 Colocating the in-situ and satellite data 

SR.MDB.0210/I The satellite pixel having the smallest deviation in both space and time 

from an in situ observation within the colocation criteria should be selected as a MDB 

record. 

It is not clearly defined within the GDS which in-situ observation should be selected for 

the match-up record when several observations match the space and time criteria. It is 

proposed to select the closest one in space (which means that the space criterion has 

priority over the time criterion) or in time if their distance to the satellite cell centre is the 

© 2004 SOC Page 49 of 193



same. 


Issue F 

SR.MDB.0220/I The colocation method will be the same for each satellite product 

regardless of their resolution. 

It is stated in the GDS that, for coarser resolution (typically 25 km), the mean of a 

transect of several measurements obtained within the grid cell will be preferred to a 

single point observation. This solution introduces a lot of complexity because of the 

ancillary parameters provided with the in-situ measurements (for instance ship speed or 

heading, location, sensor identifiers) which can’t be averaged and because in-situ 

observations may come from different sensors and platforms. In addition, a mean 

observation could be computed from both day-time or night-time measurements. It is 

proposed to use the same algorithm as for high resolution measurements. 

SR.MDB.0230/I The time and space constraints are stored in a configuration file 

(MDB_time_constraint and MDB_space_contraint variables) for each L2P dataset. 

These colocation criteria shall be defined and maintained by the GHRSST-PP 

International Project Office. 

SR.MDB.0240/I The space/time criteria shall be set as the largest as acceptable 

(typically 25km in space and 6 hours in time). These criteria may be strengthened when 

filtering out the data from the MDB at GDAC, for instance to take into account the 

day/night asymmetry, but not when generating the MDB records at RDAC in order to add 

more flexibility and extendibility. 

It is stated in the GDS that “because of the day-night asymmetry in the growth and decay 

of the diurnal thermocline, more stringent conditions for acceptable time intervals may be 

required during the day than at night. For these and ambiguous cases, such as close to 

the terminator, the smallest spatial separation and shortest possible time interval should 

be sought”. It is not clear if this should be taken into account for the MDB records 

generation or when retrieving the data records from the database, which allows more 

flexibility (easier to generate the most complete MDB dataset and then filter out when 

extracting the data). Moreover the definition and the computation of the day/night 

threshold need to be provided in order to ensure consistency through RDACs. 

SR.MDB.0250/I An in-situ measurement shall be colocated to only one pixel of each L2P 

dataset. 

This is a refinement from the GDS which states that only one instance of each in situ 

observation for each individual satellite sensor should occur within the MDB which is 

© 2004 SOC Page 50 of 193




Issue F 

ambiguous since some sensor measurements may exist in different datasets with various 

resolutions (eg AVHRR). 

SR.MDB.0260/I A satellite pixel shall be colocated to only one in situ measurement from 

a single in situ data file. However, the scope of the colocation process for in situ data is 

limited to the data files : a satellite pixel may be colocated again with another in situ 

measurement delivered by CORIOLIS a few days or weeks later in another datafile 

There is no user requirements addressing this issue. Trying to avoid a satellite pixel 

being colocated with more than one in situ measurement would be complex to implement 

while addressing very rare cases. In particular it would almost imply building a MDB to 

filter out these cases which is not the aim of this system. If this issue is considered as 

critical, it should be adressed by the GDAC MDB when ingesting its records. 

SR.MDB.0270/I The targeted in situ measurement for the MDB records production are 

the SST1m data derived from drifting/moored buoy, ship and float (Argo) observations. 

For some sensors, the SST1m may not be accessible : it is thus proposed to catch the 

closest to the 1m depth in the limits of [-5m, 0m]. 

It is stated in the GDS that the targeted in situ measurement for the MDB records 

production are the SST1m data derived from drifting/moored buoy and ship observations. 

After meeting with the CORIOLIS staff, it appears this may be too restrictive since very 

few ship observations are available beyond –5m. Relaxing this constraint allows to select 

more data and also to capture the floats data. 

3.3.3.3 Generating the MDB records 

SR.MDB.0310/I All L2P confidence data each pixel stored in a MDB record must 

accompany the extracted data. 

SR.MDB.0320/I For each L2P pixel matched to an in-situ measurement, a n x n array of 

L2P data shall be extracted centred on this pixel and provided within the related MDB 

record. 

SR.MDB.0330/I All in situ parameters available in addition to the SST measurement 

should be included in the MDB record. 

Upgrade of the MDB format (DTD) may be necessary. Additional parameters will be 

submitted to GHRSST-PP through ESA in order to keep consistency (variable names, 

units,…). 

© 2004 SOC Page 51 of 193



3.3.4 Dissemination 


Issue F 

dissemination 

ftp push/pull DODS Live Access 

Server 

Figure 3-8. The dissemination module at IFREMER 

SR.DIS.0010/I The dissemination service shall provide free access to L2P and L4/UHR 

products. 

SR.DIS.0020/I The dissemination service shall give access to the L2P and L4/UHR 

products as soon as they have been ingested by the archiving system. 

SR.DIS.0030/I The dissemination service should aim to minimize the volume of 

transferred data, using appropriate means such as compression or subsetting. 

3.3.4.1 Ftp push/pull 

SR.DIS.0110/I The dissemination system shall provide near real time ftp push service for 

L2P and L4/UHR products to registered users (including GHRSST-PP for the L2P). 

SR.DIS.0120/I The dissemination system shall provide near real time ftp pull service to 

public users for L2P and L4/UHR products. 

3.3.4.2 DODS 

SR.DIS.0210/I The dissemination service shall provide DODS access to L2P and 

UHR/L4 data. 

3.3.4.3 Live Access Server 

SR.DIS.0310/I The dissemination service shall provide LAS (Live Access Server) access 

to UHR/L4 data. 

© 2004 SOC Page 52 of 193



3.3.5 System controller at Ifremer 


Issue F 


controller 

operation log 

system 

Control 

processing flow 

Control 

data flow 


monitoring 

Synchronize 

with 

GHRSST-PP 

Trigger 

Chain 

Exchange 

data 

Exchange 

MMR-FR 

Exchange 

error messages 

Figure 3-9. The controller for the Medspiration processor at IFREMER 

3.3.5.1 Dataflow control 

SR.CTR.0110/I The system controller shall ensure that all data and messages are 

correctly transmitted and received within the overall system. 

The Medspiration team recommends that the requirements listed below are applied on 

each site receiving or transmitting data. We also suggest these requirements to be 

extended at the GHRSST-PP level to ensure overall consistency of the global system. 

SR.CTR.0120/I The system shall control the integrity of all binary data received from a 

remote site using appropriate error control code (md5 or crc checksum) when available. 

An error control code shall be associated with all the L2P files sent from CMS to 

IFREMER. 

SR.CTR.0130/I The system shall control the validity of each XML formatted message 

(Operation or error log entry) received from a remote site. The DTD associated with each 

XML file will be used to validate the messages. 

This requirement may be extended at GHRSST-PP level to MDB and MMR messages. 

SR.CTR.0140/I Retransmission shall be requested to the sender for each rejected 

datafile or message on integrity or format control. 

SR.CTR.0150/I Acknowledgement shall be transmitted by the receiver to the sender for 

data files. 

This may be very useful for the sender to clean its sending spooler. 

© 2004 SOC Page 53 of 193




Issue F 

SR.CTR.0160/I Corrupted L2P files by the receiver shall be deleted with all their related 

information (error control code) before retransmission is requested. 

SR.CTR.0170/I When transmitting files by ftp, the error control code (md5 or crc 

checksum, having a fixed size) delivered with a datafile shall be used as a flag by the 

sender indicating the transfer is completed. The receiver shall assume the transmission is 

completed when reading the related error control code. Consequently, the error control 

codes shall be sent after the related data file transmission is completed. 

SR.CTR.0180/I The selected on-the-shelf ftp tools used by Medspiration shall feature 

resume facilities in order to optimize the bandwidth and the delivery time in case of 

interrupted transmission. 

SR.CTR.0190/I On-the-shelf dissemination systems such as DODS or Live Access 

Server are out of the scope of these requirements. 

3.3.5.2 Processing flow control 

SR.CTR.0210/I The system controller shall trigger, schedule and sequence all the 

processes runned on its own site and generate appropriate error and operation 

messages. 

SR.CTR.0220/I The scope of the processing flow control shall be limited to IFREMER site 

processing. Other production sites (CMS, SOC) shall rely on their own local practices 

and facilities for the control and the sequencing of their processes. 

3.3.5.3 Triggering the processing 

SR.CTR.0230/I The system controller shall provide a poll mechanism to trigger the 

relevant processing – referred to as ‘data-driven tasks’ - on new incoming data. 

Data-driven tasks include : 

• L2P archiving 

• L2P delivery (ftp push) to operational users (GHRSST or EU) 

• L4 delivery (ftp push) to operational users (EU) 

• MMR generation and delivery 

SR.CTR.0240/I The system controller shall provide a scheduling mechanism to trigger 

processing on a periodic basis, referred to as ‘time driven’ tasks. 

© 2004 SOC Page 54 of 193



Time-driven tasks include : 

• UHR/L4 product generation 


Issue F 

• MDB records generation 

• Backup operations 

SR.CTR.0250/I Some system operation shall be manually triggered by the system 

operators. 

This addresses mainly the offline storage or restoration of the historical data. 

3.3.5.4 Chaining the processes 

SR.CTR.0260/I The system controller shall appropriately chain the processes when 

sequencing is required. 

3.3.5.5 Operation log system 

SR.CTR.0310/I The system controller shall centralize, in a system log, all relevant 

operations and errors occurring within the Medspiration system (SOC, IFREMER, CMS). 

SR.CTR.0320/I The log information shall be archived in an appropriate way to extract 

relevant operation statistics about the Medspiration system operations. These statistics 

shall then be used in the monthly operation reports delivered to ESA. 

3.3.5.6 System monitoring 

SR.CTR.0410/I The system controller shall report to the staff in charge of the system 

operations all relevant events or error occurring within the Medspiration system through 

a graphical user interface. 

SR.CTR.0420/I The log information shall be easily readable by the technicians in charge 

of the system monitoring. 

SR.CTR.0430/I Failures requiring human intervention shall be highlighted. 

3.3.5.7 Synchronization with GHRSST-PP 

SR.CTR.0510/I The system controller shall ensure all synchronization procedures with 

© 2004 SOC Page 55 of 193




Issue F 

the external sites within Medspiration or GHRSST-PP systems, GHRSST-PP entities, 

master metadata repository and error log system. 

SR.CTR.0520/I The IFREMER system controller shall also ensure the control and the 

sequencing of all the processes run on its own site. Other production sites (CMS, SOC) 

shall rely on their own local practices and facilities for the control and the sequencing of 

their processes. 

3.3.5.8 Exchange MMR 

SR.CTR.0530/I A MMR-FR file shall be delivered to the Master Metadata repository for 

each L2P and DDS data registered to the archiving system. This will inform the 

GHRSST-PP that the related data file is available. No MMR-FR will be generated nor 

delivered for the UHR/L4 products. 

This restriction comes from the SoW which does not state the GHRSST-PP as a client of 

the Medspiration UHR/L4 products. Therefore, delivering related MDB records, MMR-FR 

or HR-DDS is considered as meaningless in the frame of the GHRSST-PP. 

SR.CTR.0540/I Each archiving site (IFREMER for L2P, SOC for HR-DDS) shall be 

responsible for generating and sending the MMR-FR files related to the data files it is in 

charge of. The MMR-FR shall be delivered to the MMR as soon as they have been 

successfully ingested in the archiving system. 

3.3.5.9 Exchange error messages 

SR.CTR.0550/I The system controller shall format and deliver all specified error 

messages to the GHRSST-PP error log (ERRLOG) system. 

A tentative list of relevant messages is detailed in GDS Annex 7. This list is likely to 

evolve : as Medspiration project progresses, error or operation messages of interest will 

be submitted to be included or deprecated. The system shall thus be flexible enough to 

accommodate new messages. 

SR.CTR.0560/I The system controller shall ingest all GHRSST-PP error messages sent 

to Medspiration. The ingestion of these messages shall be reflected in the operation log 

subsystem and in the monitoring subsystem. 

No specific action from RDACs is requested by the GDS when receiving an error 

message (only one message specified so far : “MDB data rejected from MDB”). 

© 2004 SOC Page 56 of 193



3.3.5.10 Exchange data 


Issue F 

SR.CTR.0570/I The system shall deliver the L2P products to the GDAC as soon as they 

have been archived. 

SR.CTR.0580/I The system shall deliver the MDB records to the GDAC MDB as soon as 

they have been generated. 

3.4 SOC Facility 

ftpops.pde.envisat.esa.int 

ATS_NR_2P 

ATS_NR__2P 

Mirror 

IFREMER 

ATS NR 2P 

L2P/L4UHR 

GHRSST- 

PP 

ATS_NR_2P 

MMR_FR 

GDAC 

netCDF 

netCDF 

Generation 

& extraction 

netCDF 

HR-DDS & Metadata 

Generation 

CMS 

HR-DDS 

HR-DDS Dissemination 

HR-DDS 

HR-DDS 

HR-DDS 


Controller 

ERRLOG 

GHRSST- 

PP 

User 

Figure 3-10. Schematic of the Medspiration processing at SOC 

SR.DDS.1000/I There shall be a system controller at SOC that monitors and logs all 

events within the HR-DDS and AATSR systems 

3.4.1 AATSR Ingestion 

SR.DDS.1010/I All AATSR ATS_NR__2P products made available by ESA on the server 

ftp-ops.pde.envisat.esa.int shall be made securely available via a file transfer protocol at 

SOC for the GHRSST-PP. 

© 2004 SOC Page 57 of 193




Issue F 

SR.DDS.1030/I All AATSR ATS_NR__2P products made available to Medspiration shall 

be converted into GHRSST-PP netCDF format. 

SR.DDS.1040/I There shall be an extraction process to select data from the AATSR 

netCDF format which corresponds to the Atlantic region. 

SR.DDS.1050/I An interpolated geographic tie point, satellite elevation and satellite 

azimuth shall be provided for each pixel in the netCDF format AATSR data. 

SR.DDS.1060/I Only records of Combined View SST will be included in the netCDF files 

from the Distributed Product MDS. 

3.4.2 HR-DDS Generation 

SR.DDS.0010/I The HR-DDS processor shall consist of an AATSR HR-DDS Processor, 

and L2P HR-DDS Processor, and L4UHR HR-DDS Processor and an HR-DDS Metadata 

Processor 

SR.DDS.0020/I All Medspiration netCDF AATSR data elements corresponding to 

GHRSST-PP HR-DDS sites (global) shall be resampled to HR-DDS data format and 

ingested into the HR-DDS system. 

SR.DDS.0030/I All L2P data elements corresponding to a Medspiration Area HR-DDS 

site shall be resampled to HR-DDS data format by the L2P HR-DDS Processor and 

ingested into the HR-DDS system. 

SR.DDS.0040/I All UHRL4 data elements corresponding to a Medspiration 

Mediterranean Area HR-DDS site shall be resampled to HR-DDS data format by the 

L4UHR HR-DDS Processor and ingested into the HR-DDS system. 

SR.DDS.0050/I There shall be an HR-DDS Parser and Metadata Processor to ensure 

quality of HR-DDS products. 

SR.DDS.0060/I A MMR_DSR XML file shall be generated for each data type and sent to 

GDAC. 

SR.DDS.0070/I A MMR_FR shall be created for each L2P derived HR-DDS file and sent 

to GDAC. 

SR.DDS.0090/I The HR-DDS data grid shall be defined as in Table 3-3. 

SR.DDS.0091/I The HR-DDS system shall be a satellite only archive. 

© 2004 SOC Page 58 of 193




Issue F 

Table 3-3. Definition of the DDS grid 

Boundary 

Projection 

Reference Ellipsoid 

Grid Cell Size 

Grid Cell Reference Point 

Multiple to be defined by GHRSST-PP 

Cylindrical / Rectangular Equidistant 

WGS84 

½ UHR L4 grid size 

Centre Point 

3.4.3 HR-DDS Archiving 

SR.DDS.0110/I There shall be an archiving facility at SOC for the storage of 

Medspiration HR-DDS data. 

SR.DDS.0120/I All Medspiration HR-DDS data shall be stored in GHRSST-PP HR-DDS 

netCDF format. 

3.4.4 HR-DDS Dissemination 

SR.DDS.0140/I All Medspiration HR-DDS data shall be made publicly available via a 

DODS server. 

3.4.5 HR-DDS Controller 

SR.DDS.0170/I There shall be an HR-DDS system controller. 

SR.DDS.0180/I The HR-DDS system controller shall monitor and log all activities of the 

AATSR mirroring system and the HR-DDS system. 

SR.DDS.0190/I The HR-DDS system controller shall report all ERRLOG activity to GDAC 

and Medspiration central log at IFREMER. 

© 2004 SOC Page 59 of 193




Issue F 

4. INTERFACE REQUIREMENTS 

4.1 Internal 

4.1.1 Interfaces within the CMS processing facility 

SR.INT.L2P.0010/I 

each data stream. 

Data information file shall contain scheduling information for 

SR.INT.L2P.0020/I The scheduler module shall be interfaced to the ingestion 

module to order the query of data streams. 

SR.INT.L2P.0030/I The ingestion module shall be interfaced with the system controller, 

delivering error message. 

SR.INT.L2P.0040/I The ingestion module shall be interfaced with the quality check 

module to control every data file. 

SR.INT.L2P.0050/I A configuration file shall contain all the parameters needed by 

the quality check module for each data stream. 

SR.INT.L2P.0060/I The quality check module shall be interfaced with the system 

controller, delivering error message. 

SR.INT.L2P.0070/I The quality check module shall be interfaced with the merging 

module to complete necessary fields before the confidence calculation. 

SR.INT.L2P.0080/I A configuration file shall contain all the parameters needed by 

the confidence calculation module for each data stream. 

SR.INT.L2P.0090/I 

merging module. 

The confidence calculation module shall be interfaced with the 

SR.INT.L2P.0100/I The SSES assignation module shall be interface with the 

confidence calculation module 

4.1.2 Interfaces between L2P production and archiving systems 

SR.INT.ARC.0010/I The L2P production system shall be interfaced with the archiving 

system, delivering by ftp push and registering the L2P data files to the archive. 

© 2004 SOC Page 60 of 193




Issue F 

SR.INT.ARC.0020/I The L2P products shall be delivered to IFREMER by CMS with 

respect to the protocol requirements defined for the dataflow control subsystem of the 

system controller (refer to section 1.4.1). 

SR.INT.ARC.0030/I The L2P products delivered by CMS shall be formatted as specified 

in annex 1 (“L2P product format”). 

The L2P files are sent in their final (GHRSST-PP) format. It is assumed by IFREMER that 

they are complete and well formatted when successfully received. 

4.1.3 Interfaces between archiving and dissemination systems 

SR.INT.DIS.0010/I The ftp push/pull system shall be interfaced with the archiving system 

to access online L2P and L4 products. 

SR.INT.DIS.0020/I The DODS server shall be interfaced with the archiving system to 

access online L2P and L4 products. This interface is described in DODS user manual 

v1.11 (http://www.unidata.ucar.edu/packages/dods/user/guide-html/). 

SR.INT.DIS.0030/I The Live Access Server (LAS) shall be interfaced with the archiving 

system to access online L4 products. This interface is LAS documentation 

(http://ferret.pmel.noaa.gov/Ferret/LAS/Documentation/). 

4.1.4 Interfaces between archiving and MDB generation systems 

SR.INT.MDB.0010/I The MDB records production system shall be interfaced with the 

archiving system, retrieving the L2P data files needed for the generation of the MDB 

records. 

4.1.5 Interfaces between archiving and L4 generation system 

SR.INT.L4A.0010/I The UHR/L4 production system shall be interfaced with the archiving 

system, retrieving the L2P data files needed for the generation of the UHR/L4 products 

and delivering the generated UHR/L4 products. 

SR.INT.L4A.0020/I This data exchange shall aim minimizing useless data copy, using 

direct access to data storage disks, taking advantage of the colocation of both systems 

on IFREMER local network. 

SR.INT.L4A.0030/I It is the responsibility of the archiving system to provide a list of all 

L2P and ancillary products eligible for the UHR/L4 product generation, depending on 

© 2004 SOC Page 61 of 193



what is available at the cut-off time. 


Issue F 

SR.INT.L4A.0040/I The UHR/L4 products shall be formatted as netcdf files with respect 

to the format provided in Annex 2 (“L4 product format”). 

4.1.6 Interfaces within the archiving system 

SR.INT.ARC.0510/I The archiving system shall use the existing offline mass storage 

subsystem existing at CERSAT to archive the historical data stored online. The interface 

of this subsystem is described in ‘Document de specification Logiciel de l’Atelier 

d’Archivage’ (ref : WCOL-DSL-A-03-CS). This interface may need to be updated to take 

into account Medspiration specificities. 

SR.INT.ARC.0520/I The online storage system of the archiving system shall be 

accessible for the offline mass storage system to restore historical data. 

SR.INT.ARC.0530/I The archiving system may use the existing referencing subsystem 

existing at CERSAT. The interface of this subsystem is described in ‘Document de 

specification Logiciel de l’Atelier Reception’ (ref : WCOL-DSL-R-02-CS). This interface 

may need to be updated to take into account Medspiration specificities. 

SR.INT.ARC.0540/I The online space storage shall be accessible by the backup system 

available at IFREMER which shall perform a nightly saving of every new or changed files. 

SR.INT.ARC.0550/I The online space storage shall be accessible for the backup system 

available at IFREMER to restore saved files if needed. 

4.1.7 Interfaces between HR-DDS production and dissemination systems 

SR.INT.DDS.0010/I The HR-DDS production system (SOC) shall be interfaced with the 

DODS server (in the IFREMER dissemination system) to subset and download the 

relevant L2P products for the computation of the related HR-DDS. 

SR.INT.DDS.0020/I The HR-DDS production system (SOC) shall be interfaced with 

the DODS server (in the IFREMER dissemination system) to subset and download the 

relevant L4UHR products for the computation of the related HR-DDS.. 

SR.INT.DDS.0030/I There shall be an ftp interface between SOC and CMS for the 

movement of netCDF format AATSR data. 

SR.INT.DDS.0040/I 

There shall be an interface between SOC and GDAC for the 

© 2004 SOC Page 62 of 193



movement of metadata records. 


Issue F 

SR.INT.DDS.0050/I There shall be an interface between the AATSR mirroring 

service and the Medspiration AATSR netCDF converter, which shall be monitored by the 

DDS system controller. 

SR.INT.DDS.0060/I There shall be an interface between the AATSR netCDF 

Converter and the netCDF Atlantic extraction process, which shall be monitored by the 

DDS system controller. 

SR.INT.DDS.0070/I There shall be an interface between the netCDF Converter and 

the AATSR HR-DDS Processor, which shall be monitored by the DDS system controller. 

SR.INT.DDS.0080/I There shall be an interface between the AATSR HR-DDS Processor 

and the HR-DDS Parser and Metadata Processor, which shall be monitored by the DDS 

system controller. 

SR.INT.DDS.0090/I There shall be an interface between the L2P HR-DDS Processor 

and the HR-DDS Parser and Metadata Processor, which shall be monitored by the DDS 

system controller. 

SR.INT.DDS.0100/I There shall be an interface between the L4UHR HR-DDS 

Processor and the HR-DDS Parser and Metadata Processor, which shall be monitored by 

the DDS system controller. 

SR.INT.DDS.0110/I There shall be an interface between the HR-DDS Processing 

System and the HR-DDS Archive, which shall be monitored by the DDS system 

controller. 

SR.INT.DDS.0120/I There shall be an interface between the HR-DDS archive and 

the HR-DDS DODS server, which shall be monitored by the DDS system controller. 

SR.INT.DDS.0130/I There shall be an interface between the HR-DDS archive and 

the HR-DDS sftp server, which shall be monitored by the DDS system controller. 

4.1.8 Interfaces between IFREMER system controller and other systems 

SR.INT.CTR.0020/I All IFREMER systems shall be interfaced with the Ifremer system 

controller, delivering operation and error messages. 

© 2004 SOC Page 63 of 193




Issue F 

SR.INT.CTR.0030/I Remote systems (SOC, CMS) shall deliver to the controller the 

relevant error and operation messages to be centralized in the operation log system. The 

messages shall be transmitted through ftp. 

The IFREMER system controller will not have any direct control on remote systems (at 

SOC or CMS).The only interaction is through the operation and error messages. 

SR.INT.CTR.0040/I The controller shall deliver to the Medspiration remote systems the 

error and operation messages related to the dataflow control (retransmission request, 

acknowledgement). The messages shall be transmitted through ftp. 

SR.INT.CTR.0050/I Error and operation messages shall be formatted as specified in 

annex 4 (“Operation and error messages”). 

SR.INT.CTR.0060/I All systems under IFREMER control shall be able to return to the 

controller a return status after they have completed their task. 

4.2 External 

4.2.1 Satellite data providers 

SR.EXT.ING.0010/I The ingestion module shall query the provider to check the 

availability of data files from provider according to Table 5-1, Table 5-2 and Table 5-3 

SR.EXT.ING.0020/I The ingestion module shall download the available data files 

from data provider according to the protocol defined in Table 5-1, Table 5-2 and Table 

5-3 

SR.EXT.ING.0030/I Error message generated by the ingestion module shall be sent 

to the data provider and the system controller. 

SR.EXT.ING.0040/I The configuration files (see SR.QLC.0020 and SR.CFD.0370) 

will be received from GHRSST-PP by email (see SR.CFI.L2P.0010). They will be 

replaced manually after a coherency check. 

Comment: Configuration file format is still to be defined. 

SR.EXT.L2P.0010/I SSES will be provided by the GHRSST (see SR.CFI.L2P.0020) 

They will include a couple of error statistics (bias and standard deviation) per source and 

per confidence level value. 

Comment: The missing value to be used during the initiation phase remain to be defined. 

© 2004 SOC Page 64 of 193




Issue F 

SR.EXT.SYS.00xx/I The MMR_DSD records shall be sent by email to the GHRSST- 

PO. 

SR.EXT.SYS.00xx/I 

appendix A6 

The format of the MMR_DSD record is described in GDS 

4.2.2 In situ data provider 

SR.EXT.MDB.0010/I The MDB records production system shall be interfaced with the 

CORIOLIS data centre to access the in-situ data. 

In the frame of MEDSPIRATION, the CORIOLIS data centre will be considered as the 

only source of in-situ data. However, CORIOLIS is a gateway to GTS data and MEDS 

data. 

SR.EXT.MDB.0020/I The in situ data shall be delivered daily by CORIOLIS in netCDF 

format. 

This format will be defined in close collaboration with the CORIOLIS team. 

SR.EXT.MDB.0030/I The data files shall be directly readable through the IFREMER local 

network (no transmission) since the CORIOLIS data centre is hosted by IFREMER. 

4.2.3 GDAC 

SR.EXT.CTR.0210/I The L2P products shall be delivered to GDAC by ftp push as soon 

as they have been ingested in the archiving system. 

The UHR/L4 products shall not be delivered to GDAC since they are regarded as a 

purely Medspiration product in the SoW. 

SR.EXT.CTR.0220/I The L2P products shall be delivered to GDAC by IFREMER with 

respect to the protocol requirements defined for the dataflow control subsystem of the 

system controller (refer to section 1.4.1). 

SR.EXT.CTR.0230/I The L2P products shall be formatted as described in annex 1. 

4.2.4 GDAC MDB 

SR.EXT.CTR.0310/I The Medspiration system shall be interfaced with the the GHRSST- 

© 2004 SOC Page 65 of 193



PP MDB at GDAC. 


Issue F 

SR.EXT.CTR.0320/I The MDB records shall be formatted as XML files with respect to the 

DTD provided in Annex 3 (“MDB records format”). 

SR.EXT.CTR.0330/I The generated MDB data records shall be sent to the GHRSST-PP 

MDB through ftp. 

It is stated in GDS that both email or ftp may be used for the delivery. Only ftp will be 

considered within Medspiration since it provides better control on delivery checking and 

delays, and for consistency with delivery of MMR-FR and Error logs. 

SR.EXT.CTR.0340/I An error message (event code 9) shall be received from the central 

error log system if a Medspiration MDB record is rejected by the GHRSST MDB. 

4.2.5 Master Metadata Repository 

SR.EXT.CTR.0410/I The Medspiration system shall be interfaced with the Master 

Metadata Repository System. 

SR.EXT.CTR.0420/I Each MMR-FR shall be formatted in XML format, following the DTD 

in annex 5 (“format of MMR files”). 

SR.EXT.CTR.0430/I Each MMR-FR shall be delivered to the Master Metadata Repository 

by ftp push. 

It is stated in GDS that both email or ftp may be used for the delivery. Only ftp will be 

considered within Medspiration since it provides better control on delivery checking and 

delays, and for consistency with delivery of MDB records and Error logs. 

4.2.6 GDS error log system 

SR.EXT.CTR.0510/I The Medspiration system shall be interfaced with the central 

GHRSST-PP error log system, providing it with error messages or receiving error 

messages. 

SR.EXT.CTR.0520/I Each error log will be formatted in XML format, following the DTD in 

annex 4 (“Operation and error messages”). 

No format is specified in the GDS (although WP-ID1.3.1 refers to Appendix A7 which only 

specifies error codes) for the error messages. Information such as the name of the data 

file rejected or ingested shall be included within the error message. 

© 2004 SOC Page 66 of 193




Issue F 

SR.EXT.CTR.0530/I Each error message shall be delivered to the GHRSST-PP error log 

system through ftp. 

It is stated in GDS that email shall be used for the delivery. We suggest to use ftp instead 

since it provides better control on delivery checking and delays, and for consistency with 

delivery of MDB records and MMR-FR. 

4.2.7 User interfaces 

SR.EXT.DIS.0010/I Users shall access to the DODS server for L2P, L4 (IFREMER) or 

HR-DDS (SOC) product subsetting and download using a DODS client (available on 

DODS web site, at http://www.unidata.ucar.edu/packages/dods/) or using a web form 

which shall be available with each server (at SOC and IFREMER). The web form comes 

with the DODS installation package. 

SR.EXT.DIS.0020/I Users shall access to the Live Access Server for L4 product 

subsetting and download using a web interface available with the IFREMER LAS 

installation. 

SR.EXT.DIS.0030/I Users shall be able to download L2P and L4 products from the 

IFREMER ftp site using a standard ftp client. 

SR.EXT.DIS.0040/I Ftp push from IFREMER to operational users shall be possible. 

Users shall register by email to the Medspiration help desk providing an ftp server 

address with write permission. The products shall be pushed following the protocol 

defined in section 1.4.1. 

4.2.8 DDS external interfaces 

SR.EXT.DDS.0010/I There shall be an ftp interface between SOC and ESA for the 

movement of ATS_NR__2P files. 

SR.EXT.DDS.0020/I There shall be an interface between SOC and GHRSST-PP for 

the movements of ATS_NR__2P files. 

SR.EXT.DDS.0030/I There shall be an open interface between SOC and the Internet 

for the movement of HR-DDS data via DODS. 

SR.EXT.DDS.0040/I There shall be an open interface between SOC and GHRSST- 

PP for the movement of HR-DDS data via sftp. 

© 2004 SOC Page 67 of 193




Issue F 

SR.EXT.DDS.0050/I There shall be an interface between the HR-DDS System and 

GDAC for the movement of metadata. 

SR.EXT.DDS.0060/I There shall be an interface between the HR-DDS System 

Controller and GDAC for the movement of ERRLOG records. 

© 2004 SOC Page 68 of 193




Issue F 

5. PERFORMANCE REQUIREMENTS 

5.1 Scenario Definitions 

SR.PER.SYS.0010/A The L2P data files shall ideally be delivered within 6 hours after 

acquisition. It is recognised this may be not possible depending on the L2 data providers 

on which the Medspiration system has no control and thus it is just an ideal target. 

SR.PER.SYS.0011/I 

L2P must be produced in near real time. 

SR.PER.SYS.0015/I A cutoff time (Ω) must be specified after which L2P data are no 

longer eligible for inclusion within the analysis. This must take account the time taken to 

process L2P data (∆Time L2P ), the time required to perform the analysis (∆T analysis ) itself 

and the Maximum desirable output time delay (T output ) using: 

Ω = 

(Eqn. 2.3.1) 

Toutput 

− ∆Tanalysis 

− ∆TL2P 

For example: if T output = 12:00 at T+1, ∆T analysis =4h and, ∆T L2P =2h then Ω= 06:00 at T+1. 

This means that L2P SST data for day T can be accepted until day T+1 at 06:00 UTC. 

Comment: After this cutoff time data concerning the analysis at day T will be considered 

as too late and a message error will be sent. 

SR.PER.SYS.0020/A The UHR/L4 data files shall be provided within 12 hours after the 

end of the processing window, that is to say before T0 + 36h when processing the (T0 -> 

T0 + 24h) UHR/L4 product. 

SR.PER.SYS.0030/A The L2P MMR_FR metadata records shall be provided to MMR 

within 60 minutes after L2P production. 

SR.PER.SYS.0040/A The MDB records shall be delivered within 24 hours after they 

are delivered by the in situ data center. 

SR.PER.SYS.0050/A The L2P MMR_FR rejected by the MMR shall be less than 2%. 


instant 

The MMR_DSD describe the availability of data files at any given 

SR.PER.SYS.0070/I A too long delay between two data files availability of a same data 

© 2004 SOC Page 69 of 193




Issue F 

stream shall raise an error message to the GHRSST-PP and the data provider. This 

delay shall be parameterised for each data stream. 


better. 

All SST data products are requested to an accuracy of 0.4K or 

SR.PER.DDS.0010/I HR-DDS MMR_FR files shall be provided to MMR within 60 

minutes of granule generation. 

SR.PER.DDS.0020/I HR-DDS MMR-FR file rejection rate shall be less than 2% 

SR.PER.DDS.0030/I HR-DDS granules shall be available via DODS within 3 hours of 

L4UHR / L2P file generation. 

SR.PER.DDS.0050/I The ESA server ftp-ops.pde.envisat.esa.int shall be deemed not 

to provide an acceptable service if the average bandwidth available to SOC is less than 

50Kbytes/sec and/or more than 10% of interface attempts result in a timeout. 

SR.PER.DDS.0060/I 

less than 98%. 

The AATSR mirroring service shall have a user up-time of no 

SR.PER.DDS.0070/I 

than 98%. 

The DODS and sftp servers shall have a user up-time of no less 

5.2 Characterisation of L2 input data 

This section is a review of L2 data requested by the GHRSST-PP. 

5.2.1 Satellite SST 

Table 5-1: Satellite SST data streams used by Medspiration. 

Name sensor resolution Coverage Data provider/delivery 

ATS_NR_2P AATSR 1 km Atlantic ftp pull from SOC 

AVHRR16-L 

AVHRR 2 km Mediterranean ftp pull from PODAAC 

AVHRR17-L 

AVHRR16-L 

AVHRR17-L 

(NARSST) 

AVHRR 2 km European seas 

(RGD) 

Internal from 

EUMETSAT/CMS 

© 2004 SOC Page 70 of 193




Issue F 

Name sensor resolution Coverage Data provider/delivery 

AVHRR16-G 

AVHRR 9 km Global ftp pull from PODAAC 

AVHRR17-G 

SEVIRI SEVIRI 0.1 deg. Atlantic Internal from 

EUMETSAT/CMS 

AMSRE AMSR-E 0.25 deg. Global ftp pull from REMSS 

TMI TRMM-TMI 0.25 deg. Global 40N-40S ftp pull from REMSS 

5.2.2 Auxiliary satellite data 

Table 5-2: Auxiliary satellite data stream used by Medspiration. 

Name Sensor parameter resolution Coverage Data provider and 

delivery 

NISE SSM/I Fract. Sea 

Ice 

25 km Northern and 

Southern 

hemisphere 

ftp pull from NSIDC 

SEVIRI-SSI SEVIRI 3h SSI 0.1 deg. Atlantic Internal from 

EUMETSAT/CMS 

AMSRE-WSP AMSR-E Wind speed 0.25 deg. Global ftp pull from REMSS 

AMSRE-ICE AMSR-E Ice flag 0.25 deg. Global ftp pull from REMSS 

AMSRE-RAIN AMSR-E Rain rate 0.25 deg. Global ftp pull from REMSS 

TMI-WSP TRMM-TMI Wind speed 0.25 deg. Global 40N-40S ftp pull from REMSS 

TMI-RAIN TRMM-TMI Rain rate 0.25 deg. Global 40N-40S ftp pull from REMSS 

AVHRR-AOD AVHRR AOD 1. deg. Global 70S-70N ftp pull from NESDIS 

AVHRR-AOD AVHRR AOD 2 km Mediterranean ftp pull from PODAAC 

AVHRR-AOD AVHRR AOD 9 km Global ftp pull from PODAAC 

The auxiliary data provided with a SST source are given in italics. They should be given 

© 2004 SOC Page 71 of 193




priority over any external sources, apart in case of known deficiencies. 

Issue F 

5.2.3 NWP model outputs 

Table 5-3: NWP output data stream used by Medspiration. 

Name Parameter resolution coverage Data provider and 

delivery 

ECMWF-ICE 

Fract. Sea 

Ice 

0.5 deg. globe pull from ECSS 

ECMWF-SSI 6h SSI 0.5 deg. globe pull from ECSS 

ECMWF-U 

ECMWF-V 

U-wind 

component 

V-wind 

component 



5.2.4 Reference data sets 

The following reference data sets have been identified 

• 10 day minimum climatologic SST 

• MODIS/Terra land cover 

• Most recent SST analysis : to be provided by GHRSST; meanwhile, a 10 day mean 

climatology will be used. 

• Upwelling maps (EUR/ATLUPW and EUR/MEDUPW): they will be derived from the 

Landmask (LPDAAC/LANDMASK) at 10 km resolution over the Atlantic and 2 km 

resolution over the Mediterranean. A coastal area will be defined as 

upwelling_distance (km) away from coastline, upwelling_distance should be distinct 

in the Atlantic and in the Mediterranean. 

• Contamination map : equivalent to the land mask at the micro-wave SST resolution 

over the Atlantic. 

© 2004 SOC Page 72 of 193




Table 5-4 Reference data sets used by Medspiration. 

Issue F 

name Parameter resolution coverage Data provider and 

delivery 

CMS-mini 

CMS-mean 

(substitute to 

most recent 

SST analysis) 

LMSK + 

upwelling map+ 

contamination 

map 

10 day mini 

climatic SST 

10day mean 

climatic SST 

Land cover 

classification 

0.1 deg. globe Internal from 

EUMETSAT/CMS 

0.1 deg. globe Internal from 

EUMETSAT/CMS 

1km globe ftp pull from LPDAAC 

5.3 Characterisation of in situ data 

This section is a review of the in situ data requested by the GHRSST-PP against what is 

available at the CORIOLIS data centre. Discrepancies between the requirements and 

the actual available data are identified and solutions are proposed to provide in the end 

the best set of MDB records. 

The requirements in the GDS are : 

1. sources : CORIOLIS, MEDS, additional in situ sources if relevant [RD-1: 1.2] 

2. sensors : moored and drifting buoys, ships [RD-3: WP-ID3.1.1] 

3. SST measurements : SST1m [RD-3: WP-ID3.1.1] 

4. ancillary data : as specified in appendix A3-1 [RD-1: 1.2] 

A first characterisation of the available data in the CORIOLIS database has been 

performed with the CORIOLIS staff to assess, and eventually refine, these requirements 

and to quickly identify eventual problem areas. 

1. sources : MEDS data provided through the GTS-PP are collected by CORIOLIS 

(when not already obtained from the GTS). CORIOLIS can thus be identified as the 

single in situ data provider which will significantly reduce the complexity of the 

© 2004 SOC Page 73 of 193




Issue F 

Medspiration external interfaces. In addition, this will give access to some other data 

sources such as Argo or the in situ data collected over the Mediterranean sea during 

the MFSTEP experiment (from September 2004 for 6 months). 

2. The data identified in the CORIOLIS database is shown in Table 5-5: 

Table 5-5 In situ data for the Mediterranean available through Coriolis 

Sensor Depth Age Count 

(Mediterranean 

in 2003) 

Comment 

Moored 

From 

Daily (GTS) 

Very few in Mediterranean sea 

buoys 

surface 

666 

Floats 

> 5 m Near real 

Not requested but good quality 

(ARGO) 

time 

Drifting 

From 

Daily (GTS) 

not available in 

~1000 over global ocean 

buoys 

surface 

2003 

CTD (ships) 

From 

Near real 

High quality but still very few 

surface, 

time 

measurements 

every meter 

XBT (ships) > 5 m, 

Often 

1015 

Quality of measurements between 

every meter 

highly 

[0, 5m] uncertain, often discarded 

delayed 

TSG (ships) > 5 m Often 

highly 

delayed 

141118 Quality uncertain (particularly on 

VOS = 70% of measurements) 

3. SST measurements : It can observed from the above table that selecting only 

SST1m measurements will lead to ignore many other data sources. It is suggested to 

relax this constraint down to 5 m (the closer measurement to the 1 m depth will be 

selected anyway for each profile) which could allow to consider also the float 

measurements which quality may be valuable for the MDB. 

4. The meteorological data are currently not available within the CORIOLIS data. It was 

agreed with CORIOLIS head that they will be collected from the GTS by the 

CORIOLIS staff (when simultaneously available with a SST measurement) and 

© 2004 SOC Page 74 of 193




Issue F 

ingested in the database. Not all the parameters listed in the GDS table A4.1.2 will 

be available, only what is distributed through the GTS will be retrieved. 

© 2004 SOC Page 75 of 193




Issue F 

6. EXPANDABILITY REQUIREMENTS 

6.1 General 

SR.EXP.SYS.0010/I Configuration files shall be used to implement configurable code 

as input parameters are expected to evolve. 

SR.EXP.SYS.0020/I The system shall be extensible and flexible to accommodate new 

satellite sensors and the potential failure of others. Software shall not be dependent on 

any single input data stream and be capable of ingesting new data streams with minimum 

additional development. 

SR.EXP.SYS.0030/I Extensions are envisaged, in a further stage (not within 

Medspiration), to provide UHR products for the Nordic Seas 48N-75N 12W-70 E 2-3 km 

and Black Sea 40N-48N 27 E–42 E 2-3 km 

6.2 Generation of L2P 

SR.EXP.L2P.0010/I It is foreseen that data streams will change throughout the life of 

the GHRSST-PP. The GDS must be capable of bringing new data streams in and out of 

the processing system without affecting other components of the system. 

SR.EXP.L2P.0020/I Future revisions of the GDS will most likely use near 

contemporaneous wind speed observations from other satellite instruments. 

SR.EXP.L2P.0030/I 

modified. 

It is expected that the methodology used to derive IPCV may be 

SR.EXP.L2P.0040/I The GDS procedures for the derivation of IPCV and MPCV 

values described in GDS WP-ID2.1.1.14 are quite basic. It is clear that significant 

improvements can be made leading to a better quality of pixel error statistics. It is 

foreseen that this component of the GDS will be upgraded following further research and 

development within the GHRSST-PP Diagnostic Data Set. 

SR.EXP.L2P.0050/I It is foreseen that minor modifications to the procedures used to 

control the quality of input data and derive L2P data files may be required once significant 

experience is gained with the GDS. 

SR.EXP.L2P.0060/I As experience is gained in the distribution and application of 

GDS data products, data product format changes are foreseen based on user 

requirements and data delivery constraints. 

© 2004 SOC Page 76 of 193




Issue F 

SR.EXP.L2P.0070/I The GDS reference processor system should be used to test all 

proposed upgrades so that the implications of the proposed changes may be evaluated 

prior to operational implementation. 

6.3 Diagnostic data set 

SR.EXP.DDS.0010/I The HR-DDS system shall be capable of ingesting new data 

sources with minimum effort. 

SR.EXP.DDS.0020/I The HR-DDS system shall be capable of producing data for any 

geographical region; however, total data volume may be limited by Medspiration to 10 

Gigabytes per month as necessary. 

SR.EXP.DDS.0030/I 

stream. 

The HR-DDS system not be dependant on any specific L2 data 

SR.EXP.DDS.0040/I The HR-DDS code shall not contain any ‘magic numbers’, 

editable configuration files shall be used. 

SR.EXP.DDS.0050/I No data source other than ATS_NR__2P shall be required to be 

mirrored on the AATSR mirroring service. 

SR.EXP.DDS.0060/I The Atlantic Extractor Process shall be capable of selecting data 

from additional rectangular regions within the limits already set, as defined by the 

GHRSST-PP Problem Resolution Board.#. 

© 2004 SOC Page 77 of 193




Issue F 

7. SECURITY REQUIREMENTS 

SR.SEC.SYS.0010/I 

with use of L2P. 

There are no data product dissemination limitations associated 

Comment: However some inputs are password protected for restricted use within the 

GHRSST community. 

SR.SEC.DDS.0010/I The AATSR mirroring service shall employ authorisation 

procedures no weaker than the ftp-ops.pde.envisat.esa.int system. 

© 2004 SOC Page 78 of 193




Issue F 

8. DESIGN REQUIREMENTS 

SR.DES.SYS.0010/I 

The system shall be developed in a robust manner. 


The system shall be built in a modular way. 


The system design should focus on reliability and simplicity. 

SR.DES.SYS.0040/I Configuration file shall be used to implement configurable code 

as input parameters are expected to evolve. 

SR.DES.SYS.0050/I The system should be able to ingest new data streams or 

remove existing data streams with minimum code modification. 


Software shall not be dependent on any single data stream. 

© 2004 SOC Page 79 of 193




Issue F 

9. RELIABILITY, AVAILABILITY AND MAINTAINABILITY 

REQUIREMENTS 

SR.REL.SYS.0010/I The system shall run automatically in near real time without human 

intervention except for monitoring and maintenance tasks. 

SR.REL.ARC.0020/I The archiving system shall provide a backup service to restore data 

lost in case of a disk crash or any hardware failure causing no recoverable damage to 

the archived data. 

© 2004 SOC Page 80 of 193




Issue F 

10. TESTING REQUIREMENTS 

SR.TST.SYS.0020/I In order to verify that each processing centre has implemented 

the GDS correctly a reference GDS data processor will be used to process a set of data 

products using a GDS test data set. 

SR.TST.SYS.0030/I 

generated. 

Error message indicating data set rejection shall be correctly 


Error message shall be delivered correctly to data provider. 


ERRLOG. 

Error messages shall be delivered correctly to the GHRSST-PP 

SR.TST.SYS.0060/I MMR_DSD records shall be prepared and registered correctly 

within the GHRSST-PP MMR system. 


L2 data files shall be correctly renamed. 

SR.TST.SYS.0080/I L2P output data products based on the GDS test input data set 

produced at each RDAC and GDAC should be identical to those produced by the GDS 

reference data processor. 

SR.TST.SYS.0090/I L2P measurement data shall be identical to the input SST data 

but with additional error and QC). 


manner. 

MMR_FR metadata records shall be submitted in a timely 

© 2004 SOC Page 81 of 193




Issue F 

11. SAFETY REQUIREMENTS 

There are no specific human safety requirements for Medspiration. 

© 2004 SOC Page 82 of 193




Issue F 

12. CUSTOMER FURNISHED ITEMS 

SR.CFI.SYS.0010/I GHRSST-PP will provide a DVD containing 2 days of L2 data 

files having global coverage from each L2 satellite data stream considered by the 

GHRSST-PP. Both polar orbiting and geostationary observations will be included. 

SR.CFI.SYS.0020/I GHRSST-PP will provide a DVD containing 1 week of in situ data 

straddling the same period as the data sets described in SR.CFI.SYS.0010 

SR.CFI.SYS.0030/I GHRSST-PP will provide an example GHRSST-PP Match-Up 

Database with entries for each sensor. 

SR.CFI.SYS.0040/I GHRSST-PP will provide example GHRSST-PP MDB data 

records, netCDF format L2P, SSTfnd and HR-DDS 

SR.CFI.L2P.0010/I The GHRSST-PP Project Office shall update the configuration 

files for quality checks of ingested data and these shall be sent by email to the person 

responsible for the ingestion and L2P processor at CMS. (see SR.EXT.ING.0040). 

SR.CFI.L2P.0020/I The GHRSST-PP Project Office shall every month supply 

updated SSES by email to the person responsible for the L2P processor at CMS (see 

SR.EXT.L2P.0010). 

SR.CFI.DDS.0010/I ESA shall maintain the ftp-ops.pde.envisat.esa.int service for the 

duration of Medspiration in an acceptable state. 

SR.CFI.DDS.0020/I 

DDS sites. 

GHRSST-PP shall provide SOC with the locations of the HR- 

SR.CFI.DDS.0030/I Only the GHRSST-PP Problem Resolution Board shall be able to 

adjust the HR-DDS locations after SRR. 

SR.CFI.DDS.0040/I ESA shall provide Medspiration access to the ftpops.pde.envisat.esa.int 

server 

© 2004 SOC Page 83 of 193




Issue F 

13. GLOSSARY 

AATSR 

AMSR-E 

AMSRE-ICE 

AOD 

ARGO 

AVHRR 

CERSAT 

CMS 

CNR 

CORIOLIS 

CTD 

DDS 

DODS 

DTD 

DV 

ECMWF 

ERRLOG 

ESA 

EUDAC 

EURDAC 

FNMOC 

GDAC 

GDS 

GHRSST-PP 

Advanced Along-Track Scanning Radiometer 

Advanced Microwave scanning radiometer for Earth Observation 

auxiliary fractional sea ice field 

Aerosol Optical Depth 

Global array of temperature/salinity profiling floats 

Advanced very high resolution radiometer (NASA) 

Centre ERS d'Archivage et de Traitement - French ERS 

Processing and Archiving Facility 

Le Centre de Météorologie Spatiale 

Consiglio Nazionale delle Ricerche 

A system for operational oceanography under development in 

France to monitor and forecast the ocean behaviour. 

Conductivity/Temperature/Depth instruments 

(High resolution) Diagnostic data set 

Distributed Oceanographic Data System 

Document Type Definition 

Diurnal Variability 

European Centre for Medium-Range Weather Forecasts 

Error log 

European Space Agency 

European data assembly centre 

European regional data assembly centre 

Fleet Numerical Meteorology and Oceanography Center 

Global data assembly centre 

GHRSST-PP data processing specification 

GODAE high resolution sea surface temperature pilot project 

© 2004 SOC Page 84 of 193




Issue F 

GODAE 

GTS 

HR-DDS 

IFREMER 

IPCV 

IPO 

IR 

LAS 

LPDAAC/LANDMASK 

MDB 

MDR 

MEDS 

MEDSPIRATION 

MFSTEP 

MMR 

MMR_DSR 

MMR_FR 

MMR-DSD 

MODIS 

MPCV 

MPS 

NISE 

NWP 

NWP-ICE 

Global ocean data assimilation experiment 

Global Telecommunication System 

High-resolution diagnostic data set 

Institut français de recherche pour l'exploitation de la mer 

(French Research Institute for Exploitation of the Sea) 

Infrared proximity confidence values 

International project office 

Infrared 

Live Access Server 

Land Processes Data Active Archive Centre / LANDMASK 

Match-up data base 

Match-up data record 

Marine Environmental Data Service 

A European Contribution to the Global Ocean Data Assimilation 

Experiment Gridded High Resolution Sea Surface Temperature 

Pilot Project 

Mediterranean forecasting system toward environmental 

prediction 

Master metadata repository 

MMR data set record 

MMR file record 

Master metadata repository data set description 

Moderate Resolution Imaging Spectroradiometer (Aqua, Terra) 

Microwave proximity confidence values 

Medspiration processing system 

Reference sea ice data sets 

Numerical Weather Prediction 

NWP fractional sea ice field 

© 2004 SOC Page 85 of 193




Issue F 

OI 

QC 

RD 

RDAC 

SEVIRI 

SOC 

SOW 

SR 

SSES 

SSI 

SSM/I 

SST 

TRMM-TMI 

TSG 

UHR 

XBT 

Optimal interpolation 

Quality control 

Referenced Documents 

Regional data assembly centre 

Spinning Enhanced Visible and Infrared Imager (Meteosat 

Second Generation) 

Southampton Oceanographic Centre 

Statement of Work 

System Requirements 

Sensor specific error statistics 

Surface solar irradiance 

Special Sensor Microwave Imager (Defense Meteorological 

Satellite Program) 

Sea surface temperature 

Tropical Rainfall Measuring Mission Microwave Imager 

Thermosalinograph 

Ultra-high resolution 

Expendable bathythermograph 

. 

© 2004 SOC Page 86 of 193




Issue F 

This Page Is Intentionally Blank 

© 2004 SOC Page 87 of 193

Medspiration MED-SOC-RS-001_1 

System Requirements Document Issue F 

APPENDIX A TRACE BETWEEN USER REQUIREMENTS AND SYSTEM REQUIREMENTS 

This appendix contains two large tables which facilitate cross-referencing between the three reference documents [RD-1, RD-2 and RD-3] and the 

system requirements presented in the main body of this document. Table A1 segments the text in the reference documents (except for sections that are 

clearly out of the scope of Medspiration) and assigns unique identifiers to each statement, alongside the document page number and any relevant table, 

rule or figure numbers. The right hand column of this large table shows the SRs which can be traced back to the statement. Alternatively the statement 

is judged to be one which is intended to provide background information, or (in the case of [RD-3]) is out of the scope of Medspiration. In this case the 

entry is not a software requirement (NASR). 

Table A2 provides the reverse reference, from a systematic list of SRs back to the IDs of the reference document statements (as defined in Table A1) 

from which they are derived or which have influenced their definition. This arrangement using two tables should facilitate the following: 

• Checks to ensure that the system functionality required by the reference documents is fully reflected in the System requirements. 

• A means of rapidly cross-referencing those parts of the reference documents which relate to each of the system requirements. 

Not all SRs have a trace back to the reference documents. For these, their origin should be apparent from their context in this document. In many 

cases they relate to internal requirements such as internal interfaces or system controllers which are essential for the specification of a consistent 

overall system. Where there are discrepancies between the SR and the reference to which it is traced, this should be explained in the comments 

following the SR in the main body of this document, or will be discussed in the Design Justification File (DJF). 

© 2004 SOC Page 88 of 193



Table A1. Trace between the documented user requirements and the system requirements specified in this document 

Key to abbreviations used in the SR entry column: 

NASR 

ATPD 

Not a system requirement (Text in the reference document which may be explanatory or background, and 

where there is nothing mentioned which contributes to defining the system) 

Not a system requirement, but concerned with testing the system and thus may be relevant to the Acceptance Test 

Procedures Document 

Out of Scope 

Format 

Specifies requirements for a part of GHRSST-PP activity that lies outside the scope defined by the Statement of Work 

Contains information about detailed formatting of data files, reference variables, configuration files etc. 

Page Table, fig. Reference ID Text from reference documents 

SR entry 

Statement of Work 

3 1 Introduction 

3 sow-001 The international GODAE steering committee initiated the international GODAE High Resolution SST Pilot Project 

(GHRSST-PP) to develop a system that will deliver a new generation of global coverage high resolution (better than 10 km 

and ~6 hourly) SST data products in real time that are tuned to the requirements of modern operational oceanography. 

NASR (not a 

software 

requirement) 

3 sow-002 GHRSST-PP data products will be derived by combining complementary Level-2 (L2) satellite and in situ observations to NASR 

improve spatial coverage, temporal resolution, cross-sensor calibration stability and SST product accuracy through synergy. 

© 2004 SOC Page 89 of 193




3 sow-003 Due to the large volumes of data that are considered by the GHRSST-PP and the demanding data product delivery 

SR entry 

NASR 

constraints, the GHRSST-PP is designed as a distributed processing system. 

3 sow-004 The strategic implementation concept of regional/global task sharing (RGTS) by regional data product assembly centres 

NASR 

(RDAC) interconnected by dedicated, fast data connections has been adopted to underpin the practical implementation of 

the GHRSST-PP data processing system. 

3 sow-005 RDAC ingest, quality control and merge together existing L2 satellite and in situ data sources to generate regional area 

NASR 

coverage quality controlled data products in realtime. 

3 sow-006 Every 6 hours, these data products are consolidated at RDAC and sent to a Global Data Analysis Centre (GDAC) where 

NASR 

they are integrated together with other RDAC data streams having an identical data format but covering different 

geographical areas to provide global coverage data products. 

3 sow-007 The Medspiration project will provide a European RDAC service to the GHRSST-PP during 2004-2006 by generating and 

disseminating European and Atlantic area SST data products according to the GHRSST-PP Detailed Processing Model 

SYS.0020 

ING.0130 

(DPM) [AP-1]. 

3 sow-008 In addition, Medspiration will serve the direct needs of the European SST user community. SYS.2050 

3 1.1 The GHRSST-PP data processing model 

3 sow-009 The combined Medspiration DPM1 [AP-1], developed by the International GHRSST-PP Science Team, provides a 

NASR 

complete technical description of the data processing tasks required to generate GHRSST-PP data products. 

3 sow-010 Before SST data originating from different sources can be properly assimilated into ocean model systems or analysed 

NASR 

together to provide new SST data products that capitalise on their synergy, a bias and rms error estimate is required for 

each [pixel] measurement. This is a fundamental component of the GHRSST-PP processing model. 

3 sow-011 Error estimates for each L2 SST measurement are based on the statistical analysis of a match up database (MDB) NASR 

© 2004 SOC Page 90 of 193




SR entry 

containing satellite and in situ observations. 

3 sow-012 A quantitative confidence value is derived that is then used to assign statistical bias and rms. error estimate to each 

NASR 

measurement. 

3 sow-013 The outputs of this process are L2 pre-processed (L2P) products for each data file ingested by the processor. NASR 

3 sow-014 Operational ocean modelling users that have requested [AP-2] this type of SST data product may access L2P data 

NASR 

products directly in real time. 

3 sow-015 However, the majority of SST data users request [AP-2] complete SST fields, free of gaps caused by clouds, rain or lack of 

NASR 

data coverage, at regular intervals of between 6 and 24 hours. 

3 sow-016 Some require an estimate of the sub-surface SST field that cannot be directly measured using current satellite techniques NASR 

3 sow-017 whereas others require an estimate of the surface skin temperature that is in direct contact with the overlying atmosphere 

NASR 

and subject to considerable diurnal variability. 

3 sow-018 To address these needs, L2P data are used in an optimal interpolation scheme that is designed to NASR 

3 sow-019 (a) account for differences in spatial and temporal sampling characteristics of each data stream, NASR 

3 sow-020 (b) account for gaps in coverage due to the presence of cloud, rain or lack of data, NASR 

3 sow-021 (c) pre-condition data to account for SST diurnal variability and sensor bias, NASR 

3 soo-022 (d) retrieve an estimate of the subsurface temperature field (referred to as the foundation temperature, SSTfnd2). NASR 

3 sow-023 In addition, a measure of diurnal variability within the data product time domain will be derived to accompany the SSTfnd 

NASR 

estimate 

3 sow-024 and an estimate of the skin temperature of the ocean (SSTskin) will be retrieved based on parameterisations. NASR 

4 sow-025 L2P and SSTfnd SST products have been designed to satisfy the requirements of operational ocean forecast and 

NASR 

prediction systems. 

4 1.2 Objectives of the Medspiration project 

© 2004 SOC Page 91 of 193




4 sow-026 Medspiration will be the European RDAC service to the GHRSST-PP and provide SST data products to specific 

operational European users in near real time. The emphasis of the project is to use complementary satellite L2 SST and in 

situ data products together to deliver a new generation of SST data products. The Medspiration project consists of a data 

SR entry 

SYS.0010 

ARC.0010 

ARC.0040 

processing system, an off-line data archive and a data product dissemination service. 

4 sow-027 The following satellite data shall be used as input to the Medspiration software; 

4 sow-028 • AATSR EXT.ING.0010, 

DDS.1010 

4 sow-029 • AVHRR EXT.ING.0010 

4 sow-030 • TMI EXT.ING.0010 

4 sow-031 • AMSRE EXT.ING.0010 

4 sow-032 • AMSR Ignore 

4 sow-033 • MSG EXT.ING.0010 

4 sow-034 • SSM/I3 (L3 gridded SSM/I derived wind speed data as specified in [AP-2] required for derivation of L2P data products) EXT.ING.0010 

4 sow-035 These data are fully described in Table 4.2.1 of the Medspiration URD [AP-2]. NASR 

4 sow-036 The following in situ data shall be used as input to the Medspiration software: NASR 

4 sow-037 • Moored buoy, drifting buoy and ship SST observations obtained from the CORIOLIS and MEDS data centres. (4 

Additional in situ SST observations may also be used in the Medspiration software) These data are fully described in Table 

EXT.ING.0010 

EXT.MDB.0010 

4.2.1 of the Medspiration URD [AP-2]. 

4 sow-038 Additional auxiliary and reference data that are required are fully described in [AP-1, Appendix A3-1]. NASR 

4 sow-039 The following products/services shall be developed and operated for 12 months: NASR 

4 sow-040 • Production and dissemination of L2P for the overall European RDAC, page 33 of Medspiration URD [AP-2] SYS.0050 

DIS.0010 

© 2004 SOC Page 92 of 193




SR entry 

ARC.0010 

4 sow-041 • Production and dissemination of SSTfnd at Ultra High Resolution (UHR) for the Mediterranean Sea5 coverage, page 34 

of the Medspiration URD [AP-2]. (The Mediterranean Sea has been selected as an initial priority area within the 

Medspiration project [AP-2] due to lower cloud coverage conditions compared to other suggested areas. Other UHR areas 

SYS.0080 

DIS.0010 

EXP.SYS.0030 

indicated in [AP-2] may also be considered at a later date.) 

6 1.4 Product Definitions 

6 1.4.1 GHRSST-PP L2P data products for the European RDAC 

6 sow-042 A full description of GHRSST-PP L2P data products can be found in [AP-1, page 86]. SYS.0052 

6 sow-043 L2P data products are generated for every L2 satellite SST data file that is ingested into the Medspiration system. Each 

L2P data file consists of the original L2 SST measurements together with a unique set of confidence data and a mean bias 

and rms. error estimate (known as sensor specific error statistics (SSES)) that must be derived for every [pixel] 

measurement using the GHRSST-PP MDB [AP-1, page 58]. 

L2P.0010 

L2P.0020 

L2P.0040 

L2P.0050 

L2P.0070 

6 sow-044 SSES will be provided to the contractor by the GHRSST-PP. CFI.L2P.0020 

6 sow-045 L2P data files are formatted as netCDF data files according to the GHRSST-PP format fully documented in [AP-1, page 

INT.ARC.0030 

100]. 

6 sow-046 L2P data files are required by ocean modelling data assimilation systems SYS.0100 

6 sow-047 and for inclusion into GHRSST-PP and Medspiration L4 analysis procedures. SYS.2020 

6 sow-048 A GHRSST-PP metadata record, fully documented in [AP-1, page 144], will be created for each L2P data file and sent to 

the GHRSST-PP global metadata repository as described in [AP-1, page 144]. 

SYS.0055 

ING.0030 

6 1.4.2 SSTfnd UHR data products for the Mediterranean Sea 

6 sow-049 A number of European SST data users [AP-2] have requested data products that have a higher spatial resolution [2-3km] NASR 

© 2004 SOC Page 93 of 193




SR entry 

than the standard 1/12º GHRSST-PP L4 SSTfnd data product specification [AP-1, page 61]. 

6 sow-050 SSTfnd UHR data products will be generated by Medspiration for European users for the Mediterranean Sea as first 

priority6 [AP-2]. 

6 sow-051 L4 SSTfnd UHR data products will be generated from L2P data products following the same methodology as for GHRSST- 

SYS.0080 

L4A.0010 

SYS.0083 

PP SSTfnd data products 

6 sow-052 allowing for variations in decorrelation length scales and a higher spatial grid specification. SYS.0082 

6 1.4.3 GHRSST-PP High Resolution Diagnostic Data Set (HR-DDS) granules 

6 sow-053 The Medspiration project shall extract GHRSST-PP HR-DDS data granules for its coverage area SYS.0070 

DDS.0010 

6 sow-054 and format them as netCDF data files that are described in [AP-1, page 88]. SYS.0071 

DDS.0020 

6 sow-055 HR-DDS data granules will be delivered to the GHRSST-PP HR-DDS system. SYS.0071 

DDS.0110 

6 sow-056 A GHRSST-PP metadata record, will be created for each HR-DDS data file and sent to the GHRSST-PP global metadata 

repository as described in [AP-1, page 152]. 

SYS.0071 

DDS.0010 

6 1.4.4 GHRSST-PP Match up database (MDR) data records 

6 sow-057 The Medspiration project shall prepare and deliver MDB records as described in [AP-1, page 54] for the GHRSST-PP MDB 

SYS.0060 

system. 

6 sow-058 The format of GHRSST-PP MDB records is described in [AP-1, page 130] and is compatible with other international 

SYS.0061 

satellite and in situ MDB systems. 

7 1.5 The Medspiration system scope 

7 sow-059 The Medspiration demonstration system must be capable of providing an operational service that delivers SST data SYS.0015 

© 2004 SOC Page 94 of 193




SR entry 

products to European users and the GHRSST-PP GDAC. 

7 sow-060 It must be able to ingest, process and disseminate large volumes of satellite and in situ data in near real time. SYS.0015 

DIS.0020 

DIS.0030 

7 sow-061 It must also be capable of real time ftp push and pull high-volume data delivery services [AP-1]. DIS.0110 

DIS.0120 

7 sow-062 The scope of the Medspiration system should consider the data streams and data volumes outlined in [AP-2], Table 4.2.1. SYS.0030 

7 sow-063 Figure 1.5.1 shows a functional decomposition diagram of the major data processing activities within the Medspiration 

SRD Fig 2.4 

9 1.7 Prerequisites 

project together with associated input and output products. 

9 The following key issues shall be taken into consideration by the Contractor when executing the work: 

9 sow-064 • The GHRSST-PP and Medspiration is focussed on the provision of an operational near real time generation of SST data 

SYS.0015 

products. 

9 sow-065 Timeliness of data production, dissemination SYS.0015 

9 sow-066 and reliability of the Medspiration software system are critical to the success of the service. DES.SYS.0030 

CTR.0110 

9 sow-067 • Where possible the Medspiration shall rely on the use of configuration files [lookup tables] and implement configurable 

code [AP-4, page 13] that allows the processing model to be tuned (e.g., based on experience decorrelation length scales 

and various input parameters are expected to evolve) without the need to modify the Medspiration system software. 

DES.SYS.0040 

EXP.DDS.0010 

EXP.DDS.0020 

EXP.DDS.0030 

EXP.DDS.0040 

9 sow-068 • The optimal interpolation scheme used to derive L4 SSTfnd data products is expected to evolve as more experience is SYS.0082 

© 2004 SOC Page 95 of 193




SR entry 

gained through research and development within the GHRSST-PP. 

9 sow-069 The Medspiration L4 analysis system shall therefore be built in a modular manner (e.g. Mediterranean sea first) that allows 

for a limited amount of software adjustment without affecting the remainder of the Medspiration system. 

9 sow-070 • The Medspiration software shall be developed in a robust manner that is not dependent on any single data stream (which 

may not be available due to failure) 

DES.SYS.0010 

DES.SYS.0020 

DES.SYS.0060 

EXP.L2P.0010 

9 sow-071 and be capable of ingesting new data streams as they become available with minimum additional software development. DES.SYS.0050 

EXP.L2P.0010 

9 sow-072 • The Medspiration service shall be promoted. NASR 

9 sow-073 Publicity material NASR 

9 sow-074 including scientific publication, if generated, NASR 

9 sow-075 shall be directed towards non earth observational specialists with emphasis toward the application of Medspiration data 

NASR 

products and services. 

9 sow-076 • The project shall be undertaken by a European consortium containing partners familiar with: NASR 

9 sow-077 • Large scale NRT software and system development NASR 

9 sow-078 • Operational dissemination of satellite data sets, NASR 

10 2.1 Customer furnished Items (CFI) 

10 sow-079 A GHRSST-PP Reference Test Data Set (TDS) provided by the GHRSST-PP will be used to develop and test services 

CFI.SYS.0010 

10 The TDS will include the following: 

implemented in each GHRSST-PP RDAC. The intention is to provide this data set as a DVD. 

10 sow-080 • CFI 1: 2 days of L2 data files having global coverage from each L2 satellite data stream considered by the GHRSST-PP 

CFI.SYS.0010 

as defined in [AP-1, Appendix 3]. Both polar orbiting and geostationary observations will be included. 

10 sow-081 • CFI 2: 1 week of in situ data straddling the same period as the data sets described in Part 1. CFI.SYS.0020 

© 2004 SOC Page 96 of 193




SR entry 

10 sow-082 • CFI 3: An example GHRSST-PP Match-Up Database7 with entries for each sensor [AP-1]. CFI.SYS.0030 

10 sow-083 • CFI 4: Example GHRSST-PP MDB data records, netCDF format L2P, SSTfnd and HR-DDS CFI.SYS.0040 

10 sow-084 granule data files and associated metadata records. CFI.SYS.0040 

10 sow-085 The GHRSST-PP TDS DVD will be available to the Contractor at the Medspiration project KO. CFI.SYS.0010 

10 sow-086 SSES files will be provided every month as a CFI by the GHRSST-PP Science Team coordinated by the International 

CFI.L2P.0020 

GHRSST-PPO Project Office and made available to the Contractor through ESA. 

10 2.2 Work breakdown 

10 sow-087 The Medspiration project will be subdivided into two distinct phases: NASR 

10 sow-088 • Phase 1: System Prototype Development (12 months) following the procedures laid out in [AP-3] see PMP 

10 sow-089 • Phase 2: An update of the system (3 months) and a sustained Service Demonstration (12 months including the system 

see PMP 

update phase). 

10 sow-090 At all stages of the project, ESA and the GHRSST-PP will monitor the progress of the project. At the end of Phase 1, an 

see PMP 

Acceptance Review will take place to assess the prototype system and a decision to continue into Phase 2 of the project 

will be taken. A complete service assessment will take place at the end of Phase 2. 

10 2.3 Project management 

10 sow-091 A Project Management Plan (PMP) shall be delivered by the Contractor at KO. PMP 

10 sow-092 Monthly report shall be delivered to ESRIN the first working day of each month by E-mail. PRP 

10 sow-093 Progress meetings shall be held according to the following timetable: NASR 

10 • KO: ESRIN 

10 • KO + 2 month: SRR, Contractor 

10 • KO + 4 Month: PDR, ESRIN 

10 • KO + 6 Months: CDR, ESRIN 

© 2004 SOC Page 97 of 193




SR entry 

10 • KO + 9 Months: QR, ESRIN 

10 • KO + 12 months: AR, contractor 

10 • KO + 15 months: System update, ESRIN 

10 • KO + 18 months: User feedbacks, Contractor 

10 • KO + 24 months, Medspiration Symposium, ESRIN 

User Requirements Document 

Background to GHRSST and its requirements 

5 URD-001 The Global Ocean Data Assimilation Experiment (GODAE) was initiated in 1997 by the Ocean Observing Panel for Climate 

NASR 

(OOPC), in concert with the Global Climate Observing System (GCOS) and the Global Ocean Observing System (GOOS), 

as an experiment in which a comprehensive integrated observing system will be established and operated for several 

years. From 2003 to 2007 GODAE will provide a global system of observations, communications, modelling and 

assimilation which will deliver regular, comprehensive information on the state of the oceans. Information generated by 

GODAE will be made widely available for operational applications in regional and local situations calling for timely 

knowledge and forecasting of the ocean state. 

5 1 URD-002 Sea surface temperature (SST) measured from Earth Observation Satellites in considerable spatial detail and at high 

NASR 

frequency, is increasingly required for use in the context of operational monitoring and forecasting of the ocean, for 

assimilation into coupled ocean-atmosphere model systems and for applications in short-term numerical weather prediction 

and longer term climate change detection. The international GODAE steering committee focused attention on the centrality 

of SST measurements to the success of GODAE by initiating the GODAE High Resolution SST Pilot Project (GHRSST- 

PP). 

5 7 URD-003 The purpose of the GHRSST-PP is to develop an operational demonstration system that will deliver a new generation of NASR 

© 2004 SOC Page 98 of 193




SR entry 

global coverage high-resolution (better than 10 km and ~6 hourly) SST data products 

5 URD-004 GHRSST-PP data products will be derived by combining complementary Level-2 (L2) satellite and in situ observations in 

NASR 

real time to improve spatial coverage, temporal resolution, cross sensor calibration stability and SST product accuracy. 

5 11 URD-005 A full description of the GHRSST-PP project is given in the GHRSST-PP Development and Implementation Plan (GDIP) NASR 

5 5 URD-006 the GHRSST-PP is designed as a distributed processing system. NASR 

6 1 URD-007 The strategic implementation concept of regional/global task sharing (RGTS) by regional data product assembly centres 

NASR 

(RDAC) interconnected by dedicated, fast data connections has been adopted to underpin the practical implementation of 

the GHRSST-PP data processing system outlined in Figure 1. 

6 4 URD-008 RDAC ingest, quality control and merge together existing L2 satellite and in situ data sources to generate regional area 

NASR 

coverage quality controlled data products in real-time. 

6 6 URD-009 Every 6 hours, these data products are consolidated at RDAC and sent to a Global Data Analysis Centre (GDAC) NASR 

6 7 URD-010 where they are integrated together with other RDAC data streams having an identical data format but covering different 

NASR 

geographical areas to provide global coverage data products. 

6 9 URD-011 The GHRSST-PP Development and implementation Plan [RD-2] provides a complete description of the RGTS system and 

NASR 

the GHRSST-PP. 

6 1 URD-012 The combined Detailed Processing Model (DPM) 1 and Input/Output Data Definition document (IODD) [RD-3], developed 

NASR 

by the International GHRSST-PP Science Team, provide a complete technical description of the data processing tasks 

required to generate GHRSST-PP data products. Note that the GHRSST-PP Processing Model will be discussed in detail 

at the 4th GHRSST-PP workshop, to be held in September 2003 at JPL, USA. Following this meeting, changes to the 

current version of the GPM (the Medspiration DPM) are anticipated. It is expected that members of the Medspiration 

consortium will attend the 4th GHRSST-PP workshop. 

6 1 URD-013 Before SST data originating from different sources can be properly assimilated into ocean model systems or analysed NASR 

© 2004 SOC Page 99 of 193




SR entry 

together to provide new SST data products that capitalise on their synergy, a bias and rms. error estimate is required for 

each [pixel] measurement. This is a fundamental component of the GHRSST-PP processing model. 

6 4 URD-014 Error estimates for each L2 SST measurement are based on the statistical analysis of a match up database (MDB) 

NASR 

containing satellite and in situ observations. 

6 5 URD-015 A quantitative confidence value is derived that is then used to assign statistical bias and rms. Error estimate to each 

NASR 

measurement. 

6 7 URD-016 The outputs of this process are L2 pre-processed (L2P) products for each data file ingested by the processor. NASR 

6 8 URD-017 Operational users that have requested [RD-13] these sparse grid SST data products may access L2P data products 

NASR 

directly in real time. 

6 URD-018 However, the majority of SST data users request [RD-13] complete SST fields, free of gaps caused by clouds, rain or lack 

NASR 

of data coverage, at regular intervals of between 6 and 24 hours. 

6 URD-019 Some require an estimate of the sub-surface SST field that cannot be directly measured using current satellite techniques NASR 

6 URD-020 whereas others require an estimate of the surface skin temperature that is in direct contact with the overlying atmosphere 

NASR 

and subject to considerable diurnal variability. 

6 URD-021 To address these needs, L2P data are used in an optimal interpolation scheme (e.g., Reynolds and Smith, 1994; Reynolds 

NASR 

et al, 2002; Guan and Kawamura, 2003) that is designed to 

6 URD-022 (a) account for differences in spatial and temporal sampling characteristics of each data stream, NASR 

6 URD-023 (b) account for gaps in coverage due to the presence of cloud, rain or lack of data, NASR 

6 URD-024 (c) account for SST diurnal variability and retrieve an estimate of the subsurface temperature field (referred to as the 

NASR 

foundation temperature, SSTfnd2), 

6 URD-025 (d) derive a measure of diurnal variability to accompany the SSTfnd estimate and NASR 

6 URD-026 (e) retrieve an estimate of the skin temperature of the ocean (SSTskin). NASR 

© 2004 SOC Page 100 of 193




6 URD-027 L2P and SSTfnd SST products have been designed to satisfy the requirements of operational ocean forecast and 

SR entry 

NASR 

prediction systems. 

6 URD-028 The data generated and maintained at both RDAC and GDAC is interfaced by a suite of services and tools that collectively 

NASR 

provide user information and services (UIS). 

6 URD-029 These include an active web service where data may be viewed, ordered and accessed, an archive service, a 

NASR 

comprehensive metadata repository and a data product validation data base. 

6 URD-030 The UIS is intended to serve the needs of non-operational scientific user groups. NASR 

6 URD-031 In contrast the specific and often unique requirements of operational users are met by the GHRSST-PP Application User 

NASR 

Services (AUS). Within the AUS, a number of systems (e.g., MERCATOR, FOAM, ECMWF) will access and utilise 

GHRSST-PP data products in a test mode to assess their usefulness and measure the impact of their use against existing 

operational practices. 

6 URD-032 Only through this kind of user feedback can a sustainable SST data product service be justified NASR 

7 GHRSST-PP implementation n/a 

7 URD-033 The GHRSST-PP envisages that this work will be supported through Regional Task Sharing Projects that underpin each 

NASR 

RDAC centre. Four GHRSST-PP RDAC projects are currently in preparation and are fully described in the GDIP. These 

are: 

7 URD-034 1. The Medspiration project (MSP) serving the Atlantic, Mediterranean and European Coastal seas area sponsored by the 

NASR 

European Space Agency. 

7 URD-035 2. The New Generation SST project (NGSST) serving the western Pacific area sponsored by the Japanese Space Agency. NASR 

7 URD-036 3. The SeasNET program of the Institut de Recherche pour le Development (IRD) serving the tropical oceans. The 

NASR 

SeasNET project is based in France. 

7 URD-037 4. The Production of Enhanced Multi-sensor SST analysis project (PEMSA) serving the regional needs of the American NASR 

© 2004 SOC Page 101 of 193




SR entry 

region. 

7 URD-038 An initial GHRSST-PP GDAC centre is in preparation at the Jet propulsion Laboratory Physical Oceanography Data Active 

NASR 

Archive Centre (PO.DAAC) that is linked to the US-GODAE data server system (http://www.usgodae.org). The GDAC will 

host the GHRSST-PP metadata repository that is used to document all data sets that are used within the GHRSST-PP as 

described in the GPM [RD-3]. 

7 URD-039 The US-GODAE server is dedicated to serving large data sets to operational ocean models within the GODAE framework 

NASR 

and to other scientific users. It forms the main hub of the GODAE data sharing project and is well connected with the 

operational ocean modelling community in Europe. 

7 URD-040 It is expected that in the coming years an equivalent European GDAC centre may be established providing European 

NASR 

autonomy as a mirrored system. 

7 URD-041 In addition, the extensive experience and capability of the PO.DAAC will ensure that all GHRSST-PP users are provided 

NASR 

with excellent support, documentation and data access. 

7 GHRSST-PP management n/a 

7 URD-042 The planning, management, implementation and monitoring of all aspects of the GHRSST-PP are the responsibility of the 

NASR 

GHRSST-PP Science Team. As stated in the consensus statement of The Ocean Observing System for the 21st Century 

(Koblinsky and Smith, 2001), the GHRSST-PP Science Team has the implementation oversight for the high resolution SST 

analysis network component of an integrated global observation strategy. The GHRST-PP constitutes the first step towards 

such an integrated system of SST measurements. 

7 URD-043 The Science Team is formed as an international group having a broad experience in all aspects of the GHRSST-PP 

NASR 

activities and convenes at least once per year to review the progress of the project. It plays a particularly important role in 

the following areas: 

7 URD-044 1. Reviewing the evolution of GHRSST-PP objectives/goals, maintenance of the GHRSST-PP Strategic Plan and, NASR 

© 2004 SOC Page 102 of 193




SR entry 

GHRSST-PP Development and Implementation Plan (GDIP), the GHRSST-PP Processing Model (GPM); 

7 URD-045 2. Coordination of the international consortium that will undertake the development and implementation of the GHRSST- 

NASR 

PP, including its final transition into an operational system; 

7 URD-046 3. Providing advice and guidance on scientific and technical innovations relevant to the GHRSST-PP; NASR 

7 URD-047 4. Providing a formal body that can liase and interact with national agencies in order to implement the GHRSST-PP. NASR 

7 URD-048 Starting in September 2003, an international GHRSST-PP project office (GHRSST-PO) will become operational at the Met 

NASR 

Office, UK taking responsibility for the day-to-day coordination of all aspects of the project. 

7 1.1 Document Scope n/a 

7 URD-049 ESA has integrated a Data User Element (DUE) within the second phase of the Earth Observation Envelope Programme 

NASR 

(EOEP), which will cover the time frame 2003 to 2007. The DUE provides continuity for the activities that have to date 

been carried out under the Data User Programme (DUP). 

7 URD-050 Consultations with Member States during the preparation of the second period of the DUP indicated that a majority would 

NASR 

like DUP activities to be integrated within the EOEP. 

8 URD-051 The second period of DUP has therefore been limited to three years in order to facilitate the incorporation of its activities 

NASR 

within the second phase of the EOEP. 

8 URD-052 The activities initiated within the DUE provide a bridge between scientific and methodological investigations carried out 

NASR 

within AO projects and the more commercially oriented activities to be performed under market development, an element 

already part of the EOEP. A major benefit is that a single programmatic approach can be followed for both the Product & 

Service development and the market development activities. 

8 URD-053 This document is the User Requirements Document (URD) for a European operational service called Medspiration that will 

NASR 

generate and disseminate SST data products in the European area under the DUE for European users and the GHRSST- 

PP. 

© 2004 SOC Page 103 of 193




8 URD-054 During the preparation of the Medspiration URD, European user requests for GHRSST-PP SST data products have been 

SR entry 

NASR 

solicited and collated by members of the GHRSST-PP Science team coordinated by the GHRSST-PP Science Team 

Chairman. 

8 URD-055 Together, this group acts as an external component of the ESA Expert Support Laboratory (ESL). NASR 

8 URD-056 The Medspiration URD is the first of a series of background documents that define what data products will be produced by 

NASR 

Medspiration, the detailed processing model (DPM) that will be used (which in the case of Medspiration is the GHRSST-PP 

processing model), the input and output definitions for the service (IODD) and, the project validation plan (PVP) that will 

coordinate the validation of Medspiration data products and services. 

8 URD-057 Collectively these documents form the primary inputs to the ESA Data User Element project planning and implementation 

NASR 

process. 

8 1.2 Objectives of the Medspiration project 

8 URD-058 There is no body or project presently existing in Europe able to provide a European contribution to GHRSST-PP by fulfilling 

sys.0010 

the tasks of a European area RDAC (EURDAC). The aim of the Medspiration project is to provide this service to the 

GHRSST-PP and directly serve the interests of European users with dedicated SST data products. 

8 URD-059 Medspiration will implement a finite demonstration service for the European area based on the GHRSST-PP GPM [RD-3] 

which has been developed by the International GHRSST-PP Science Team. 

8 URD-060 The Medspiration service will deliver GHRSST-PP SST data products to specific operational and scientific users in the 

European area and to the GHRSST-PP in real time and as an ftp pull service to registered clients. 

sys.0020, 

sys.0010 

sys.0030, 

sys.0060, 

sys.0070 

DIS.0120 

CTR.0570 

8 URD-061 In addition, Medspiration will generate and deliver ultra-high resolution (~2km spatial resolution data products) for specific sys.0040 

© 2004 SOC Page 104 of 193




SR entry 

European users following the same methodology described in the GPM. 

8 URD-062 The Medspiration project will focus on the following objectives: see following 

8 URD-063 • The implementation of the GHRSST-PP data processing model to provide operational data products covering the Atlantic 

Ocean and European Seas to the GHRSST-PP and European users; 

sys.0020, 

sys.0030 

sys.0070 

8 URD-064 • The operational generation of ultra-high resolution data products (2-4km) for the Mediterranean Sea, and a finite 

sys.0040 

number/time period of user requested small regional areas of interest; 

8 URD-065 • The operational extraction and archive of GHRSST-PP Diagnostic Data Set (DDS) granules [RD-4] for the European area 

and European sensors (ENVISAT AATSR); 

SYS.0050 

DDS.0020 

ARC.0010 

8 URD-066 • Establish data product dissemination service including the operational delivery of SST products to specific European 

sys.0060 

operational users and to the GHRSST-PP GDAC; 

8 URD-067 • Conduct an evaluation of Medspiration data products and service (by solicited user feedback) including a proper 

validation of SST data products using high quality in situ observations provided by users that will form part of the GHRSST- 

PP satellite and in situ match up data base using existing regional in situ infrastructure. 

sys.0080 

sys.0090, 

sys.0100 

9 1.3 Document Content 

9 This document is organised into the following sections: 

9 • Part 1 is this introduction. 

9 • Part 2 provides a user profile for each of the primary users of the Medspiration service. 

9 • Part 3 provides a consolidated user request for Medspiration SST data products. 

9 • Part 4 provides a specification of user defined products and service requirements for the Medspiration service. 

9 1.4 Reference Documents 

© 2004 SOC Page 105 of 193




9 URD-O68 [RD-1] Donlon, C. J., The GODAE High Resolution Sea Surface Temperature Pilot Project: Strategy and Initial 

SR entry 

NASR 

Implementation Plan, available from the GHRSST-PP International Project Office, 2002. 

9 URD-069 [RD-2] Donlon, C. J., The GODAE High Resolution Sea Surface Temperature Pilot Project Development and 

NASR 

Implementation Plan (GDIP), available from the GHRSST-PP International Project Office, 2003b. 

9 URD-070 [RD-3] Donlon, C.J. et al., The Recommended GHRSST-PP In situ and Satellite Integration Processing Model Version 1 

NASR 

(ISDI-PM-v1), available from the GHRSST-PP International Project Office, 2003. 

9 URD-071 [RD-4] Pinnock, S. and C. J. Donlon, Implementation of the GHRSST-PP High Resolution Diagnostic Data Set, GHRSST- 

NASR 

PP Document reference GHRSST/14, available from the GHRSST-PP International Project Office, 2003. 

9 URD-072 [RD-5] Casey, K., Draft Report for the GHRSST-PP Reanalysis Technical Advisory Group (RAN-TAG), available from the 

NASR 

GHRSST-PP International Project Office, 2003. 

11 URD-073 2 GHRSST-PP User Profiles The following sections provide a summary user profile for the major users of SST data 

EXP.SYS.0030 

products in the European area. For each user, a short description of the main SST application is provided followed by a 

summary of the SST data product(s) that are currently used if appropriate. Finally, each user has specified the SST 

products that they would ideally like to use in their applications. Based on a consolidation of all user profiles, a number of 

optimal SST data products are specified in Section 3 that balance the needs of each user group against the need to 

provide an affordable near real-time service. 

33 3 Consolidated User Requirements for Medspiration 

33 URD-074 The user requirements described in Section 2 of this document are broad and encompass a wide range of activities, 

NASR 

demand a large number of different data formats, delivery type and spatio-temporal resolution. In this section of the 

Medspiration URD these requirements are considered together and consolidated into a finite number of SST data products 

that can be used by the widest community of users without significantly compromising any application. 

33 The following criteria were used to consolidate Medspiration user requirements: NASR 

© 2004 SOC Page 106 of 193




SR entry 

33 URD-075 • The requirements of the GHRSST-PP NASR 

33 URD-076 • Number of individual user requests NASR 

33 URD-077 • The long term usefulness of the products NASR 

33 URD-078 • Data product coverage and spatial characteristics NASR 

33 URD-079 • Data product type and accuracy NASR 

33 URD-080 • Temporal characteristics NASR 

33 URD-081 • Data product format NASR 

33 URD-082 • Data product delivery and dissemination NASR 

33 3.1 Medspiration data product coverage 

33 3.1.1 Global coverage 

33 URD-083 European area users requiring global coverage SST data products should these data from the GHRSST-PP GDAC. It is 

not foreseen that Medspiration will produce global coverage SST data products. Clearly though, if GHRSST-PP is to 

generate a real time global coverage SST data product it is important that Medspiration delivers L2P SST data products in 

a timely manner and fulfil the role of a GHRSST-PP RDAC under the GHRSST-PP RGTS implementation model. 

SYS.0015, 

SYS.0050 

DIS.0120 

DIS.0110 

33 3.1.2 European GHRSST-PP RDAC coverage (EURDAC) 

33 URD-084 The core of Medspiration will be to generate SST products over the Atlantic Ocean and adjoining Seas which is influential 

for local forecasting activities in the European area. 

34 URD-085 The Atlantic product should encompass the area 70S to 90N (to the ice limit) and from 100W to 45E (to include the 

adjacent seas) at a resolution of 1/12º (~10km) as shown in Figure 3.1.2.1. At this scale all data input sources used by 

SYS.0010, 

SYS.0050 

SYS.0051 

ING.0130 

GHRSST-PP are possible. 

34 URD-086 This specification corresponds to the “regional coverage” that is envisaged in the GHRSST Strategic Plan for a European 

NASR 

RDAC 

© 2004 SOC Page 107 of 193




34 URD-087 and it encompasses the EUMETSAT Ocean and Sea Ice Satellite and Application Facility (SAFOI) Atlantic region that will 

SR entry 

NASR 

provide a significant data input to the Medspiration project. 

34 T.3.1.2.1 URD-088 Table 3.1.2.1 describes the consolidated user request for GHRSST-PP RDAC SST data products. 

34 T.3.1.2.1 URD-089 GHRSST-PP EURDAC. L2P: 6 hourly SYS.0050 

34 T.3.1.2.1 URD-090 EURDAC (EU users) SSTfnd: daily analysis Out of scope 

34 T.3.1.2.1 URD-091 GHRSST-PP EURDAC GHRSST-PP DDS data granules SYS.0070 

34 T.3.1.2.1 URD-092 EURDAC MDB data records SYS.0060 

34 3.1.3 Medspiration Ultra-High (UHR) resolution coverage 

34 URD-093 The potential zones of interest for ultra-high resolution SST data product coverage are the Mediterranean Sea, the Black 

Sea, the Baltic Sea, the North Sea, the Greenland Sea and the Gulf of Mexico. These areas correspond to particular 

EXP.SYS.0030 

SYS.0080 

interests of the European countries for modelling ocean and air-sea interaction processes at fine resolution. In these cases 

the nominal space resolution is 2-3 km. 

34 URD-094 For UHR products, the use of Microwave SST data as part of the input data is excluded within 50 km of the coast (this is a 

minimum exclusion due to side-lobe contamination). 

CFD.0100 

CFD.0110 

CFD.0120 

34 URD-095 Figures 3.1.3.1-3 describe the areas requested for Medspiration UHR data coverage data products. see below 

34 F.3.1.3.1 URD-096 Figure 3.1.3.1 The Medspiration Mediterranean Sea product grid domain will cover from 30N to 46N and from 6W to 36.5E 

at 2 km spatial resolution. 

35 F.3.1.3.2 URD-097 Figure 3.1.3.2 The Medspiration Nordic Seas product grid domain will cover from 48N to 75N and from 12W to 70E at 2 km 

SYS.0081 

ING.0130 

NASR 

spatial resolution. 

35 F.3.1.3.3 URD-098 Figure 3.1.3.3 The Medspiration Black Sea product grid domain will cover from 40N to 48N and from 27E to 42E at 2 km 

NASR 

spatial resolution. 

© 2004 SOC Page 108 of 193




35 URD-099 Table 3.1.3.1 describes the consolidate user request for Medspiration data product ultra high resolution coverage based on 

SR entry 

PER.SYS.0080 

the user requirements set out in Section 2 of this document. All SST data products are requested to an accuracy of 

0.4K or better. The ECMWF request for data products having an accuracy of 0.1K is exceptionally demanding and should 

be considered as an “ultimate” target for satellite derived SST data products. 

36 T. 3.1.3.1 URD-100 Mediterranean Sea; L2P,SSTskin and SSTfnd SYS.0050 

SYS.0080 

36 T. 3.1.3.1 URD-101 Black Sea; L2P and`SSTfnd NASR 

36 T. 3.1.3.1 URD-102 Nordic seas; L2P, SSTskin, & SSTfnd NASR 

37 4 Product and Service Specifications 

37 4.1 Processing system 

37 URD-103 The system should generate the SST products as described in Tables 3.1.2.1 and 3.1.3.1. SYS.0050 to 

SYS.0083 

37 URD-104 In addition, Medspiration must contribute to the building of the GHRSST-PP Diagnostic Data Set as defined in [RD-2] and 

SYS.0070 

[RD-4]. 

37 URD-105 The system should be extensible and flexible in order to accommodate new satellite sensors and the potential failure of 

EXP.SYS.0020 

others. 

37 URD-106 The Medspiration processing system must conform to the GHRSST-PP processing model [RD-3] if regional data products 

SYS.0020 

generated at different GHRSST-PP RDAC are to be effectively combined together as a single global coverage data 

product at GHRSST-PP GDAC. 

37 4.2 Input data definitions 

37 URD-107 The input data sets to the Medspiration data processing chain will be level 2 SST, wind speed and surface solar irradiance 

SYS.0030 

(SSI) data products that are available in real time. 

© 2004 SOC Page 109 of 193




37 URD-108 Table 4.2.1 provides a summary of the data streams that should be considered by the Medspiration data processing 

SR entry 

SYS.0030 

system. All of these data sets are available in real time and have either no data usage agreement or a special data 

agreement that has been negotiated for the GHRSST-PP project. 

37 URD-109 In some cases data providers have stipulated that all data must be used for the sole purpose of the GHRSST-PP. As 

SYS.0040 

37 4.3 Data products 

Medspiration intends to generate and disseminate combined L2 data products (as opposed to the native L2 data streams 

themselves) there are no data product dissemination limitations associated with use of these L2 data streams. 

3 URD-110 The Medspiration Project must be capable of insertion into the implementation strategy of GHRSSTPP, becoming a 

SYS.0010 

Regional Data Assembly Centre and capable of contributing regional coverage GHRSST-PP EURDAC area L2P data 

products (as defined in the GPM) to Global Data Analysis Centres in real time. In addition, European area coverage L4 

analysed data products should be produced to satisfy European user needs. The required data products are: 

37 URD-111 • Collated products (L2P) for each input sensor. L2P data products should be made available to European users in real 

time via special agreement. L2P data products for a single sensor should be consolidated to provide a single L2P data file 

SYS.0050 

SYS.0100 

for each sensor at 6 hourly intervals. These data should also be passed to the GHRSST-PP GDAC in near real time. 

37 URD-112 • A static archive of L2P data products that can (a) serve the needs of the GHRSST-PP reanalysis project and (b) be used 

as the starting point for any reprocessing effort if required. Because the data quality flagging for L2P data is experimental, 

it is important for the pilot project phase of GHRSST to be able to revisit the flagging criteria following quality analysis, 

SYS.0090 

SYS.2040 

ARC.0010 

which is facilitated by preserving a static archive. 

37 URD-113 • Level 4 analysed SSTfnd for Ultra High Resolution areas. The analysed product is the result of combining all available 

SYS.0080 

SST observations using an optimal interpolation (OI) scheme described in [RD-3]. 

37 URD-114 • GHRSST-PP diagnostic data set granules as described in [RD-4] SYS.0070 

SYS.0071 

© 2004 SOC Page 110 of 193




SR entry 

37 URD-115 • Satellite and in situ match up data sets to be entered into the GHRSST-PP MDR system according to [RD-3] as available. SYS.0060 

SYS.0061 

37 URD-116 Several intermediate data products may be produced but these will be internal to the Medspiration project and will not be 

NASR 

available to the user community. 

38 T.4.2.1 URD-117 ATS_NR__2P: AATSR, 1km, (SSTskin) SYS.0030 

38 T.4.2.1 URD-118 ATS_MET_2P: AATS,R 10 arc min, (SSTskin) SYS.0030 

38 T.4.2.1 URD-119 AVHRR16-L: AVHRR NOAA16, 9km, (MCSST) SYS.0030 

38 T.4.2.1 URD-120 NARSST: AVHRR NOAA16+17, 2km, (SSTsubskin) SYS.0030 

38 T.4.2.1 URD-121 AVHRR17-L: AVHRR NOAA17, 9km, (MCSST) SYS.0030 

38 T.4.2.1 URD-122 ATLSST: GOESE+MSG SEVIR,I 0.1º, (SSTsubskin,) SYS.0030 

38 T.4.2.1 URD-123 ATLSSI: GOESE+MSG SEVIR,I 0.1º, (SSI) SYS.0030 

38 T.4.2.1 URD-124 AMSRE: AMSR-E, 25 km grid, (SSTsubskin, Wind speed, water vapour, cloud liquid water vapour, rain rate) SYS.0030 

38 T.4.2.1 URD-125 AMSR: AMSR, 25 km grid, (SSTsubskin) NASR 

39 T.4.2.1 URD-126 TMI: TRMM-TMI, 25 km grid, (SSTsubskin, Wind speed, water vapour, cloud liquid water vapour, rain rate) SYS.0030 

39 T.4.2.1 URD-127 SSMI: SSM/I F13, F14 and F15, (25 km grid, Wind speed, water vapour, cloud liquid water vapour, rain rate) SYS.0030 

39 T.4.2.1 URD-128 ECMWF NWP Wind speed and SSI, 0.5º grid, (Wind speed, heat fluxes and SSI) SYS.0030 

39 T.4.2.1 URD-129 CORIOLIS: In situ SST observations, Point source, (In situ ocean and atmospheric parameters) SYS.2060 

39 T.4.2.1 URD-130 MEDS: In situ observations, Point source, (In situ ocean and atmospheric parameters) SYS.2060 

40 4.4 Product dissemination 

40 URD-131 It is expected that Medspiration will provide an operationally sustained service for a 12 month period following a 12 month 

SYS.0015 

preparation and prototyping phase. 

40 URD-132 It is recommended that Medspiration data products should be made available for public release to obtain the widest SYS.0110 

© 2004 SOC Page 111 of 193




SR entry 

possible application, user feedback and validation data input at the earliest opportunity. 

40 URD-133 At all stages of the project, close user collaboration is required especially with the GHRSST-PP Science Team. SYS.0020 

SYS.0021 (See 

also CFIs in 

chapter 12) 

GDS (version 1, revision 1.1; 7 Jan 2004) 

1.0 Introduction 

17 GDS-001 The primary aim of the Global Ocean Data Assimilation Experiment (GODAE) High Resolution Sea Surface Temperature 

NASR 

Pilot Project (GHRSST-PP) is to develop and operate an operational demonstration system that will deliver high-resolution 

(better than 10 km and ~24 hours) global coverage SST data products for the diverse needs of GODAE and the wider 

scientific community. A new generation of SST data products will be derived and served to the user community by 

combining complementary satellite and in situ SST observations in near real time. A full description of the GHRSST-PP 

project is given in the GHRSST-PP Development and Implementation Plan (GDIP) which can be obtained from the 

GHRSST-PP project web server located at http://www.ghrsst-pp.org. 

17 GDS-002 Figure 1.1 provides a simplified schematic overview of the GDIP. The GHRSST-PP is based on a distributed system in 

NASR 

which the data processing operations that are necessary to operationally generate and distribute high resolution SST data 

sets having global coverage are shared by Regional Data Assembly Centres (RDAC). RDAC ingest, quality control and 

merge existing satellite and in situ SST data sources that are then used together to generate regional coverage quality 

controlled SST data products to the same specification (called L2P products), in real-time. RDAC data products are then 

assembled together at Global Data Analysis Centres (GDAC) where they are integrated and analysed to provide L4 global 

coverage data products. 

© 2004 SOC Page 112 of 193




18 GDS-003 Each RDAC implements a processing system described in the GDS within a regionally funded project that is common to all 

SR entry 

NASR 

RDAC. Five GHRSST-PP RDAC projects are currently in preparation and are fully described in the GDIP. These are: 

18 GDS-004 1. The New Generations SST project (NGSST) serving the western Pacific area replaced by a approximately defined by 

NASR 

the Geostationary Meteorological Satellite (GMS, now replaced by GOES-9) footprint. The NGSST project is based in 

Japan. 

18 GDS-005 2. The European Medspiration Project (MSP) serving the Atlantic area and European shelf seas. SYS.0010 

18 GDS-006 3. The Ocean Forecasting Australia (OFA) BlueLink project serving the regional needs of the Australian region. NASR 

18 GDS-007 4. The Survey of the Environment Assisted by Satellite (SEASnet) program of the IDD serving the tropical oceans. The 

NASR 

SEASnet project is based in France. 

18 GDS-008 5. A project serving the SST needs of the USA under the US National Ocean Partnership Program (NOPP) under the 

NASR 

general title of ‘SST for GODAE’. 

18 1 GDS-009 A GDAC centre is currently in preparation that will be implemented as a joint system by the Jet propulsion Laboratory 

NASR 

Physical Oceanography Data Active Archive Center (PO.DAAC) and the US-GODAE data server system at Monterey 

(http://www.usgodae.org). 

18 4 GDS-010 The PO.DAAC will be responsible for the data management of the GDAC including metadata, data serving and user 

NASR 

interactions and US-GODAE will be responsible for the archive of GHRSST-PP data sets and the production of a global 

analysed SST fields initially using the US-Navy system. 

18 7 GDS-011 The USGODAE server is dedicated to serving large data sets to operational ocean models. In addition, the extensive 

NASR 

experience and capability of the PO.DAAC will ensure that GHRSST-PP scientific users are provided with excellent 

support, documentation and data access. 

18 GDS-012 In parallel, a second backup GDAC will be developed as part of the European Marine Environment and Security in the 

SYS.0010 

European Area (MERSEA) initiative (see http://www.ifremer.fr/merseaip/objectives.htm).The EU RDAC project 

© 2004 SOC Page 113 of 193




SR entry 

Medspiration forms the initial pilot study for the MERSEA GDAC which will provide an operational backup processing 

system to the US GDAC described above. MERSEA aims to develop a European system for operational monitoring and 

forecasting on global and regional scales of the ocean physics, biogeochemistry and ecosystems. The prediction time 

scales of interest extend from days to months. This integrated system will be the Ocean component of the future European 

Global Monitoring for Environment and Security (GMES) system. An initial configuration of the MERSEA EU GDAC is 

expected in 2006/7. 

18 GDS-013 Figure 1.2 shows the configuration of the GHRSST-PP Regional/Global task sharing system that will implement the GDS. 

In addition to the global processor system, the GDAC also hosts the GDS (international) system-wide metadata repository 

(MMR), matchup database system (MDB), High Resolution Diagnostic Data Set (HR-DDS) and main product archive. 

RDAC will also maintain their own specific archives of L2P data products, HR-DDS, MDB and ultra-high resolution (~2km 

spatial grid) data products as required but the MMR will always reside at the GDAC. 

SYS.0010 

SYS.0060 

SYS.0070 

SYS.0090 

SYS.0100 

ARC.0010 

19 The GHRSST-PP Data Processing Specification (GDS) 

19 1 GDS-014 The GHRSST-PP Data Processing Specification (GDS) is a recommended common data processing specification that 

NASR 

should be implemented at each GHRSST-PP RDAC and GDAC. It defines clearly the input and output data specifications, 

data processing procedures, algorithms and data product file formats that are used within the GDS and are thus common 

to each GHRSST-PP RDAC and GDAC. This is a prerequisite if the GHRSST-PP Global/Regional task sharing 

implementation framework is to function efficiently. 

19 7 GDS-015 The GDS specifies in detail the minimum data processing that should be performed at each RDAC and GDAC centre to 

SYS.0020 

ensure that data and data products can be used and exchanged with confidence. For example, a common processing 

description is necessary to simplify documentation of data, facilitate exchange by sharing a common data format agreed by 

RDAC, GDAC and users, to avoid significant duplication of effort, to minimise reformatting of different data products 

© 2004 SOC Page 114 of 193




SR entry 

derived by RDAC and to ease the integration of RDAC data to provide global coverage data sets at GDAC centres. Lowlevel 

data products generated according to the GDS will form a direct input to the GHRSST-PP reanalysis project (RAN). 

These operationally produced data products will then be improved by using additional data that are only available in a 

delayed mode together with extensive quality control procedures. The GHRSST-PP RAN Strategy is described in Casey et 

al. (2003). 

19 GDS-016 GHRSST-PP RDAC centres must implement data processing procedures that account for specific aspects of regional 

SYS.0010 

coverage input data products (e.g., geostationary imagers). RDAC must also provide additional data products and services 

to satisfy regional user requirements (e.g., regionally specific analysed data products or ultrahigh resolution data products) 

that will require research and development of new analysis, quality control, and data provision procedures. Regional 

extensions to the GDS are both necessary and critical to the preservation of regional identity and the proper evolution of 

the GDS; without evolution, the data products and services provided by the GHRSST-PP are unlikely to satisfy developing 

user demands and concerns. 

20 GDS-017 It is not possible to specify exactly how the final version of the GDS will be implemented and operated without first having 

an initial ‘Version-1’ system in place to make an informed assessment. Neither is it desirable to have a GDS that is rigid 

SYS.0021 

DES.SYS.0040 

without the ability to innovate based on experience. The first version of the GDS (v1.0) is focused on an initial data 

processing specification with specific emphasis on implementing: 

20 GDS-018 (a) An operational data exchange and delivery system connecting data providers, RDAC, GDAC and user communities by 

SYS.0015 

2005, 

20 GDS-019 (b) A number of common format (L2P) sensor specific near real time SST data products SYS.0050 

20 GDS-020 (c) A suite of regional L4 data products based on different analysis procedures following current state-of-the-art knowledge 

SYS.0080 

that can be upgraded and refined based on experience. The analysis procedures should as far as possible capitalise on 

the synergy benefits of complementary measurements (accuracy, susceptibility to atmospheric clouds and aerosol loading, 

© 2004 SOC Page 115 of 193




SR entry 

spatial and temporal resolution etc.) 

20 GDS-021 (d) An initial Global analysis system at the GHRSST-PP GDAC, NASR 

20 GDS-022 (e) An initial implementation of the GHRSST-PP High Resolution Diagnostic Data Set (HR-DDS) system and, SYS.2080 

SYS.2081 

SYS.2082 

20 GDS-023 (f) A suite of initial test data products to be available to selected users at each RDAC and GDAC by mid 2004. CFI.SYS.0010 

20 GDS-024 The GDS is split into several work package (WP) sections that are supported by extensive technical Appendices. This 

NASR 

format provides a framework that preserves the readability of the processing specification while providing extensive 

technical references that can be easily maintained and updates without affecting the overall structure of the GDS. While 

the interface parameters for each work package will remain relatively static, considerable flexibility within a WP is 

maintained by this type of approach. Work packages develop a modular approach with clearly defined input and output 

parameters that greatly assist in the development of large multiinstitute/ national projects such as the GHRSST-PP. 

20 Document Scope 

20 GDS-025 This document is the GDS version 1 which is based on the First Report of the GHRSST-PP In situ and Satellite Data 

NASR 

Integration Technical Advisory Group (ISDI-TAG, Wick et al, 2002) and many subsequent discussions at the Third 

GHRSST-PP Workshop, held at ESA/ESRIN, Frascati, Italy in December 2002 (Donlon, 2003b) and further refined at the 

4th GHRSST-PP Science Team Meeting, Los Angeles, USA in September 2003. It represents a consensus opinion of the 

GHRSST-PP community of how to pursue the optimal combination of satellite and in situ data streams within a globally 

distributed operational system to provide a new generation of global coverage SST data products. Much of the document is 

dedicated to issues of data exchange, management and operational considerations. For certain international groups 

(particularly the European Medspiration project), it provides a reference baseline that will be implemented and innovated 

by their project. 

© 2004 SOC Page 116 of 193




20 GDS-026 The GDS will evolve as each of the GHRSST-PP RDAC projects gain experience and knowledge throughout the Pilot 

SR entry 

NASR 

Project and a significant scientific upgrade of the processor is foreseen following the successful commission of the v1.0 

GDS. This is thus a working document written primarily for the RDAC and GDAC teams as they physically realise, develop 

and, refine the GHRSST-PP demonstration system. The document content will be constantly modified as initial approaches 

are tried and refined by the RDAC teams. But, in order to maintain consistency with funding agencies, published releases 

of the GDS will occur at regular intervals and represent reference baselines. 

21 7 GDS-027 These will carry an integer revision number (e.g., GDS-v1.0, GDS-v2.0 etc). As such, each may be considered a technical 

NASR 

reference manual for the GHRSST-PP for a given time window based on the best current knowledge of the GHRSST-PP 

community, the Science Team, data providers and RDAC/GDAC projects. The GDS will be modified, refined and updated 

and published electronically on a regular basis by the GHRSST-PP International Project Office (GHRSST-PO) as RDAC 

projects implement the GDS. 

23 2 Notations, conventions and definitions used by the GDS. 

23 GDS-028 The following sections describe the notations and conventions that are used throughout the GDS documentation. RDAC 

SYS.0020 

and GDAC implementation projects are expected to adhere to the nomenclature and style of the GDS in their own 

documentation as much as possible. This will greatly facilitate exchange of documentation between each centre. 

23 2.1 Flow diagram symbols 

GDS-029 Table 2.1.1 Symbols used in GDS flow and functional breakdown diagrams SYS.0020 

2.2 Definition of data processing levels 

GDS-030 The GDS uses the definitions provided in Table 2.2.1 when referring to data processing levels SYS.0020 

2.3 GDS data processing window specifications 

24 GDS-031 GDS data analysis processing activities are linked to Analysed Product Processing Window (APPW) periods within a 24 

L4A.0020 

hour period that are defined in Table 2.3.1. A cutoff time (Ω) must be specified after which L2P data are no longer eligible 

© 2004 SOC Page 117 of 193




SR entry 

for inclusion within the analysis. This must take account the time taken to process L2P data (DTime L2P ), the time required 

to perform the analysis (DT analysis ) itself and the Maximum desirable output time delay (T output ) using (Eqn. 2.3.1) 

2.4 GHRSST-PP definitions of sea surface temperature 

24 GDS-032 2.4.1 to 2.4.5 are physical definitions of temperature variables See SRD 

section2.1.1 

26 GDS-033 2.4.6. The diurnal cycle/variation of SST (DV) For the GDS, a diurnal cycle refers to changes in vertical and horizontal 

See 

SRD 

distribution of SST throughout a 24 hour period and thus includes warm stratified layers and cool skin effects. Cool skin 

section2.1.1 

effects are typically more pronounced at night due to radiative cooling of the sea surface but may also occur during the day 

when the wind is light following a significant rainfall that may leave a cool freshwater layer on the surface of the ocean 

2.4.7 GDS operational output grid specifications 

26 T.2.4.7.1 GDS-034 Table 2.4.7.1 describes the GDS preliminary output grid specification that is applicable to standard L4SSTfnd global 

Out of scope 

coverage data products produced by the GDS 

26 T.2.4.7.2 GDS-035 Ultra-high resolution SSTfnd data products (L4FNDUHR) will be similar to L4FND data products but produced on a smaller 

L4A.0050 

grid specification described in Table 2.4.7.2. 

27 T.2.4.7.3 GDS-036 High Resolution Diagnostic Data Set (HR-DDS) will be constructed by remapping L2P data streams onto a uniform grid as 

specified in Table 2.4.7.3. 

DDS.0090 

DDS.0030 

GDS-037 2.5.Missing Data Values In all GHRSST-PP data products missing values are denoted by the integer value -9999 Format 

GDS-038 

2.6 Sea ice value In all GHRSST-PP data products sea ice is denoted by the integer value 5555. The corresponding 

value for the fractional sea ice coverage can be found in the associated L2P and L4 product confidence data record. 

3.0 Overview of the GHRSST-PP Processing Specificationv1.0 (GDS) 

Format 

31 GDS-039 This section of the GDS provides a general overview of the processing model introducing how data will flow within the 

NASR 

processor, the processor input and output data definitions (IODD), and the work packages (WP) that will be used to 

© 2004 SOC Page 118 of 193




SR entry 

implement the processor. It may be used as a “map” of the GDS and identifies the interfaces between each specific work 

package. The work packages themselves are expanded in technical detail within subsequent sections and associated 

appendices of the GDS 

31 GDS-040 Figure 3.1.1 General overview of the GHRSST-PP GDS. Input data sources are shown in red, output parameters are 

NASR 

shown in green and GDS processing steps with a further breakdown are shown in light blue. Database storage is shown in 

dark blue. For each output parameter a corresponding metadata record is generated and delivered to the GHRSST-PP 

Master Metadata Repository (MMR) system. The MMR system has been omitted to preserve clarity in this figure 

32 Summary description of the GDS 

32 GDS-041 The GDS is designed to produce SST data products that satisfy the requirements of operational ocean forecast and 

NASR 

prediction systems. Based on a user requirements survey (see the proceedings of the 3rd GHRSST-PP workshop and the 

Medspiration User Requirements Document for example, both available from the GHRSST-PO or http://www.ghrsstpp.org), 

the main requirements are 

32 GDS-042 1. SST data are required operationally in near real time and should ideally be available within 6 hours of data acquisition at 

SYS.0015 

the satellite platform. 

32 GDS-043 2. An error estimate (bias and standard deviation) and confidence data (such as an indication of atmospheric aerosol 

presence at the time of measurement) for each SST measurement including a bias and SD. is required by users and by 

L2P.0040 

L2P.0050 

the GHRSST-PP as a necessary precursor to data analysis. 

32 GDS-044 3. A global ocean coverage analysed SST data product providing a best measure of the SSTfnd is required at a minimum 

NASR 

interval of 24 hours having a maximum spatial grid size of 1/12° (latitude x longitude). 

32 GDS-045 4. Coastal modelling groups require an ultra-high spatial resolution SSTfnd and SSTskin data products on a grid cell size 

of 1-2km and a timeliness of ~6 hourly. 

SYS.0080 

L4A.0020 

32 Figure 3.1.1 shows a functional breakdown diagram of the GDS that identifies the flow of data, inputs and output channels SRD Fig 2.4 

© 2004 SOC Page 119 of 193




SR entry 

and data. The GDS is split into work package (WP) sections to aid development and understanding of the system. The 

major work package components of the processing specification are shown in light blue together with their associated input 

and output data parameters that are shown in red and green respectively. The flow of data and information between each 

work package is indicated by the direction of connecting arrows. 

32 GDS-046 The GDS data processing flow is designed to: see below 

32 GDS-047 (a) Ingest and QC input SST data sets. L2P.0010 

L2P.0020 

32 GDS-048 (b) Assign pixel confidence data, auxiliary data (wind speed, Surface Solar Irradiance (SSI) and, Aerosol Optical Depth 

(AOD)) to each SST measurement. 

32 GDS-049 (c) Assign error estimates (called Sensor Specific Error Statistics, SSES) to each SST measurement and format as a 

GHRSST-PP L2P output data file. L2P data sets should be available to the RDAC user community and GDAC processor 

L2P.0030 

L2P.0040 

L2P.0050 

PER.SYS.0010 

ideally within 6 hours of data reception at the satellite sensor. 

32 GDS-050 (d) Collocate L2P data records with in situ measurements and enter these data into the GHRSST-PP Match-up 

Database (MDB). 

32 GDS-051 (e) Extract High Resolution Diagnostic Data Set (HR-DDS) data granules from L2P data and submit these data to the 

GHRSST-PP HR-DDS system. 

SYS.0060 

SYS.2060 

SYS.0070 

SYS.2080 

DDS.0030 

INT.DDS.0010 

32 GDS-052 (f) Consolidate L2P SST data sets every 24 hours and analyse all data within an Analysis Product Processing Window 

SYS.0080 

(APPW) to provide a ‘best estimate’ of the SSTfnd. Format analysed SST data sets as GHRSST-PP L4 data files and 

archive. L4 data products should be available to the user community no later than 12 hours following the end of an APPW. 

The analysis procedures, than must be developed, should aim to capitalise on the synergy benefits of complementary 

© 2004 SOC Page 120 of 193




SR entry 

infrared and microwave SST measurements with particular emphasis on data combinations that lead to better accuracy, 

minimise the impacts of cloud/rain contamination and atmospheric aerosol loading, optimise spatial and temporal sampling 

resolution and address diurnal variability amongst others. 

33 GDS-053 (g) Extract High Resolution Diagnostic Data Set (HR-DDS) data granules from L4 data and submit these data to the 

GHRSST-PP HR-DDS system. 

SYS.0070 

SYS.2080 

DDS.0040 

INT.DDS.0020 

33 GDS-054 (h) For each data processing operation, create unique metadata records and submit these to the GHRSST-PP Master 

Metadata Repository (MMR). 

SYS.0055 

CTR.0530 

33 GDS-055 (i) Archive L2P and L4 data in a GDAC archive for use in the GHRSST-PP Reanalysis Project (RAN). SYS.0090 

ARC.0010 

33 GDS-056 Referring to Figure 3.1.1, RDAC first ingest, in real time, regional coverage satellite and in situ SST and auxiliary data 

streams from a variety of different data providers (WP-ID1 in Figure 3.1.1). 

SYS.2010 

L2P.0010 

33 GDS-057 Each input satellite SST data stream is quality controlled to check for gross errors, consistency and timelines. SYS.2010 

L2P.0020 

33 GDS-058 In the case of MW SST data sets, the use of level-2 (L2) as a descriptor of the data processing level is incorrect as these 

NASR 

data are typically L3 gridded fields. Thus, in the context of L2P data descriptions, the input data are actually L2/L3 but in 

order to keep the terminology simple for L2P data files throughout the GDS the term L2P will be used for both L2 IR and L3 

MW SST data sets. 

33 GDS-059 Data that are unacceptable for further use in the GDS are rejected at this point. ARC.0010 

33 GDS-060 Each SST data file is then reformatted to a common GDS pre-processed data format (WP-ID2 in Figure 3.1.1) referred to 

L2P.0060 

as L2P and described in Appendix A1, that is designed to allow easy sharing of data across the GHRSST-PP RDAC, 

© 2004 SOC Page 121 of 193




SR entry 

provide a data product suitable for use by GHRSST-PP data analysis systems and ocean model data assimilation 

schemes, the conform to the GODAE data sharing project. 

33 GDS-061 L2P data products are the lowest-level, common format data products produced by the GHRSST-PP and provide the 

NASR 

“building blocks” for all other higher level data products. 

33 GDS-062 Each L2P data product contains original SST measurements together with confidence fields and an error estimate (called 

SSES and described ion the following paragraphs). L2P data products consist of the original SST measurements (that are 

not re-gridded or modified) together with additional confidence and error estimates. 

L2P.0030 

L2P.0040 

L2P.0050 

33 GDS-063 A separate L2P data product is produced for each sensor at each RDAC. L2P.0070 

33 GDS-064 Operational users that have requested this type of SST data product (see the Medspiration User Requirements Document 

SYS.2050 

(URD), available from the GHRSST-PP Project Office) may access L2P data products directly in real time from RDAC and 

GDAC. 

33 GDS-065 In addition, L2P data products provide a direct input to the GHRSST-PP Reanalysis project (Casey et al., 2003) and form 

NASR 

the principal data archive for the GHRSST-PP. 

33 GDS-066 A bias and standard deviation (sd.) error estimate is required for each [pixel] measurement before SST data originating 

L2P.0050 

from different sources can be properly assimilated into ocean model systems or analysed together to provide new SST 

data products. Assigning error estimates to SST measurements is a fundamental requirement of the GDS. Two types of 

error assignment are possible within a L2P data set: 

33 GDS-067 1. Error estimates provided by a data provider as part of the L2/L4 input data L2P.0050 

33 GDS-068 2. Statistical error estimates calculated from a match up database containing satellite and drifting/moored buoy in situ SST 

L2P.0050 

observations. 

33 GDS-069 In the case of (2), there are clearly insufficient buoy observations to assign a unique error estimate for every satellite 

NASR 

measurement and instead, the available data spanning a particular time-window must be used to assign a statistical error 

© 2004 SOC Page 122 of 193




SR entry 

estimate. This is performed as a four stage process (WP-ID3 in Figure 3.1.1): 

34 GDS-070 1. A quantitative “confidence value”, having a value spanning 0 (no data, measurement is sea ice) to 5 (highest confidence 

in the SST measurement), is derived for each pixel measurement based primarily on an estimate of the surface wind 

L2P.0040 

CFD.0010 

speed, proximity to other cloud contaminated/rain contaminated pixels and, proximity to a SST reference climatology. 

Confidence values are optimized for likely errors from each sensor type (MW and IR). 

34 GDS-071 2. L2P observations are then matched to near contemporaneous quality-controlled in situ SST observations in situ data 

SYS.0060 

and the resulting data record (together with any additional auxiliary data) are stored in a relational database system called 

the GHRSST-PP Match-up Database (MDB). 

34 GDS-072 3. Error estimates for each SST measurement are then derived by analysing the MDB for a given time window (e.g., 1 

Out of scope 

week, 1 month, etc.). For each sensor and for each confidence value (1-5) a Sensor Specific Error Statistic (SSES) is 

produced (i.e., for each sensor and confidence value all data are analysed to compute a mean bias and standard 

deviation). 

34 GDS-073 4. The SSES bias and standard deviation computed in (3) above is then assigned to all [sensor specific] L2P data having 

L2P.0050 

an equal confidence value. 

34 GDS-074 The format of data records held within the MDB is described in Appendix A4 and has been designed to be compatible with 

format 

other SST MDB (e.g., the Miami pathfinder MDB) in order to take advantage of these data and to further contribute to their 

development. 

34 GDS-075 GHRSST-PP L2P data products will serve the requirements of some operational ocean modelling groups in real time. SYS.0100 

34 GDS-076 However, many user applications and operational modelling groups request complete SST fields, free of gaps caused by 

NASR 

clouds, rain or lack of data coverage, at regular intervals of between 6 and 24 hours. 

34 GDS-077 Most users require an estimate of the sub-surface SST field that is free of diurnal variability (the SSTfnd) that cannot be 

NASR 

directly measured using current satellite techniques. 

© 2004 SOC Page 123 of 193




34 GDS-078 Others require an estimate of the surface skin temperature that is more directly related to the overlying atmosphere and 

SR entry 

NASR 

subject to considerable diurnal variability 

34 GDS-079 To address these needs, L2P data will used in an advanced analysis scheme (e.g., Reynolds and Smith, 1994; Reynolds 

SYS.2030 

et al, 2002; Guan and Kawamura, 2003, Murray et al. 2002, Murray et al. 1994, Fieguth et al., 1998; 2000, Menemenelis et 

al. 1997) that is designed to: 

34 GDS-080 (a) Provide a daily global coverage combined SSTfnd product that builds on the synergy between complementary SST 

Out of scope 

data streams having a grid cell size of 1/12° latitude x longitude (GDS-v1.0), 

34 GDS-081 (b) Provide error estimates for each analysed grid cell, L4A.0051 

34 GDS-082 (c) Account for differences in spatial and temporal sampling characteristics of each data stream, L4A.0052 

34 GDS-083 (d) Account for gaps in coverage due to the presence of cloud, rain or lack of data, L4A.0053 

34 GDS-084 (e) Account for SST diurnal variability and retrieve an estimate of the subsurface temperature field (SSTfnd), L4A.0054 

34 GDS-085 (f) Provide a measure of diurnal variability within the data product time domain to accompany the SSTfnd estimate and, L4A.0055 

34 GDS-086 (g) Provide a best estimate of the skin temperature of the ocean (SSTskin) for each grid cell. L4A.0055 

35 GDS-087 At 24 hour intervals, called Analysed Product Processing Windows (APPW) defined in Table 2.3.1, global coverage L2P 

Out of scope 

data products are collated together at GDAC centres and used in an analysis procedure that will generate GHRSST-PP L4 

analysed data products (WP-ID4 in Figure 3.1.1). 

35 GDS-088 L4 SST data products include the foundation SST (SSTfnd) including an estimate of SSTskin diurnal variability (magnitude 

SYS.2030 

and phase). Each L4 data product is formatted to a common GDS L4 data format (Appendix A1) that contains the analysis 

at each grid cell together with quality control and error statistic information. 

35 GDS-089 L4 data products will be available in real time to the GHRSST-PP user community no later than 12 hours after an APPW 

SYS.2050 

(see Table 2.3.1). MDB data records should be prepared for each L4 data product and sent to the GHRSST-PP MDB 

system for product validation activities (WP-ID5). 

© 2004 SOC Page 124 of 193




SR entry 

35 GDS-090 Global analysis will take place at the GHRSST GDAC although regional analysis systems will be used at RDAC. NSAR 

35 GDS-091 The GDS also prepares and delivers L2P and GHRSST-PP Analysed L4 data products for use within the GHRSST-PP 

SYS.2080 

high resolution diagnostic data set (HR-DDS), fully described in reference document GHRSST/14 “The HR-DDS 

implementation plan” and available at http://www.ghrsst-pp.org. 

35 GDS-092 Note that the GHRSST-PP HR-DDS is used for diagnostic analysis and validation of the GHRSST-PP GDS by the 

NASR 

GHRSST-PP community and is completely separate from the GHRSST-PP Match-up Database (MDB) system. 

35 GDS-093 The HR-DDS consists of satellite SST and auxiliary data (wind speed and solar radiation where possible) that are 

DDS.0030 

extracted from data streams and re-gridded to a resolution of 0.01° x 0.01° latitude x longitude over small well defined 

geographical areas called HR-DDS granules (see Appendix A5) that are distributed globally. 

35 GDS-094 The HR-DDS provides a satellite only (at least in the GDS) data resource that allows easy inter-comparison of separate 

DDS.0091 

data streams in an operational manner. 

35 GDS-095 It is implemented as a shared data resource where data access to will be through a Live Access Server (or variant) 

system. 

SYS.2081 

SYS.2082 

35 GDS-096 The primary outputs of the HR-DDS are: NASR 

35 GDS-097 Operational assessment of relative satellite SST bias changes (typically caused by an environmental event (e.g., volcanic 

NASR 

eruption, atmospheric dust) or sensor problems) 

35 GDS-098 To test, validate and refine the methods and data products that are produced by the GDS itself. NASR 

35 GDS-099 Provide a focus for commissioning the GDS and the production of on-going metrics required to assess the performance of 

NASR 

the processor. 

35 GDS-100 Each GDS work package has been designed to encapsulate a distinct suite of activities, common to all RDAC or GDAC 

NASR 

that has a definite input and output definition (IODD). In this way, the exchange and use of all data products within the 

GDS is greatly simplified by referring to the work package interface IODD provided in section 3.2. 

© 2004 SOC Page 125 of 193




36 GDS-101 3.2 Input and output data definitions (IODD) for the GDS Appendix A3 provides a complete description of the input data 

SR entry 

format 

streams for the GDS and the main outputs of the GDS are listed in Table 3.2.1 

39 Work Package number: WP-ID1 Ingestion of Data Streams 

39 Leader: GHRSST-PO and Data Management sub-group (Contact: Ed Armstrong, ed@seastar.jpl.nasa.gov) 

39 Aim : To configure the GDS to successfully ingest near real time data streams from different data providers. 

39 Objectives: 

39 WP1-001 1. Specify the data streams that will be considered by the GDS. NASR 

39 WP1-002 2. Specify a data provider responsible for each data stream. NASR 

39 WP1-003 3. Specify the primary and any secondary GDAD/RDAC entry points for each data stream. NASR 

39 WP1-004 4. Specify the limitations to the use of data arising from specific agreements pertaining to data use within the GHRSST-PP. NASR 

39 WP1-005 5. To specify the GHRSST-PP Master Metadata Repository Data Set Description (MMR_DSD) records for each data 

NASR 

stream. 

39 WP1-006 6. Specify the data transfer mechanism from data provider to GHRSST-PP primary entry point. NASR 

39 Description: 

39 WP1-007 This WP is dedicated to the ingestion of satellite and auxiliary data streams (including in situ and NWP fields) within the 

NASR 

GHRSST-PP GDS. It describes how each data stream is documented within the GHRSST-PP data management system 

and provides guidance for RDAC/GDAC on the essential data ingestion/exchange/provision control mechanisms within the 

GDS. 

39 WP1-008 For each data stream, a MMR_DSD record will be generated and registered by the GHRSST-PO and data management 

ING.0030 

sub-group to which all other L2P MMR File records (MMR_FR) that describe individual data files are registered in WP-ID2. 

39 WP1-009 If data are rejected by the GDS then an appropriate error message should be sent to the data provider stating why the data ING.0020 

© 2004 SOC Page 126 of 193




have been rejected. The error message should be copied to the ERRLOG (errlog@ghrsst-pp.org). 

SR entry 

ING.0100 

QLC.0010 

39 WP1-001 Inputs: 

39 WP1-010 1. Data product definitions. NASR 

39 WP1-011 2. Data provider definitions and restrictions. NASR 

39 WP1-012 3. RDAC/GDAC data usage descriptions. NASR 

39 WP1-013 4. Data access and use agreements. NASR 

39 WP1-014 5. MMR_DSD records. NASR 

39 Outputs: 

39 WP1-015 1. E-mail error message sent data provider explaining data ingestion/format problems. ING.0100 

39 WP1-016 2. E-mail to the GHRSST-PP ERRLOG explaining data ingestion/format problems. QLC.0010 

39 WP1-017 3. MMR_DSD records for each data stream used by the GDS. ING.0030 

39 Acceptance tests: 

39 WP1-018 1. Error message indicating data set rejection is correctly generated. ATPD 

40 WP1-019 2. Error- message is correctly delivered to data provider. ATPD 

40 WP1-020 3. Error messages are correctly delivered to the GHRSST-PP ERRLOG. ATPD 

40 WP1-021 4. MMR_DSD records prepared and registered correctly within the GHRSST-PP MMR system. ATPD 

40 WP1-022 5. Data files are correctly renamed on acceptance into the GDS. ATPD 

40 WP1-023 Figure 4.1 provides a functional breakdown diagram that identifies the main data processing tasks within WP-ID1. These 

NASR 

are: 

40 WP1-024 1. Establish real time operational access to data streams at RDAC and GDAC centres as appropriate for the processing 

centre (i.e. regional or global). 

ING.0010 

EXT.ING.0010 

© 2004 SOC Page 127 of 193




SR entry 

EXT.ING.0020 

40 WP1-025 2. Create a Master Metadata Repository Data Set Description (MMR_DSD) record within the GHRSST-PP MMR for each 

data stream described in Appendix A3. 

ING.0030 

MDB.0530 

40 WP1-026 3. Evaluate each data files for integrity when ingested at an RDAC or GDAC facility. ING.0060 

CTR.0120 

CTR.0110 

40 WP1-027 4. Determine if the data file should be accepted into the GDS. If not, then raise an error report and send this to the data 

provider and to the GDS ERRLOG. 

QLC.0010 

EXT.ING.0030 

40 WP1-028 5. Rename the data file by prefixing the RDAC identification code to the filename. ING.0040 

40 WP1-029 Each sub task is described in the following sections. NASR 

40 F4.1 WP1-030 Figure 4.1 Functional breakdown of GDS WP-ID1 identifying each sub task. NASR 

41 WP-ID1.1.1 Access to input data streams 

41 WP1-031 The GDS does not consider L0, L1a or L1B data streams (although L1B data streams may be available for certain HR- 

NASR 

DDS sites if RDAC are able to supply these data). 

41 WP1-032 Satellite SST, auxiliary satellite data (including wind speed and surface solar irradiance (SSI)), in situ observations and 

L2P.0010 

NWP data are all required by the GDS to construct L2P data products and to produce L4 analysed SST data product 

outputs. 

41 WP1-033 Satellite data are ingested at RDAC and in some cases at GDAC centres. L2P.0010 

41 WP1-034 Each data stream will be formatted according to a well specified format provided by each data provider. format 

41 WP1-035 Note that data streams from the same sensor may have different formats depending on the data provider. format 

41 WP1-036 Table 4.1 provides an overview of the data sets that are available to the GHRSST-PP during the period 2003-2007 

categorised by data type. 

SRD 5.2 Tables 

5-1, 5-2 & 5-3 

© 2004 SOC Page 128 of 193




41 T4.1 WP1-037 Table 4.1 Real Time global and regional satellite and in situ data streams available to the GHRSST-PP during the period 

SR entry 

NASR 

2003-2007. In situ data streams are those providing data within the upper 8 m of the water column. Acronym definitions 

are given in Appendix A2 Table A2.2. 

42 WP1-038 Appendix A3 describes in detail the data that will be used by the GDS. Appendix A3.1 defines the satellite SST data 

NASR 

streams, Appendix A3.2 the auxiliary satellite data streams, Appendix A3.3 the in situ data streams and Appendix A3.4 the 

NWP/Forecast fields. 

42 WP1-039 A unique identification code for each data stream is given in Appendix A3 that will be referred to throughout the GDS. NASR 

42 WP1-040 Also specified are the general characteristics of each data stream including the data provider, data delivery mechanism, 

NASR 

any data agreement that is applicable together with the primary and secondary RDAC/GDAC entry points. 

42 WP1-041 All of this information will be used by the GHRSST-PO and the GHRSST-PP Data management sub-group to generate 

NASR 

MMR_DSD records for each data stream that is used by the GDS according to the specifications provided in Appendix A6 

Table A6.2.1. 

42 WP-ID1.1.2 Preparation of Master Metadata Repository (MMR) data set description records (MMR_DSD) 

42 WP1-042 The data streams within the GDS are dynamic in the sense that new data sets will become available, certain data sets may 

NASR 

take priority in given circumstances (e.g., aerosol contamination) and regional preferences based on the ease of data 

access will exist at RDAC. 

42 WP1-043 The GHRSST-PP Master Metadata Repository (MMR) is an online dynamic database that contains a metadata record for 

NASR 

every data file that is produced by the GHRSST-PP. It provides a major source of information for RDAC and GDAC 

describing the availability of data files at any given instant in time. It also provides a catalogue for the GHRSST-PP 

archive. 

42 WP1-044 The GHRSST-PP MMR system and the format of MMR_DSR and associated MMR File Records (MMR_FR), 

ING.0050 

implementation of the MMR and delivery of MMR data records by RDAC and GDAC is described in Appendix A6. 

© 2004 SOC Page 129 of 193




42 WP1-045 The GHRSST-PO in collaboration with individual data providers, RDAC and GDAC will prepare and maintain MMR_DSD 

SR entry 

CTR.0530 

records within the MMR system for each data stream used in the GDS. 

42 WP1-046 The information within the MMR_DSD must be kept current as these data will be used to monitor the availability of data, 

CTR.0530 

problems and issues that are relevant to operations and data quality. 

42 WP-ID1.2 Evaluate the integrity of data files 

42 WP1-047 When a data file enters a GDAC or RDAC processing facility following transfer from the data provider, it typically resides 

NASR 

on a temporary staging area at an RDAC or GDAC centre. In some cases, the delivery may be incomplete; data 

connections could be lost, corruption of the data may have occurred during delivery, or the original file was incorrectly 

generated. 

42 WP1-048 The aim of the GDS at this stage is to identify a data delivery/data format problem and to initiate a dialog with the data 

provider to establish a solution as soon as possible. 

42 WP1-049 Individual RDAC and GDAC are responsible for implementing local procedures that are able to access data and a wide 

ING.0060 

CTR.0120 

CTR.0180 

variety of tools will be used that are specific to each RDAC. 

42 WP1-050 RDAC/GDAC must also implement local procedures to assess the integrity of satellite data files, delivery protocols and 

reliability noting that these are likely to vary according to the data provider (i.e. the same data may be provided in a 

different format) and in time (data providers change file format, sensor is down, communication. problems). 

42 WP1-051 RDAC systems should focus on operational reliability and simplicity rather than elaborate procedures that are likely to 

CTR.0140 

CTR.0150 

CTR.0170 

DES.SYS.0030 

introduce unnecessary complexity into the data processing system with minimal impact. 

43 WP1-052 As a guide, the first GDS processing steps must evaluate the timeliness and integrity of each data file based on the 

see below 

following questions: 

43 WP1-053 1. What is the status of the satellite system at present Are there health warnings or environmental problems affecting the 

CFI.L2P.0010 

quality of data This information should be present in the MMR_DSD record. 

© 2004 SOC Page 130 of 193




43 WP1-054 2. Was data transfer successful and is the data file complete File sizes and CRC checks for example, will establish the 

SR entry 

CTR.0120 

situation. 

43 WP1-055 3. Is the data file correctly formatted according to the specifications provided by the data provider The data format could 

L2P.0020 

be randomly checked at the RDAC. 

43 WP1-056 4. Was the delivery timely ING.0110 

43 WP-ID1.3 Admit data file into the GDS system 

43 WP1-057 Based on the assessment made by RDAC in WP-ID1.2 a decision is made to either accept a data stream or to reject the 

L2P.0020 

data stream from the GDS. The GDS specifies the following rules for this purpose: 

43 Rule 

WP1-058 

A data file should be admitted into the GDS processing system by an RDAC or GDAC only if the data file has been verified 

QLC.0045 

1.3.1 

as complete, correctly formatted and that the delivery was timely with respect to the L2P delivery criteria of ‘ideally 

available within 6 hours of acquisition at the satellite platform’ and the analysed product processing window (APPW) 

defined in Table 2.3.1. 

43 WP-ID1.3.1 Inform data provider and ERRLOG of data delivery/ingestion problem. 

43 WP1-059 If a data file has been rejected by an RDAC/GDAC, an error must be raised and an e-mail message sent to the data 

ING.0100 

provider that explains why the data file has been rejected from the GHRSST-PP GDS. These messages are used to: 

43 WP1-060 (a) Establish a healthy feedback dialog with data providers NASR 

43 WP1-061 (b) To provide information to the GHRSST-PP that can be used to monitor GDS operations. NASR 

43 WP1-062 A separate error message should be sent for each data access attempt (i.e., if a second download is attempted and 

ING.0120 

also fails two ERRLOG messages are generated). The Data provider contact details and point of contact for error 

reports can be found in the L2P MMR_DSD records associated with each satellite data stream. 

43 WP1-063 A copy of the error message should be sent via e-mail to the GHRSST-PP ERRLOG system using the address 

QLC.0010 

errlog@ghrsst-pp.org. The subject of the message should be written as follows: 

© 2004 SOC Page 131 of 193




44 WP1-065 GDS ERROR message:where is defined in Appendix A2.1 and 

is defined in Appendix A7. The format of ERRLOG messages is provided in Appendix A7. 

SR entry 

EXT.CTR.0520 

 

44 WP-ID1.4 Rename data file to GHRSST-PP GDS specification. 

44 WP1-066 In order to identify a data file that has been admitted into the GDS system by an RDAC or GDAC, the GDS recommends 

ING.0040 

that each data file should be renamed by prefixing the processing centre code to the original filename according to the 

following filename specification: 

44 WP1-067 -GDS- ING.0040 

44 WP1-068 where is defined in Appendix A2 Table A2.1. In the example above, JAP-GDS-20010507tm 

ING.0040 

would refer to a REMSS TMI bmaps_03 data file (20010507tm) that has been checked and admitted into the GDS at the 

Japanese RDAC (JAP). 

44 WP1-069 Renaming a data file in this way provides a simple method to identify data that have passed the initial data delivery tests 

NASR 

from those that have not while preserving the original data product filename. Although data files within this part of the GDS 

may have no visibility beyond the RDAC processor itself, the purpose of renaming files to a common specification is to 

facilitate error analysis and problem solving. If problems are found at a higher level within the GDS processing chain, 

accepted GDS files may be differentiated from other data files and traced back to RDAC/GDAC centres by simply noting 

the filename. 

GDS-WP-ID2 

WP-ID2: Generation of GHRSST-PP Level-2 Pre-processed Data files (L2P). 

45 To process input data files and produce GHRSST-PP L2P SST data files in a timely manner. 

45 Objectives: 

45 WP2-001 1. To extract confidence data provided with each input SST data file. QLC.0050 

© 2004 SOC Page 132 of 193




SR entry 

QLC.0060 

QLC.0065 

45 WP2-002 2. To quality control input SST data and derive GHRSST-PP pixel confidence data. QLC.0010 

45 WP2-003 3. To determine if SST data are suitable for further use in the GDS. If not inform the data provider and generate an error 

QLC.0010 

message for the GHRSST-PP ERRLOG explaining why these data have not been used in the GDS. 

45 WP2-004 4. Extract auxiliary data (wind speed, surface solar irradiance and aerosol optical depth) and collocate with SST data. MRG.0010 

45 WP2-005 5. Create a GHRSST-PP netCDF L2Pdata file. Optional fields will only be included prior to a cut-off time at which point the 

L2P.0055 

L2P data will be shipped ‘as is’. 

45 WP2-006 6. For each L2P data file, prepare and submit L2P MMR_FR to the GHRSST-PP MMR. CTR.0530 

45 WP2-007 7. Submit appropriate error messages to the GHRSST-PP ERRLOG log (errlog@grsst-pp.org). CTR.0550 

CTR.0580 

45 Description: 

45 WP2-008 This part of the GDS is dedicated to the production of L2P data files that consist of native SST observations together with 

NASR 

additional pixel confidence data and auxiliary data stored in GDS netCDF format. 

45 WP2-009 L2P data products form the basic “building blocks” for all other GHRSST-PP data products and should ideally be made 

NASR 

available to the GHRSST-PP operational user community in real time within 6 hours after the reception of data at the 

satellite sensor. 

45 WP2-010 Each input SST data file is assessed pixel by pixel, using gross error checking rules. L2P.0020 

45 WP2-011 A configuration file is used to store all QC parameter limits and thresholds that will be revised as required. QLC.0020 

45 WP2-0120 Confidence data are extracted from native SST data streams if present and they are derived using auxiliary and reference 

data streams and sensor specific error statistics (SSES, generated by WP-ID7). 

L2P.0050 

CFD.0030 

45 WP2-013 For every L2P file that is generated, a L2P MMR_FR must be created and registered under the appropriate MMR_DSD at ING.0030 

© 2004 SOC Page 133 of 193




the GHRSST-PP MMR system as soon as possible. 

SR entry 

CTR.0550 

CTR.0580 

45 WP2-014 As the GHRSST-PP intends to generate global 1/12° L4 analysed SST data output from L2P data, high resolution ) input 

L2P.0090 

data sets may be averaged to a coarser resolution no greater than 1/12° in order to reduce data volume. It should be 

stressed that this is highly undesirable as it will impact the usefulness of L2P data sets within the coastal zone 

where 1km data may already be too coarse in certain areas characterised by dynamic temperature structures. 

45 WP2-015 GHRSST-PP High Resolution Diagnostic Data Set (HR-DDS) granules are extracted from L2P data, formatted and 

DDS.0030 

delivered to the GHRSST-PP HR-DDS system. 

45 WP2-016 If satellite SST data are unsuitable for further use in the GDS then a message is sent to the data provider and to the 

GHRSST-PP ERRLOG log (errlog@ghrsst-pp.org) informing why these data have not been used. 

ING.0100 

QLC.0035 

46 Inputs: 

46 WP2-017 1. Infrared and Microwave satellite SST data streams. L2P.0010 

46 WP2-018 2. Auxiliary satellite and NWP data streams. L2P.0010 

46 WP2-019 3. Reference data streams. 

46 WP2-020 4. GDS L2P configuration files. QLC.0020 

46 WP2-021 5. Error checking rules. QLC.0020 

46 Outputs: 

46 WP2-022 1. GHRSST-PP L2P data files. L2P.0070 

46 WP2-023 2. L2P MMR_FR metadata record. IMG.0030 

46 WP2-024 3. Error message sent to data provider and to the GHRSST-PP ERRLOG log (errlog@ghrsst-pp.org) as required. IMG.0100 

46 WP2-025 4. HR-DDS data granules extracted from L2P data. DDS.030 

46 Acceptance tests: 

© 2004 SOC Page 134 of 193




46 WP2-026 1. L2P output data products based on the GDS test input data set produced at each RDAC and GDAC should be 

SR entry 

ATPD 

identical to those produced by the GDS reference data processor. 

46 WP2-027 2. L2P measurement data are identical to the input SST data but with additional error and QC). ATPD 

46 WP2-028 3. HR-DDS data extraction is correct and data delivery interface is functional. ATPD 

46 WP2-029 4. Gross error checking procedures successfully flag unsuitable data and admit useful data with minimal data loss. ATPD 

46 WP2-030 5. Error messages to data provider and ERRLOG are correct and promptly delivered. ATPD 

46 WP2-031 6. MMR_FR metadata records are submitted in a timely manner. ATPD 

46 WP2-032 7. MMR_FR metadata records are accurate. ATPD 

46 Metric for performance assessment: 

46 WP2-033 1. L2P data files are correctly formatted. ATPD 

46 WP2-034 2. L2P data are produced in a timely manner (ideally within 6 hours from reception at satellite platform). ATPD 

46 WP2-035 3. L2P MMR_FR metadata records provided and ingested at MMR in real time. MMR rejection rate < 2%. ATPD 

CTR.0130 

46 WP2-036 4. Data provider promptly notified in case of problems with data stream. ATPD 

46 WP2-037 5. HR-DDS L2P extraction and format is correct. ATPD 

46 WP2-038 6. ERRLOG messages are correct and only reject problematic data. ATPD 

46 WP2-039 The purpose of this work package is to derive Level-2 Pre processed GHRSST-PP data files (L2P) through a process of 

NASR 

quality control and data merging. The principles for setting the quality flags and pre-processing algorithms for assigning 

quality flags are outlined in this section. 

46 WP2-040 The L2P processor identifies and flags problematic satellite SST data at an early stage of the GDS processing chain 

NASR 

leaving as much time as possible to correct faults and make use of the erroneous data later on in the processing system. 

46 WP2-041 The main difference between the input SST data file and the output L2P data file is that additional confidence data and L2P.0040 

© 2004 SOC Page 135 of 193




sensor specific error estimates for each pixel value have been included and the original SST data reformatted to netCDF 

format. 

SR entry 

L2P.0050 

L2P.0060 

46 WP2-042 No modification to the original SST data values has taken place during the conversion process. L2P.0080 

47 Footnote 

7 

WP2-043 Note that in the case of 1km input SST data streams, averaging of these data is permitted to provide data at a resolution 

of no greater than 1/12° latitude x longitude. In this case, there may be some modification to the original input data. 

L2P.0090 

47 WP2-044 L2P data products will be available to the operational user community in real time and ideally, within 6 hours following 

PER.SYS.0010 

reception at the satellite platform. 

47 WP2-045 However, as the GHRSST-PP intends to generate global 1/12° L4 analysed SST data output from L2P data files, high 

L2P.0090 

resolution input data sets may be averaged to a coarser resolution no greater than 1/12°. 

47 Figure 

WP2-046 Functional breakdown of WP-ID2 identifying each major sub task NASR 

5.1 

47 WP2-047 A functional breakdown diagram for WP-ID2 is shown in Figure 5.1 (additional functional breakdown diagrams are 

NASR 

provided for WP-ID2.1, WP-ID2.2 and WP-ID2.5 in the appropriate section below). 

47 WP2-048 In a series of pre-processing and quality control procedures, microwave and Infrared Satellite SST data are merged 

L2P.0030 

together with reference data and auxiliary data including satellite and NWP Wind speed, sea ice concentration, surface 

solar irradiance and aerosol optical depth estimates. 

47 WP2-049 If data processing problems are encountered the SST data file is rejected from the GDS, (e.g., values are outside of 

expected range, overwhelming cloud contamination) an error message is sent to the satellite SST data provider point of 

ING.0100 

QLC.0035 

contact (as defined in the GHRSST-PP MMR_DSD record associated with the SST data file) explaining why the SST data 

have not been used in the GDS. A copy of the message is also sent to the GHRSST-PP error log system (errlog@ghrsstpp.org). 

48 WP2-050 If the SST data are accepted into the GDS, L2P additional pixel confidence data are then derived for every SST L2P.0040 

© 2004 SOC Page 136 of 193




SR entry 

measurement. L2P confidence data are required to: 

48 WP2-051 1. Derive a quantitative ‘confidence value’ for each SST measurement that is used to identify reduced quality data. NASR 

48 WP2-052 2. Derive and interpret of SSES values assigned to each SST measurement. NASR 

48 WP2-053 3. Force parameterisations that estimate diurnal variability. NASR 

48 WP2-054 Using confidence data, Sensor Specific Error Statistics (SSES) are assigned to each SST measurement based on analysis 

L2P.0050 

of the GHRSST-PP Match-up Database (MDB) system described in WP-ID3. 

48 WP2-055 A L2P data file is generated (format described in Appendix A1.4) which contains the original SST data together with pixel 

L2P.0060 

confidence data. L2P data files are formatted as GDS netCDF files (WP-ID1.2.3) that are fully described in Appendix A1. 

48 WP2-056 For each L2P data file a MMR_FR metadata record (described in Appendix A6) is generated and registered at the MMR 

ING.0030 

under the appropriate MMR_DSD. 

48 WP2-057 L2P data files and pixel confidence data are identical in format for all input SST data streams with differs between the IR 

L2P.0060 

and MW SST data exist. Using a single data format for all SST data files greatly facilitates SST inter-comparison and 

merging activities within the GHRSST-PP. 

48 WP-ID2.1 Pre-processing and merging of auxiliary data. 

48 WP2-058 This work-package describes in detail common pre-processing operations performed on each IR and MW SST data file. 

MRG.0020 

Figure 5.2.1 provides a functional breakdown diagram that identifies each common pre-processing pixel based operation. 

These are: 

48 WP2-059 Check that the SST value lies within acceptable limits, if not then reject the data file QLC.0070 

48 WP2-060 Compute the pixel measurement time ING.0070 

48 WP2-061 Assign a fractional sea ice value if required MRG.0030 

48 WP2-062 Assign a wind speed value MRG.0040 

48 WP2-063 Assign a surface solar irradiance (SSI) value MRG.0050 

© 2004 SOC Page 137 of 193




SR entry 

48 WP2-064 Assign an Atmospheric Optical Depth (AOD) value MRG.0060 

48 WP2-065 The specific thresholds, limits and processing rules that are used to QC each data set are stored in a system wide L2P 

QLC.0020 

configuration file. This allows easy modification of critical values and other configurable parameters without the need for 

software code changes. 

48 WP2-066 As auxiliary data files are only used as indicators within the GDS, only simple QC tests are specified. NASR 

48 WP2-067 It is left to the RDAC and GDAC to determine the level of QC that is required to use these data with confidence. NASR 

48 WP2-068 Different pre-processing operations must be applied to IR and MW SST data and to each auxiliary data file. NASR 

49 Figure 

WP2-069 

Fig.5.2.1 Functional breakdown diagram of pre-processing and merging operations common to IR and MW SST data files. 

NASR 

5.2.1 

A L2P configuration file is used to store appropriate thresholds and reference values. 

49 WP-ID2.1.1 SST Climatology limit check 

49 WP2-070 This test is used to set the L2P confidence data record variable DT_min defined in Table A1.2.2 in Appendix A1. It 

identifies data that fall outside of acceptable range of global SST values and identifies unrealistic SST values. 

QLC.0070 

QLC.0080 

49 The GDS specifies the following rules: 

49 Rule 

WP2-071 

Rule 2.1.1a: A valid SST observation must lie within a temperature range of LowSSTLimit < SST < HighSSTLimit. If the 

QLC.0070 

2.1.1a 

pixel SST value is out of these limits, the observation must be rejected from the final L2P data file. 

QLC.0040 

49 Rule 

WP2-072 

Rule 2.1.1b: The difference between the pixel SST value (SSTobs) and the reference SST fied, SSTref (defined in 

QLC.0080 

2.1.1b 

Appendix A3, Table A3.1.1), DT_min is derived using: DT_min = SSTobs - SSTref (Eq. 2.1.1) The 

DT_min value should be inserted into the DT_min field of the L2P confidence data record for the pixel in question. 

49 WP2-074 This reference SST is SST1m derived as a 10 day “coldest” climatology from Pathfinder SST data products. SST values 

QLC.0080 

for a given location and season that are significantly beneath this climatological value indicate the presence of cloud 

contamination. 

50 WP-ID2.1.2 Compute SST measurement time 

© 2004 SOC Page 138 of 193




50 WP2-075 Most SST data files provide the time at which a SST measurement was acquired but some do not. The GHRSST-PP GDS 

SR entry 

ING.0070 

specifies that the time of measurement should be extracted or computed to the nearest minute and then coded as 

continuous UTC time coordinates using the following rules: 

50 Rule 

WP2-076 

Rule 2.1. 2a The time of the earliest SST measurement within this data set should be coded as a continuous time 

ING.0080 

2.1.2a 

coordinate specified as minutes from 00:00:00 UTC January 1, 1981 (start of the useful AVHRR SST data record) and 

entered into the netCDF data file global variable Start_Time. 

50 Rule 

WP2-077 

Rule 2.1.1.2b The time of SST measurement should be coded as the deviation in minutes from the netCDF data file global 

ING.0090 

2.1.1.2b 

variable Start_Time and entered into the L2P confidence record variable TimeDeviation. 

50 WP-ID2.1.3 Assign fractional sea ice value if required 

50 WP2-078 Some SST data are contaminated in part or wholly by sea ice. This procedure is used to set the L2P confidence data 

record variable FractionalSeaIce defined in Table A1.2.2 in Appendix A1. 

MRG.0070 

MRG.0080 

MRG.0090 

50 WP2-079 Some input SST data streams provide a flag to indicate that the SST measurement is contaminated by sea ice (e.g., 

MRG.0090 

AMSR-E). In cases where no such data are present in the input data stream a reference sea ice data product (defined in 

Appendix A3) should be used to assess the likelihood of sea ice contamination. The GDS specifies the following rules: 

50 Rule 

WP2-080 

Rule 2.1.3a If an input data set pixel fractional sea ice estimate exists, this should be used to set the FractionalSeaIce 

MRG.0070 

2.1.3a 

flag of the L2P confidence data record. 

50 Rule 

WP2-081 

Rule 2.1.3b If an input data set pixel sea ice flag exists (i.e. indicating sea ice but not ther fractional amount of coverage), 

MRG.0080 

2.1.3b 

this should be used to set the FractionalSeaIce flag of the L2P confidence data record to 100% according to the code 

values defined in Table A1.4.2 in Appendix A1. If the flag is a binary flag. a check should be made against the reference 

fractional sea Ice data set to determine if the pixel is likely to be 100% contaminated and the fraction reported by the 

reference data set should be set if it is < 100%. 

© 2004 SOC Page 139 of 193




SR entry 

50 Rule 

WP2-082 

Rule 2.1.3c If an input data set pixel sea ice flag does not exist, and the pixel is located in or close to a region that may be 

MRG.0090 

2.1.3c 

ice contaminated, the reference sea ice data sets defined in Appendix A3 should be used to determine the value of the 

L2P confidence flag FractionalSeaIce. 

50 Rule 

WP2-083 

Rule 2.1.3d The L2P confidence bitfield FractionalSeaIce_source must be set to indicate the data source used to set 

MRG.0110 

2.1.3d 

FractionalSeaIce using the values specified in Table 2.1.3. 

50 Rule 

WP2-084 

Rule 2.1.3e: If the SST input data set is derived from a microwave sensor and a sea ice flag is present in the data stream, 

MRG.0120 

2.1.3e 

bit 4 of the L2P confidence data variable MW_SST_flags should be set for this pixel. 

51 Table 

WP2-085 Code value for the source of the data used to assign the L2P confidence value FractionalSeaIce_source MRG.0110 

2.1.3 

51 WP-ID2.1.4 Assign wind speed data to L2P confidence record 

51 WP2-086 Wind speed measurements are required within the GDS to derive L2P SST proximity confidence values, for use in diurnal 

NASR 

variability correction schemes and to interpret the relationship between satellite and in situ SST data. 

51 WP2-087 At low wind speeds, especially in clear sky conditions, stronger diurnal variability is expected leading to higher surface 

NASR 

layer temperature gradients and the potential for significant de-coupling of the skin/sub-skin SST from the SST at depth. 

51 WP2-088 Ideally a near contemporaneous wind speed measurement from satellite sensors should be used but this is impossible for 

NASR 

all sensors due to the limited number of satellite wind speed sensors available. 

51 WP2-089 As a surrogate for a measured wind speed value, NWP estimates may be used as an indication of the surface wind 

NASr 

speed. 

51 WP2-090 The L2P confidence data record variable Wspd_value defined in Table A1.2.2 contains a best estimate of the surface 

MRG.0130 

wind speed at the time of SST data acquisition. 

51 WP2-091 A near contemporaneous wind speed estimate (an NWP field may be used here) is assigned to this field as an indicator of 

MRG.0130 

the turbulent state of the air sea interface. 

© 2004 SOC Page 140 of 193




51 WP2-092 The source of wind speed information must be specified in the L2P confidence data variable Wspd_source (defined in 

Table 2.1.4) and the difference in acquisition time between SST observation and wind speed measure must be specified in 

SR entry 

see next five 

rows 

the L2P confidence variable Wspd_Dtime_from_SST. 


51 Rule 

WP2-093 

Rule 2.1.4a: A 10m surface wind speed value should be assigned to each SST measurement pixel using the GDS L2P 

MRG.0130 

2.1.4a 

confidence data variable Wspd_value described in Table A1.2.2. As a general rule for the GDS v1.0, only simultaneous 

wind speed measurements should be used otherwise NWP analyses should be used. Future revisions of the GDS will 

most likely use near contemporaneous wind speed observations from other satellite instruments. 

51 Rule 

WP2-094 

Rule 2.1.4b: The source of data used to set the L2P confidence data variable Wspd should be indicated in the confidence 

Format 

2.1.4b 

variable Wspd_source as defined in Table 2.1.4. 

requirement 

51 Rule 

WP2-095 

Rule 2.1.4c: In the case of microwave SST measurements, the use of a simultaneous microwave 10m wind speed 

MRG.0150 

2.1.4c 

measurements obtained from the same instrument providing the SST measurement may be used. 

51 Rule 

WP2-096 

Rule 2.1.4d: In the absence of a simultaneous surface wind speed measurement, an NWP estimated 10m surface wind 

MRG.0160 

2.1.4d 

speed (See Appendix A3, Table A3.1.1) should be used to set the L2P confidence data variable Wspd_value. 

52 Rule 

WP2-097 

Rule 2.1.4e: The difference in time expressed in hours between the time of SST measurement and the time of wind speed 

MRG.0170 

2.1.4e 

measurement should be entered into the L2P confidence data variable Wspd_Dtime_from_SST. A value of 25 should be 

used to indicate unknown. 

52 Table 

2.1.4 

WP2-098 Code value for the source of the data used to assign the L2P confidence value Wspd_source Format 

requirement 

52 WP2-099 The following QC checks should be applied to all input wind speed data sets. The tests applied are simple tests designed 

QLC.0090 

to verify that wind speed data are within realistic limits. 

52 WP2-100 RDAC and GDAC may choose to implement more sophisticated QC procedures if deemed necessary. 

© 2004 SOC Page 141 of 193




SR entry 

52 WP-ID2.1.4.1 Gross wind speed limit check 

52 WP2-101 This test identifies wind speed values that fall outside of acceptable range of global wind speed values. The GDS specifies 

NASR 

the following rule: 

52 Rule 

WP2-102 

Rule 2.1.4.1: A valid wind speed observation must lie within a wind speed range of 0 

QLC.0090 

2.1.4.1 

speed values that fall outside this range are considered erroneous and should not be used within the GDS. 

52 WP2-103 The HighWindSpeed value is set in a L2P configuration file maintained at the RDAC and GHRSST-PP International 

QLC.0120 

Project Office. 

52 WP-ID2.1.5 L2P Surface Solar Irradiance (SSI) value assignment 

52 WP2-104 SSI measurements are required within the GDS to asses the magnitude and variability of significant diurnal SST variations, 

NASR 

for use in diurnal variability correction schemes, as part of the L4 SST analysis procedures and to interpret the relationship 

between satellite and in situ SST data. 

52 WP2-105 Ideally a near contemporaneous SSI measurement from satellite sensors should be used but this is impossible for all 

NASR 

areas due to the limited number of geostationary satellite sensors available. 

52 WP2-106 As a surrogate for a measured SSI value, NWP estimates may be used. MRG.0190 

52 WP2-107 This test is used to set the L2P confidence data record variable SSI_value defined in Table A1.2.2 in Appendix A1. MRG.0180 

MRG.0190 

52 WP2-108 Near contemporaneous SSI measurement, coded according to the definition provided in Appendix A1 Table A1.2.2 should 

MRG.0180 

be assigned to the L2P confidence data a record field SSI_value. 

52 WP2-109 The source of SSI information must be specified in the L2P confidence data variable SSI_source (defined in Table 2.1.5) 

MRG.0200 

and the difference in acquisition time between SST observation and SSI measure must be specified in the L2P confidence 

variable SSI_Dtime_from_SST. 

53 WP2-110 The GDS specifies the following rules: see next 5 rows 

© 2004 SOC Page 142 of 193




SR entry 

53 Rule 

WP2-111 

Rule 2.1.5a: A 6 hourly integrated downwelling SSI measurement (e.g., derived from satellite measurements) should be 

MRG.0180 

2.1.5a 

assigned to each SST pixel value using the SSI_value L2P confidence data variable. The SSI measurement nearest in 

space and time before the input pixel SST value should be used. 

53 Rule 

WP2-112 

Rule 2.1.5b: If no SSI measurement is available, a 6 hourly integrated SSI value derived from an NWP system (See 

MRG.0190 

2.1.5b 

Appendix A3) nearest in space and time to the SST measurement should be used to set the value of SSI_value. 

53 Rule 

WP2-113 

Rule 2.1.5c: The source of data used to set the L2P confidence data variable SSI_value should be indicated in the 

MRG.0200 

2.1.5c 

confidence variable SSI_source as defined in Table 2.1.5. 

53 Rule 

WP2-114 

Rule 2.1.5e: The difference in time expressed in hours between the time of SST measurement and the mean time of SSI 

MRG.0210 

2.1.5e 

measurement/data validity should be entered into the L2P confidence data variable SSI_Dtime_from_SST. A value of 25 

should be used to indicate unknown. 

53 Table 

WP2-115 Code value for the source of the data used to assign the L2P confidence value SSI_source MRG.0200 

2.1.5 

53 WP2-116 The following QC checks should be applied to all input SSI data sets that are used at RDAC and GDAC. These tests are 

see following 

simple tests designed to verify that SSI data are within realistic limits. RDAC and GDAC may choose to implement more 

sophisticated QC procedures if deemed necessary. 

53 WP-ID2.1.5.1 Gross SSI limit check 

53 WP2-117 This test identifies data that fall outside of acceptable range of global SSI values. The GDS specifies the following rule: NASR 

53 Rule 

2.1.5.1 

WP2-118 Rule 2.1.5.1: A valid 6 hourly integrated SSI observation/forecast must lie within a SSI range of 0 < SSI < 

HighSSIValue. SSI values that fall outside this range should not be used within the GDS. 

QLC.0100 

53 WP2-119 The HighSSIValue value is set in the L2P configuration file maintained at the RDAC and GHRSST-PP International 

QLC.0120 

Project Office. 

53 P-ID2.1.6 L2P Aerosol Optical Depth (AOD) value assignment 

© 2004 SOC Page 143 of 193




53 WP2-120 This test is used to set the L2P confidence data record variable AOD_value defined in Table A1.2.2 in Appendix A1. A 

SR entry 

MRG.0220 

near contemporaneous AOD measurement, coded according to the definition provided in Appendix A1 Table A1.2.2 should 

be assigned to the L2P confidence data a record field AOD_value. 

53 WP2-121 The source of AOD information must be specified in the L2P confidence data variable AOD_source (defined in Table 

MRG.0240 

2.1.6) and the difference in acquisition time between SST observation and AOD measure must be specified in the L2P 

confidence variable AOD_Dtime_from_SST. 


54 Rule 

WP2-122 

Rule 2.1.6a: A L2P AOD measurement (e.g., derived from satellite measurements) should be assigned to each SST pixel 

MRG.0220 

2.1.6a 

value using the AOD_value L2P confidence data variable. The AOD measurement nearest in space and time to the input 

pixel SST value should be used. 

54 Rule 

WP2-123 

Rule 2.1.6b: If no AOD measurement is available, an AOD value derived from an NWP system or aerosol forecast (See 

MRG.0230 

2.1.6b 

Appendix A3) nearest in space and time to the SST measurement should be used to set the value of AOD_value. 

54 Rule 

WP2-124 

Rule 2.1.6c: The source of data used to set the L2P confidence data variable AOD_value should be indicated in the 

MRG.0240 

2.1.6c 

confidence variable AOD_source as defined in Table 2.1.6. 

54 Rule 

WP2-125 

Rule 2.1.6d: The difference in time expressed in hours between the time of SST measurement and the time of AOD 

MRG.0250 

2.1.6d 

observations/analysis should be entered into the L2P confidence data variable AOD_Dtime_from_SST. A value of 25 

should be used to indicate unknown. 

54 Table 

WP2-126 Code value for the source of the data used to assign the L2P confidence value AOD_source MRG.0240 

2.1.6 

54 WP2-127 The following QC checks should be applied to all input AOD data sets. NASR 

54 WP2-128 The tests applied are simple tests designed to verify that AOD data are within realistic limits. NASR 

54 WP2-129 RDAC and GDAC may choose to implement more sophisticated QC procedures if deemed necessary. EXP.SYS.0100 

© 2004 SOC Page 144 of 193




SR entry 

54 WP-ID2.1.6.1 Gross AOD limit check 

54 WP2-130 This test identifies AOD values that fall outside of acceptable range of global AOD values. The GDS specifies the following 

NASR 

rule: 

54 Rule 

WP2-131 

Rule 2.1.6.1: A valid AOD observation/estimate must lie within a range of LowAODLimit 

QLC.0110 

2.1.6.1 

values that fall outside this range are considered erroneous and should not be used within the GDS. 

54 WP2-132 The LowAODLimit and HighAODLimit values are set in a L2P configuration file maintained at the RDAC and GHRSST- 

QLC.0120 

PP International Project Office. 

54 WP-ID2.2 Derivation of L2P confidence data and assignment of Sensor Specific Error Statistics (SSES). 

54 WP2-133 Due to characteristic differences between SST data sets derived from infrared and microwave sensors, the optimal 

CFD.0050 

assignment of error and confidence data for each measurement is different. 

54 WP2-134 In the case of infrared SST data sets, data are stratified according to their proximity to cloud and by wind speed (used to 

CFD.0320 

identify conditions favourable to stratification). 

54 WP2-135 Bias and standard deviation errors are assigned based on an analysis of the GHRSST-PP match-up database (MDB). L2P.6020 

54 WP2-136 A proximity confidence value is specified for each pixel based on the “proximity” of that pixel to several different criteria 

CFD.0320 

known to have a derogatory effect on the final SST value that is reported. 

55 WP2-137 The L2P confidence data record variable Proximity_Confidence defined in Table A1.4.2 in Appendix A1 is used to 

CFD.0320 

statistically derive and assign Sensor Specific Error Statistics (SSES) error estimate for each SST measurement. 

55 WP2-138 A long time series of data will be developed within the GHRSST-PP Match-up database (MDB) (containing limited 

NASR 

geographical coverage of in situ SST and L2P data) that are analysed on a regular (weekly/monthly) basis according to 

sensor and Proximity_Confidence values to derive that provide a mean bias and standard deviation value that can then 

be applied to all other SST measurements having the same Proximity_Confidence value thereby maximising the use of 

the limited coverage of the in situ observations. The technique relies on the fact that SST measurements are generally of a 

© 2004 SOC Page 145 of 193




SR entry 

reduced quality (and are therefore likely to have larger errors) the closer they are to other measurements that have been 

flagged as erroneous. 

55 WP2-139 The GDS specifies separate schemes to derive Proximity_Confidence values for infrared and microwave SST data 

CFD.0050 

streams. 

55 WP2-140 For SST data derived from infrared radiometers, sub-pixel cloud and wind speed are the main factors influencing the 

NASR 

quality of SST measurements. 

55 WP2-141 However, extremely large errors may be associated with atmospheric aerosol contamination due to dust storms or volcanic 

NASR 

eruptions that have an immediate and widespread impact. This type of error is not considered in the GDS-v1.0 but will be 

included in a revised GDS once v1.0 is operating. 

55 WP2-142 For microwave SST data streams, the proximity to rainfall, side lobe contamination in the proximity of land, high wind 

CFD.0100 

speed regimes modifying the surface emissivity of seawater in the 6-11 GHz frequency, radio frequency interference and 

proximity to sea ice are the main factors influencing the Proximity_Confidence value and the quality of SST retrieval. The 

approach adopted for the GDS-v1.0 is to flag suspect data in close proximity to rain, land, sea ice and at high wind speeds. 

55 WP2-143 Bias errors are assigned based on an analysis of the GHRSST-PP MDB. Standard deviation error increments associated 

CFD.0020 

with each error source are statistically derived based on look-up tables generated by the data provider (Remote Sensing 

Systems) and through analysis of the MDB. 

55 WP-ID2.2.1 Derivation of L2P confidence data and assignment of SSES for Infrared SST data sets. 

55 WP2-144 Figure 2.2.1.1 shows a functional breakdown diagram of the processing operations required to derive L2P confidence data 

NASR 

and assign SSES for infrared SST data files. 

55 WP2-145 Initially, a series of quality control checks are performed on pixel-by-pixel bases that are designed to reject suspect data 

QLC-0045 

from the GDS. 

55 WP2-146 Proximity confidence values are then derived and SSES are assigned to each measurement. SSES are fully described in see lower down 

© 2004 SOC Page 146 of 193




SR entry 

WP-ID3. 

55 WP-ID2.2.1.1 Cosmetic data test 

55 WP2-147 Some SST data streams contain pixel values that are cosmetic rather than measured in order to provide a complete data 

see WP2-149 

product. For example, the ENVISAT ATS_NR__2P data stream may contain cosmetically filled pixels. These data are 

used to fill in data gaps across the swath following rectification of the curved ground swath made by the conical scan 

geometry used by the instrument. 

56 WP2-148 The purpose of this test is to extract the status of an input SST flag (if such a flag is present in the native input data 

NASR 

stream) and to reject all data that have been derived rather than measured by a sensor. 

56 The following GDS rule is specified: 

56 Rule 

WP2-149 

Rule 2.2.1.1: If an input SST data stream includes information that indicates that a pixel value is cosmetic rather than 

QLC.0050 

2.2.1.1 

measured, these data should be rejected from the L2P data file. 

56 Figure 

WP2-150 

Functional breakdown diagram of data processing steps to produce L2P data records for infrared satellite SST 

NASR 

2.2.1.1 

data files. 

56 WP2-151 WP-ID2.2.1.2 Cloud flag test 

56 WP2-152 Many input SST data streams provide a flag or a data value indicating that the input pixel is cloudy. The GDS specifies the 

NASR 

following rule: 

56 Rule 

WP2-153 

Rule 2.2.1.2: If an input SST pixel data value or associated confidence data indicate the pixel to be cloudy, these data 

QLC.0060 

2.2.1.2 

should be rejected from the L2P data file. 

56 WP-ID2.2.1.3 Sun glint test 

56 WP2-154 This test is used to set the L2P confidence data record variable SunGlint defined in Table A1.2.2 in Appendix A1. CFD.0300 

56 WP2-155 Depending on the local wind speed and sensor-sun view-geometry, sun-glint areas may be present in satellite SST data 

NASR 

streams. Normal sun glint occurs in reflection from the oceans when the sun is behind and to the side of the satellite. 

© 2004 SOC Page 147 of 193




56 WP2-156 Sun glint may degrade the SST value retrieved by affecting the quality of the cloud mask used by an infrared radiometer 

and consequently these regions should be flagged. 

56 WP2-157 Note that for polar orbiting satellite systems the problem is quite limited, but for geosynchronous orbit sensors it is 

SR entry 

CFD.0300 

CFD.0310 

NASR 

unavoidable. 


57 Rule 

WP2-158 

Rule 2.2.1.3a: If an indication of sun-glint is provided with an input SST pixel value, this should be used to set the 

CFD.0300 

2.2.1.3a 

SunGlint flag of the corresponding L2P confidence data record. 

57 Rule 

WP2-159 

Rule 2.2.1.3b: If an indication of sun-glint is not provided with an input pixel value, an appropriate method should be used 

CFD.0310 

2.2.1.3b 

to set the SunGlint flag of the L2P confidence data record that is based on the geometry of sun and satellite position and 

surface roughness (e.g., Gardashov and Barla, 2001). 

57 WP-ID2.2.1.4 Derivation of Infrared Proximity Confidence Values (IPCV) 

57 WP2-160 The major source of error associated with infrared SST data sets is contamination by cloud due to poor cloud clearing 

CFD.0320 

techniques or particularly difficult environmental conditions (e.g., clouds are sub-pixel in size, SST is highly dynamic 

(coastal zone), thin cirrus cloud is present or low lying fog) that are difficult to detect using current algorithms. For the GDS 

v-1.0, IPCV are determined as a function of deviation from a minimum SST climatology (as cloud contaminated SST are 

cooler than surrounding waters) and distance from the nearest cloud flagged pixel (as smaller clouds are often found in 

close proximity to larger clouds). This type of approach is successfully used at the EUMETSAT O&SI SAF (Brisson et al., 

2001) and as part of the US Navy NAVOCEANO operational SST processing system. 

57 WP2-161 The GDS-v1.0 IPCV scale is defined in Table 2.2.1.4. CFD.0320 

57 Table 

WP2-162 Infrared proximity confidence value (IPCV) scale definitions. CFD.0320 

2.2.1.4 

57 WP2-163 Figure 2.2.1.4.1 presents a schematic lookup table describing how IPCV values are assigned. In this figure, four DT_min CFD.0320 

© 2004 SOC Page 148 of 193




SR entry 

thresholds (IPCVThresh1 - IPCVThresh3) and two cloud proximity distances (IPCV_D1 and IPCV_D2) delineate the set of 

data that correspond to the confidence scale provided in Table 2.2.4.1. 

57 WP2-164 It is expected that the IPCV scale will be expanded to identify an additional scheme that can be used to identify areas of 

NASR 

diurnal stratification based on the difference between the previous analysis field and the observations and the SSI. 

57 WP2-165 IPCV values are derived by considering the following GDS rules that have been found sufficient to identify most poor 

NASR 

quality data (Brisson et al., 2001): 

57 Rule 

WP2-166 

Rule 2.2.1.4a: Typically, sub-pixel clouds often contaminate data immediately adjacent to cloudy areas. The spatial 

CFD.0340 

2.2.1.4a 

distance, D (expressed in km) of an SST observation to clearly flagged cloud contaminated areas is used to identify these 

measurements. Two threshold values set by the GDS, IPCV_D1 and IPCV_D2, for each L2P data stream. The distance 

IPCV_D2 is set on the assumption that cloudy pixels beyond this distance do not influence the SST measurement. The 

distance IPCV_D1 is set assuming that cloudy pixels where IPCV_D1 < nearest_cloudy_pixel < IPCV_D2 have a 

reasonable probability of being cloud contaminated. Pixels within a distance less than D1 are assumed to have a high 

probability of cloud contamination. D values will depend on the spatial resolution and the geometry of each individual 

satellite sensor and must be established for each sensor. For example, D values for geostationary observations of 5km will 

be different from polar orbiting radiometer data of 1.1km. 

57 Figure 

WP2-167 

Schematic diagram showing how IPCV values are derived based on the deviation from a minimum SST climatology 

CFD.0330 

2.2.1.4.1 

defining the coolest expected SST value and the distance from the nearest cloud flagged pixels. 

CFD.0320 

58 Rule 

WP2-168 

Rule 2.2.1.4b: The second IPCV test uses the deviation from a minimum SST climatological value defined in the L2P 

CFD.0350 

2.2.1.4b 

confidence data record variable DT_min discussed in Section WP-ID2.1. Three threshold values for DT_min will be set by 

the GDS L2P configuration file IPCVThresh1 - IPCVThresh3. 

58 Rule 

WP2-169 

Rule 2.2.1.4c: A static map of upwelling regions may be used to decide if a pixel is cloud contaminated in the case of IPCV 

CFD.0360 

2.2.1.4c 

value 6. Maps will be developed by RDAC as appropriate for each region of interest. 

© 2004 SOC Page 149 of 193




58 WP2-170 Note that the actual values for IPCVThres1-3 and IPCV_D1 and IPCV_D2 are expected to vary for each sensor (Brisson 

SR entry 

CFD.0370 

et al., 2001) and the exact value of these parameters is a subject of on-going research and development within the 

GHRSST-PP. IPCVThres1-3, IPCV_D1 and IPCV_D2 values will be maintained by the GHRSST-PP International Project 

Office and stored in the L2P configuration file that is specific to each RDAC or GDAC. 

58 WP2-171 The derivation of these values will initially use best estimates until a sufficiently large population of data within the 

CFD-0320 

GHRSST-PP MDB is available (e.g., those suggested by Brisson et al. (2001). 

58 WP2-172 The filename of this configuration file should be written into each L2P file using the optional global netCDF attribute 

“References” as described in Appendix A1.2.1. 

Format 

requirement 

58 WP2-173 It is expected that the methodology used to derive IPCV may be modified in the GDSv2. EXP.L2P.0030 

59 WP-ID2.2.1.5 Assign Sensor Specific Error Statistic 

59 WP2-174 This processing step is used to assign the L2P confidence data record variable bias and sd defined in Table A1.2.2 in 

Appendix A1. 

L2P.6010 

L2P.6020 


59 Rule 

WP2-175 

Rule 2.2.1.5a: If pixel bias error and sd error statistics are provided by a data provider, these values may be assigned to 

L2P.6010 

2.2.1.5a 

the L2P bias and sd variables respectively. In this case, the L2_native_bias and L2_native_sd flags of the 

corresponding L2P confidence data record should also be set as these error estimates are independent of GHRSST-PP 

methods. 

59 WP2-176 If native bias and sd error values are not available or an RDAC chooses to ignore the error statistics provided by a data 

provider, these must be assigned based on the L2P Proximity_Confidence variable using sensor specific error statistics 

L2P.6020 

CFD.0020 

(SSES) as described in WP-ID3. In this case the L2_native_bias and L2_native_sd. flags of the corresponding L2P 


59 The GDS specifies the following rule: 

© 2004 SOC Page 150 of 193




SR entry 

59 Rule 

WP2-177 

Rule 2.2.1.5b: If pixel bias error and sd error statistics are not available for SST measurements, these values should be 

L2P.6020 

2.2.1.5b 

assigned the most recent SSES bias and sd values for the each data stream and L2P confidence data record 

Proximity_Confidence value. In addition, the L2_native_bias and L2_native_sd. flags of the corresponding L2P 


59 WP2-178 It is expected that the IPCV and SSES schemes will develop considerably throughout the GHRSST-PP. EXP.L2P.0030 

59 WP-ID2.2.2 Quality control of satellite MW SST data sets and assignment of pixel confidence data. 

59 WP2-179 SSES and L2P confidence and data must be derived for every MW SST measurement contained within an input SST data 

stream. 

see 

lines 

following 

59 WP2-180 The processing is different from infrared data streams since the native MW fields already contain wind speed, rain, and 

CFD.0050 

other ancillary parameters required to calculate the coded bitfields identifying suspect pixels. 

59 WP2-181 Specific thresholds, limits, reference files, and processing rules that are used to process each data set are stored in a 

CFD.0220 

system wide L2P microwave L2P configuration file. 

59 WP2-1820 This allows easy modification of critical values and other configurable parameters without the need for software code 

CFD.0220 

changes. 

59 WP2-183 Figure 2.2.2.1 shows a functional breakdown diagram of the processing steps required to derive confidence data and 

NASR 

assign SSES to microwave SST measurements. 

59 WP2-184 The output of these processing steps is a GHRSST-PP L2P netCDF data file described in Appendix A1.4. format 

59 WP2-185 Table A1.4.2 in Appendix A1 describes the format of GDS L2P pixel confidence data records. format 

59 WP2-186 The following sections describe in detail the MW QC tests and pre-processing operations performed on each data file. NASR 

59 WP-ID2.2.2.1 SST Climatology limit check 

59 WP2-187 This test is identical to 2.1.1 described above. QLC.0070 

QLC.0080 

© 2004 SOC Page 151 of 193




SR entry 

60 Figure 

WP2-188 

Functional breakdown diagram of data processing steps to produce L2P data records for microwave satellite SST 

NASR 

2.2.2.1 

data files. 

60 WP-ID2.2.2.2 Test for possible sidelobe contamination 

60 WP2-189 Microwave SST observations within about 50 to 100 km from land and sea ice are affected by the warm emission of land 

NASR 

and ice entering the antenna side-lobes. The effect varies by region and season (e.g., in monsoon climates where more 

contamination is expected in wet ground conditions) and is difficult to quantify without having access to engineering data 

provided by the satellite sensor. 

60 WP2-190 It cannot be quantified using buoy match-ups in the coastal zone. NASR 

60 WP2-191 Instead, global reference maps identifying regions with persistent sidelobe contamination will be generated by Remote 

NASR 

Sensing Systems to provide an estimate the retrieval error in coastal zones and near sea ice margins. 

60 WP2-192 The geolocation of each pixel will be used to look up possible contamination from the reference map. NASR 

61 WP2-193 Since the effect is different for the 10.7 GHz and 6.9 GHz retrievals, it must be calculated separately for TMI and AMSR-E 

NASR 

radiometers. We will approach this problem in two ways. Initially, TMI will be collocated with VIRS infrared SSTs while 

AMSR-E will be collocated with MODIS SST retrievals. The bias and variability in the STD will be calculated as the STD as 

a function of geographic location minus the minimum STD as a function of geographic location. This may be done using 

only retrievals within 200 km of land or ice or it may be done globally. There are several issues with this methodology that 

should be considered. There will be some overlap with dependencies on SST and wind speed. If the check is only used 

close to land, it will ignore possible side-lobe effects near frontal features, but if it is used globally, increased variability from 

the IR sensors due to water vapour or stray light will be included. It is expected that further work will be required to 

establish the optimum configuration of sidelobe contamination maps. 


61 Rule WP2-194 · Rule 2.2.2.2a: If a pixel is located within an area of known sidelobe contamination as defined by sensor specific CFD.0110 

© 2004 SOC Page 152 of 193




SR entry 

2.2.2.2a 

sidelobe contamination maps, bit 0 of the L2P confidence data variable MW_SST_flags should be set. 

61 Rule 

WP2-195 

· Rule 2.2.2.2b: If a sidelobe contamination map is not available, any pixel within sidelobe_distance_threshold 

CFD.0120 

2.2.2.2b 

(specified in the L2P configuration file in km) d should flagged as contaminated. 

61 WP-ID2.2.2.3 Strict test for possible rain contamination 

61 WP2-196 SST cannot be retrieved in raining conditions and data flagged as rain contaminated must be rejected from the L2P data 

QLC.0065 

file. The GDS specifies the following rule: 

61 Rule 

WP2-197 

· Rule 2.2.2.3: If a measurement is identified as rain contaminated in the native data input file, this measurement 

QLC.0065 

2.2.2.3 

should not be included in a L2P data file. 

61 WP-ID2.2.2.4 Relaxed test for possible rain contamination 

61 WP2-198 A recognized problem in the MW SST retrievals is unidentified rain contamination in the SST, often nearby raining pixels. 

NASR 

Low rain rates or small areas of rain within the large MW footprint are difficult to identify and in many cases, the quality of 

SST retrievals surrounding a rain flagged pixel are degraded by unresolved rain. 

61 WP2-199 For this reason, pixels within a defined radius relaxed_MW_rain_distance (specified in km and held within the L2P 

CFD.0140 

configuration file) of a raining pixel will be flagged as potentially rain contaminated. 

61 WP2-200 In addition, a comparison of the previous analysed SST values will be used to reject or accept the measurement for 

CFD.0150 

inclusion within a L2P file if the difference is greater than a predefined threshold specified in K and held in the L2P 

configuration file variable relaxed_rain_threshold. 


61 Rule 

WP2-201 

· Rule 2.2.2.4a: If a pixel lies within a radius of relaxed_MW_rain_distance specified in km of a clearly flagged rain 

CFD.0140 

2.2.2.4a 

contaminated pixel, bit 1 of the L2P confidence data variable MW_SST_flags should be set. 

61 Rule 

WP2-202 

· Rule 2.2.2.4b: If the difference between the most recent GHRSST-PP analysis SST and the potentially 

CFD.0150 

2.2.24b 

contaminated pixel is greater than relaxed_rain_threshold (K), the pixel should not be included in a L2P data file. 

© 2004 SOC Page 153 of 193




SR entry 

62 WP-ID2.2.2.5 TMI SST retrieval below 285 K 

62 WP2-203 TMI retrieves SST primarily from the 10.7 GHz channel, which has decreased sensitivity (and therefore increased error) at 

CFD.0160 

SSTs below 285K. Although the bias at lower temperatures is negligible, the standard deviation increases (as reflected in 

the SSES). TMI data having retrievals below 285K must be flagged according to the following GDS rule: 

62 Rule 

WP2-204 

· Rule 2.2.2.5: If a TRMM TMI SST measurement value is less than 285K, bit 2 of the L2P confidence data variable 

CFD.0160 

2.2.2.5 

MW_SST_flags should be set. 

62 WP-ID2.2.2.6 High Wind retrieval, above 12 ms -1 

62 WP2-205 Uncertainties in the emissivity model at high winds and increased errors in the directional model, result in larger errors 

CFD.0170 

above 12 ms -1 . These errors should not vary temporally or spatially since they are due to uncertainty in the estimate of 

emissivity. Although this increased error will be reflected in the SSES, some data users may chose to simply exclude these 

retrievals as suspect. 


62 Rule 

WP2-206 

· Rule 2.2.2.6a: If a microwave wind speed measurement contemporaneous with a microwave SST measurement is 

CFD.0170 

2.2.2.6a 

greater than 12 ms -1 , bit 3 of the L2P confidence data variable MW_SST_flags should be set. 

62 Rule 

WP2-207 

· Rule 2.2.2.6b: If a contemporaneous microwave wind speed measurement is unavailable, the nearest NWP analysis 

CFD.0180 

2.2.2.6b 

in space and time toi the SST measurement should be used to evaluate Rule 2.2.2.6a. 

62 WP-ID2.2.2.7 Derive a Microwave Proximity Confidence Value (MPCF) 

62 WP2-208 MPCV data are analogous to Infrared Proximity Confidence Values (IPCV) and provide a method to better understand the 

CFD0210 

character of microwave SST and their relationship to the SST1m. Microwave SST measurements are known to be of a 

reduced quality when they are in close proximity to clearly flagged rainfall, due to side lobe contamination in the proximity 

of land and sea ice. Also, at wind speeds < 2 ms -1 , a cool skin effect may also exist whereas at high wind speeds the 

emissivity model used to derive SST is poorly defined. These factors may be used to derive a Proximity_Confidence 

© 2004 SOC Page 154 of 193




SR entry 

value for microwave SST retrievals that can then be used to derive a MPCV for use within the GHRSST-PP MDB and 

ultimately the assignment of SSES for MW SST data. The initial MPCV scheme proposed for the GDS is based on the 

following criteria: 

62 WP2-2090 1. Physical distance of an SST measurement from the nearest rain flag. CFD0200 

62 WP2-210 2. Physical distance of an SST measurement from nearest land. CFD0200 

62 WP2-211 3. Physical distance of an SST measurement from nearest sea ice (held in bit 4 of MW_SST_flags). CFD.0190 

62 WP2-212 4. Conditions when the surface wind speed is > 12 ms -1 and is likely to modify the emissivity conditions of the sea surface 

CFD.0170 

in the 6-11GHz frequency range. 

62 WP2-213 5. Low wind speed conditions < 2ms -1 when a cool skin/warm layer effect may be present. 

62 WP2-214 6. For the special case of TMI SST, conditions when the SST is < 285K. CFD0160 

63 WP2-215 The proposed scheme is an initial configuration for MPCV and further research is required within the GHRSST-PP to 

NASR 

establish an optimal scheme, which should be undertaken at RDAC once sufficient data are available within the GHRSST- 

PP MDB. 

63 The MPCV scale is shown in Table 2.2.2.7.1. 

63 Table 

WP2-216 Microwave proximity confidence value (MPCV) scale definitions. CFD.0210 

2.2.2.7.1 

63 WP2-217 If any of the test bitflags are set for the MW retrieval, the data will be flagged as questionable. CFD.0210 

63 WP2-218 In addition two surface wind speed threshold values are used to delineate the wind speed conditions for which the best 

SST retrievals and relationship to the in situ observations is expected using the threshold parameters MPCV_wind1 and 

CFD.0210 

CFD.0220 

MPCV_wind2. 

63 WP2-219 The values for MPCV_windn shown in Figure 2.2.2.7.1 are expected to vary for a given sensor and the exact value of 

CFD.0220 

these parameters is a subject of on-going research and development within the GHRSST-PP. 

© 2004 SOC Page 155 of 193




63 WP2-220 Finally, the physical distance in km specified in the L2P configuration file variable MPCV_proximity is used to identify 

pixels that are far away from contaminating effects of sea ice (flagged in WP-ID2.1.3). 

SR entry 

CFD.0190 

CFD.0220 

CFD.0210 

63 WP2-221 All threshold values will be stored in a L2P configuration file specific to each RDAC or GDAC and maintained at the 

GHRSST-PP international project office that can be modified based on an assessment of sensor specific values. 

CFD.0220 

EXP.L2P.0050 

63 WP2-222 This will only be possible once the GHRSST-PP MDB has sufficient data available for analysis. EXP.L2P.0050 

63 WP2-223 The filename of this configuration file should be written into each L2P file using the optional global netCDF attribute 

format 

“References” as described in Appendix A1.2.1. 

63 WP2-224 It is expected that the methodology used to derive MPCV will be modified based on experience in the GDSv2. EXP.L2P.0040 

64 Figure 

WP2-225 

Schematic diagram showing the initial scheme (GDS-v1.0) proposed to derive MPCV values. Note that the TMI is 

see Fig. 3-2 of 

2.2.2.7.1 

subject to an additional lookup based on the actual SST value which is not shown. 

SRD 

64 WP-ID2.2.2.8 Assign L2P Sensor Specific Error Statistics 

64 WP2-226 This processing step is used to assign the L2P confidence data record variable bias and sd defined in Table A1.2.2 in 

see below 

Appendix A1. The GDS specifies the following rules: 

64 Rule 

WP2-227 

Rule 2.2.2.8a: If pixel bias error and sd error statistics are provided by a data provider, these values may be assigned to 

L2P.6010 

2.2.2.8a 

the L2P bias and sd variables respectively. In this case, the L2_native_bias and L2_native_sd flags of the 

corresponding L2P confidence data record should also be set as these error estimates are independent of GHRSST-PP 

methods. 

64 WP2-228 If native bias and sd error values are not available or an RDAC chooses to ignore the error statistics provided by a data 

provider these must be assigned based on the L2P Proximity_Confidence (MPCV) variable using sensor specific error 

L2P.6020 

CFD.0020 

statistics (SSES) as described in WP-ID3. In this case the L2_native_bias and L2_native_sd. flags of the corresponding 

L2P confidence data record should be set to zero. 

© 2004 SOC Page 156 of 193




SR entry 


Rule 

WP2-229 

Rule 2.2.2.2b: If pixel bias error and sd error statistics are not available for SST measurements, these values should be 

L2P.6020 

2.2.2.2b 

assigned the most recent SSES bias and sd values for each data stream and pixel Proximity_Confidence value. In 

addition, the L2_native_bias and L2_native_sd. flags of the corresponding L2P confidence data record should be set to 

zero. 

WP2-230 It is expected that the MPCV and SSES schemes will develop considerably throughout the GHRSST-PP. EXP.SYS.0100 

WP-ID2.3 Evaluate L2P data 

64 WP2-231 Each RDAC and GDAC centre will evaluate whether or not a L2P data set should be admitted to the GDS processor based 

L2P.7000 

64 WP-ID2.3.1 Reject L2P data file 

on objective criteria Including completeness, timeliness and quality. 

64 WP2-232 If a L2P data file has been rejected by an RDAC/GDAC, an error message must be raised and logged at the GHRSST-PP 

CTR.0550 

ERRLOG system as described in Appendix A7.2. 

64 WP2-233 No MMR_FR metadata are prepared for rejected L2P data streams. CTR.0550 

64 WP-ID2.3.2 Accept L2P data file 

64 WP2-234 If a L2P data file is accepted for further use in the GDS, then a L2P data file should be generated as described in WP- 

L2P.7000 

ID2.4. 

64 WP2-235 A corresponding MMR_FR metadata record should be generated as specified in WP-ID2.5. CTR.0530 

64 WP-ID2.4 Format L2P data file 

64 WP2-236 Each L2P data set should be prepared, formatted and archived as a netCDF file following the data format described in 

L2P.0060 

Appendix A1.2 and A1.4. 

64 WP-ID2.5 Generate and register L2P MMR_FR metadata record 

64 WP2-237 For each L2P data a corresponding MMR_FR must be prepared by the responsible RDAC/GDAC processor and registered CTR.0530 

© 2004 SOC Page 157 of 193




SR entry 

at the MMR as soon as the L2P data become available to the user community. 

65 WP-ID2.5.1 Format L2P MMR_FR metadata record 

65 WP2-238 A MMR_FR metadata record should be prepared for each L2P data file according to the specification provided in Appendix 

CTR.0530 

A6.2. 

65 WP-ID2.5.2 Register L2P MMR_FR metadata record with MMR system 

65 WP2-239 MMR_FR metadata records should be delivered to the MMR system as soon as possible after the L2P data set has been 

CTR.0580 

evaluated following the procedure described in Appendix A6.4. 

65 WP2-240 RDAC should aim to register MMR_FR records within 60 minutes of L2P data production in order that users are informed 

CTR.0580 

in a timely manner. 

65 WP2-241 It is recognised that, if the MMR_FR record is submitted by e-mail, delays in registration are beyond the control of the 

CTR.0110 

RDAC. At the 4 th GHRSST-PP Science Team workshop, it was proposed to enable MMR data records to be delivered to 

the MMR via ftp push from the RDAC to circumvent this problem. 

67 WP-ID3 The GHRSST-PP Matchup Data base (MDB) and derivation of Sensor Specific Error Statistics (SSES) 

Description: 

67 WP3-001 This WP describes the GHRSST-PP match up database system (MDB) and the MDB data records that should be 

NASR 

produced at each RDAC. 

67 WP3-002 The GDS requires that error estimates are assigned to every satellite SST measurement during the derivation of L2P data 

NASR 

products. As an in situ observation is not available for every SST measurement, Sensor Specific Error Statistics (SSES) 

are derived by a statistical analysis of MDB data records for a given sensor type and time period. SSES consist of a 

statistical mean bias and standard deviation (sd.) error estimate that is correlated to the mean L2P Proximity_confidence 

value for a given sensor. These values are then assigned to all L2P measurements that have the same 

Proximity_confidence value. 

© 2004 SOC Page 158 of 193




SR entry 

67 WP3-003 In addition, The MDB system also provides a resource that can be used to validate GHRSST-PP data products. NASR 

67 WP3-004 In the case of microwave SST, the derivation of SSES also requires that error components are assigned to each pixel 

NASR 

based on static look-up-tables of mean error due to sidelobe contamination, proximity to rain and wind speed. These 

tables will be provided by Remote Sensing Systems (RSS) for the TMI and AMSR-E (and in the future, Windsat) 

microwave instruments. 

67 WP3-005 The main source of in situ observations used in this system will be those available from the GTS supplied through 

NASR 

international in situ data centres (e.g., MED, CORIOLIS, FNMOC) at which QC procedures are used to filter out poor 

quality data. 

67 WP3-006 These data centres only provide in situ observations in a delayed mode (typically 24-72 hours, although delays may be 

MDB.0010 

longer than this) and therefore RDAC and GDAC can only provide MDB records in a delayed mode. 

67 WP3-007 RDAC are expected to arrange access to regional in situ data sources that are not available via the GTS system but can 

MDB.0120 

be included in the MDB system. 

67 WP3-008 The GHRSST-PP reanalysis project will be able to make use of other in situ observations that are unavailable in a NRT 

NASR 

mode. 

inputs 

68 WP3-009 • L2P data files MDB.0040 

68 WP3-010 • In situ ocean-atmosphere measurements from buoys, drifters and ships MDB.0020 

68 WP3-011 • SSES configuration file NASR 

68 WP3-012 • Static Look-up-Table (LUT) of microwave SST sidelobe contamination error NASR 

68 WP3-013 • Static LUT of microwave SST rain contamination errors NASR 

68 WP3-014 • Static LUT of microwave SST wind speed errors NASR 

outputs 

© 2004 SOC Page 159 of 193




SR entry 

68 WP3-015 • MDB records delivered to the GHRSST-PP MDB CTR.0580 

68 WP3-016 • SSES for each sensor derived on a on a regular basis NASR 

Acceptance tests 

68 WP3-017 • MDB records are formatted correctly and are delivered to the GHRSST-PP MDB system ATPD 

68 WP3-018 • SSES analysis is performed on a weekly basis and SSES are published to all RDAC and via the GHRSST-PP UIS ATPD 

Metric for performance assessment: 

68 WP3-019 • MDB records are produced in a timely manner using a target of within 24 hours from when the in situ data are made 

available by a data centre. 

ATPD 

MDB.0010 

68 WP3-020 • MDB records are provided and ingested at the MDB in near real time. MDB rejection rate < 2% CTR.0130 

68 WP3-021 The MDB will be physically realised as a complete relational database system that can be analysed using structured query 

NASR 

language (SQL) routines. 

68 WP3-022 These data provide a collective resource that is shared and populated by all RDAC and GDAC within the GHRSST-PP to 

NASR 

generate an independent assessment of the absolute error of all satellite SST data streams. 

68 WP3-023 The MDB forms the core data resource for both the derivation of Sensor Specific error statistics (SSES) that are assigned 

NASR 

to all L2P data in WP-ID2 and for the on-going validation of satellite data streams described in WP-ID5. 

68 WP3-024 Both of these rely on the regular population of the GHRSST-PP MDB using near real time satellite and in situ observations. MDB.0020 

69 WP3-025 The generation of individual GHRSST-PP MDB records and their storage in the GHRSST-PP MDB database system CTR.0580 

69 WP3-026 GHRSST-PP L2P data files for each individual satellite sensor are matched in space and in time with in situ observations 

MDB.0050 

(WP-ID3.1.1) if available. 

69 WP3-027 Time and space constraints that define near contemporaneous match-up criteria are stored in an MDB configuration file 

MDB.0230 

which will be maintained by the GHRSST-PP International Project Office 

69 WP3-028 If in situ data can be matched with satellite data then a MDB data record is prepared and formatted according to the MDB.0210 

© 2004 SOC Page 160 of 193




SR entry 

specification set out in Appendix A4.1 (WP-ID3.1.2). 

69 WP3-029 in situ observations may be matched to SST measurements derived from different satellite sensors and are thus used 

MDB.0250 

more than once in the system providing consistency across GHRSST-PP data products 

69 WP3-030 only 1 instance of each in situ observation (the nearest in space and time to the satellite data) is used to define a matchup 

MDB.0260 

record 

70 WP3-031 SSES are published on the GHRSST-PP web site as part of the GHRSST-PP User Information Service (UIS) and all 

NASR 

RDAC/GDAC are informed of the latest issue of SSES for use in the generation of GHRSST-PP L2P data products 

WP-ID3.1 Generation of Match Up Database (MDB) records 

70 WP3-032 The GHRSST-PP MDB system is a relational database containing all GHRSST-PP MDB data records. The GHRSST-PP 

NASR 

MDB will be implemented and maintained at the JPL PO.DAAC using the MySQL /database system 

70 WP3-033 MDB data records should be produced by RDAC and ingested at the MDB in near real time (1-7 days[1]) in order for SSES 

MDB.0030 

to be generated in a timely manner. [1] Note that the MDB will be used extensively by the GHRSST-PP reanalysis project 

so that the time constraints specified here should be interpreted in the broadest possible sense; if a match-up data record 

has been established, it should be delivered to the MDB system regardless of the timeliness of the data. 

70 WP3-034 Timeliness of MDB data is related to the availability of in situ data. Time penalties are incurred because data centres 

MDB.0030 

careful quality control and validate in situ measurements 

70 WP3-035 Collaboration with operational data centres that are well practiced in the QC of in situ observations must be established 

and maintained by RDAC and GDAC especially in the case of data that are made available on the GTS 

70 WP3-036 The GHRSST-PP expects to work closely with the CORIOLIS data centre (France), the Japanese Meteorological Agency 

MDB.0130 

MDB.0110 

MDB.0110 

(JMA), and the MEDS data centre (Canada) amongst others as described in Appendix A3.4.5 and Appendix A3.4.6 

70 WP3-037 the MDB is open to all in situ observations that are deemed of sufficient quality by the RDAC and GDAC teams MDB.0120 

MDB.0110 

© 2004 SOC Page 161 of 193




SR entry 

WP-ID3.1.1 Derivation of MDB data record 

70 WP3-038 The data inputs to GHRSST-PP MDB records are L2P data streams and in situ observations. MDB.0020 

70 WP3-039 For an MDB data record to be accurate and legitimate the comparison must be between like measurements although in the 

MDB.0270 

case of SSTskin observations, in situ data are extremely scarce 

70 WP3-040 Instead, emphasis is placed on the use of in situ SST1m data derived from drifting/moored buoy and ship observations. MDB.0270 

71 WP3-041 in situ data drawn down directly from the GTS must be QC’d locally before use MDB.0130 

71 WP3-042 Other data streams are only available to national institutes where they must be pre-processed and matched to satellite 

MDB.0120 

data on a case by case basis. 

71 WP3-043 each RDAC and GDAC centre must be responsible for implementing basic in situ QC procedures using local 

MDB.0130 

ocean/atmosphere knowledge and experience 

71 WP3-044 limits of coincidence must be applied to constrain the contributions to the error budget of the SSES/validation procedure 

MDB.0230 

from these sources to acceptable levels (say




SR entry 

MDB_space_constraint. 

71 WP3-049 [1] Based on discussions at the 4th GHRSST-PP Science Team Workshop, Los Angeles, USA, September 2003, 

MDB.0240 

MDB_time_constraint = 25 km radius of the pixel centre point and MDB_space_constraint should be within ±6 ours of the 

satellite overpass. These constraints are considered the absolute maximum and all efforts should be made to reduce 

these to the smallest deviations from zero as possible. 

71 WP3-050 In situ data that cannot be matched to better than these criteria should be ignored MDB.0240 

71 WP3-051 RDAC and GDAC should aim to use data with the highest spatial and temporal coincidence MDB.0210 

71 Rule 

WP3-052 

Because of the day-night asymmetry in the growth and decay of the diurnal thermocline, more stringent conditions for 

MDB.0240 

3.1.2a 

acceptable time intervals may be required during the day than at night 

71 Rule 

WP3-053 

For these and ambiguous cases, such as close to the terminator, the smallest spatial separation and shortest possible time 

MDB.0240 

3.1.2a 

interval should be sought. 

72 Rule 

WP3-054 

Only one instance of each in situ observation for each individual satellite sensor should occur within the MDB i.e. the 

MDB.0250 

3.1.2b 

satellite data having the smallest deviation in space and time from the in situ observation should be used within the MDB 

MDB.0210 

and all other duplicates should be removed 

72 Rule 

WP3-055 

L2P data adjacent to the validation measurement must be extracted to provide information on the spatial variability in the 

MDB.0320 

3.1.2c 

vicinity of the validation point 

72 Rule 

WP3-056 

Appropriate ‘missing data’ values will be used if any of the elements of the pixel array extend beyond the edges of the 

MDB.0320 

3.1.2c 

instrument swath. 

72 Rule 

WP3-057 A 5 x 5 array of L2P data should be extracted centred on the validation pixel. MDB.0320 

3.1.2c 

72 Rule 

WP3-058 All L2P confidence data each pixel stored in a MDB record must accompany the extracted data MDB.0310 

3.1.2d 

© 2004 SOC Page 163 of 193




SR entry 

72 Rule 

WP3-059 

A minimum delay of 24 hours is to be expected when using data from operational in situ data centres due to the latency 

MDB.0030 

3.1.2e 

incurred by QC procedures 

72 Rule 

WP3-060 all MDB records are admissible irrespective of their timeliness for use by the GHRSST-PP reanalysis project MDB.0030 

3.1.2e 

72 Rule 

WP3-061 

Additional geophysical fields will be required to provide insight into any uncorrected perturbations to the SSTs which might 

MDB.0330 

3.1.2f 

result in systematic errors. All available in situ parameters should be included in the MDB record using the spare 

WP-ID3.1.2 Format of MDB record 

72 WP3-062 Each in situ SST matched to a near contemporaneous satellite SST will be formatted as an XML text file following the 

Format 

format described in Appendix A4. 

WP-ID3.1.3 Insert MDB record into the GHRSST-PP MDB system 

72 WP3-063 MDB data records should be sent to the GHRSST-PP MDB either as an e-mail message or via ftp put CTR.0580 

72 WP3-064 An error message will be returned to the data provider if the MDB record is incorrectly formatted. NASR 

WP-ID3.2: Derivation of SSES using MDB records 

78 

72- 

79- 

WP-ID3.3: Publish SSES on GHRSST-PP web site and inform RDAC/GDAC 

80 

WP-ID4: Generation of L4 Analysed data products (L4) 

Description 

81 WP4-001 The GDS will produce an analysed estimate of SSTfnd every 24 hours using analysis procedures that depend on L2P data 

SYS.0080 

products as input. 

© 2004 SOC Page 164 of 193




SR entry 

81 WP4-002 GDS L4SSTfnd data products provide complete coverage SST data fields that are free of gaps for each APPW NASR 

81 WP4-003 the GHRSST-PP Science Team have specified that a diversity of approach is required to establish the optimal analysis 

DES.SYS.0040 

method that will maximise the impact of complementary satellite observations 

81 WP4-004 Standard GHRSST-PP L4SSTfnd products will be generated on a grid scale of 1/12° every 24 hours. NASR 

81 WP4-005 Ultra-high resolution (UHR) L4SSTfndUHR data products will be generated for regional areas at a grid scale of 1/48° 

L4A.0020 

latitude x longitude (~2km) every 24 hours 

inputs 

81 WP4-006 • L2P data files L4A.0030 

81 WP4-007 • L4 data processor configuration file L4A.0030 

outputs 

81 WP4-008 • Global coverage L4SSTfnd data product (L4FND) and associated confidence and error statistics for each APPW NASR 

81 WP4-009 • Regional coverage L4SSTfndUHR data product (L4FNDUHR) and associated confidence and error statistics for each 

APPW 

L4A.0100 

L4A.0051 

81 WP4-010 • MMR_FR metadata record for each L4 product NASR 

81 WP4-011 • Extracted HR-DDS data granules and HR-DDS MMR_FR metadata record for each data granule DDS.0040 

INT.DDS.0030 

acceptance tests 

81 WP4-012 • Identical L4 output data products are produced at each RDAC and GDAC when the GDS test data set us used compared 

to the reference processor 

ATPD 

EXP.L2P.0070 

81 WP4-013 • L4 MMR_FR metadata entries are timely and accurate ATPD 

81 WP4-014 • HR-DDS L4 data products are extracted correctly ATPD 

81 WP4-015 • L4 HR-DDS-MMR –FR metadata is correct and accepted by the HR-DDS MMR system ATPD 

© 2004 SOC Page 165 of 193




SR entry 

Metric for performance assessment 

82 WP4-016 • L4 products and HR-DDS L4 granules are produced in a timely manner ATPD 

82 WP4-017 • L4 MMR_FR metadata records provided and ingested at MMR and HR-DDSS MMR in real time. MMR and HR-DDS 

MMR rejection rate < 2% 

PER.DDS.0020 

CTR.0130 

82 WP4-018 • OPLOG L4_DPSR records correct and timely ATPD 

82 WP4-019 L4 SST data products provide an estimate of the foundation SST (SSTfnd). L4A.0054 

82 WP4-020 At 24 hour intervals, called Analysed Product Processing Windows (APPW) defined in Table 2.3.1, global coverage L2P 

L4A.0020 

data products are used in an analysis procedure. 

82 WP4-021 Two L4 data products are specified by the GDS: an estimate of SSTfnd at a grid resolution of 1/12° having global coverage 

NASR 

and an Ultra High Resolution SSTfnd product at a grid resolution of 1/48° having regional coverage. 

82 WP4-022 Each data product will include an estimate of the diurnal variability based on a parameterisation that can be driven using 

ancillary solar radiation and wind speed data 

LA4.0040 

L4A.0055 

82 WP4-023 and will be formatted to a common GDS L4 data format (described in Appendix A1) format 

82 WP4-024 will be made available to the user community in real time. DIS.0020 

82 WP4-025 The processor takes L2P data files as input together with a L4 configuration file containing threshold and data processor 

configuration settings. 

L4A.0030 

L4A.0035 

82 WP4-026 For each APPW L2P data are first collated for each APPW and grid cell. L4A.0060 

82 WP4-027 L4SSTfnd is calculated using analysis procedures for each output grid cell (WP-ID4.2 in Figure 4.1). L4A.0080 

82 WP4-028 An estimate of the diurnal variability within a 24 hour period is then derived for each grid cell (WP-ID4.3 in Figure 4.1). L4A.0055 

82 WP4-029 Each L4 data product is then formatted as a L4 data file (WP-ID4.4 in Figure 4.1) NASR 

82 WP4-030 a separate MMR_FR is prepared and submitted to the MMR (WP-ID4.5 in Figure 4.1). NASR 

82 WP4-031 HR-DDS granules are extracted from each L4 data product (WP-ID4.6 in Figure 4.1) NASR 

© 2004 SOC Page 166 of 193




SR entry 

82 WP4-032 a HR-DDS MMR_FR prepared and submitted to the HR-DDS MMR system (WP-ID4.7). NASR 

82 WP4-033 There are several schemes that have been developed by operational agencies and research establishments (e.g., 

Reynolds and Smith) that could be used but in each case, the specific method must be adapted to the high resolution 

L4A.0080 

L4A.0095 

space scales that the GHRSST-PP is attempting to resolve 

82 WP4-034 it is expected that L4 data products will evolve as RDAC gain more experience with high resolution SST measurements. L4A.0090 

WP-ID4.1 Collation of Available L2P Data 

83 WP4-035 all L2P data eligible for analysis must first be collated. L4A.0030 

83 WP4-036 L2P data must then be mapped into the analysis grid. L4A.0050 

84 WP4-037 L2P data must first be re-sampled onto the L4FND standard output grid which is defined in Appendix A1.1. NASR 

84 WP4-038 A number of input sensors (infrared imagers) have finer spatial resolution than the output grid specification, as shown in 

L4A.0060 

Figure 4.1.1. For these cases the rule will be to average the values of all pixels which overlap the product cell entirely and 

which have a L2P confidence record Proximity_Confidence value equal to the highest encountered within the cell, to 

produce a single value 

84 Rule 4.1a WP4-039 In the case of a smaller L2P input pixel than the L2FND grid cell size, L4FND data product cell values are derived from an 

L4A.0060 

average of the L2P pixel which completely overlap the product cell and which have a L2P confidence record 

Proximity_Confidence value equal to the highest encountered within the cell, to produce a single value. 

84 Rule 4.1b WP4-040 For input pixels that straddle the boundary between output grid cells, a weighting function may be applied to the input 

L4A.0060 

values according to the degree of coverage of the output grid cell and according to the SSES. 

84 Rule 4.1c WP4-041 The SSES value for a re-gridded data set will take the value associated with the Proximity_Confidence value assigned by 

L4A.0060 

Rule 4.1a. 

84 WP4-042 When pixels in the input data stream are much larger than those of the SSTFND output grid (e.g., microwave instruments), 

L4A.0060 

as illustrated in Figure 4.1.2, the output grid cell takes the value and confidence data record of the input pixel in which it 

© 2004 SOC Page 167 of 193




SR entry 

lies. Should it straddle more than one input pixel, it will take a weighted average of all those input pixels with which it 

overlaps and which have the highest L2P confidence record Proximity_Confidence value amongst the overlapping pixels. 

Weights will be assigned based on the coverage an input pixel has over the output grid. 

85 Rule 4.1d WP4-043 In the case of a larger pixel than the L4FND grid cell size, the output grid cell takes the value of the L2P pixel in which it 

L4A.0060 

lies. 

85 Rule 4.1e WP4-044 In the case where the output grid cell is covered by more than one L2P pixel, it will take the weighted average of all those 

L4A.0060 

L2P pixels with which it overlaps and which have the highest L2P confidence record Proximity_Confidence value 

amongst the overlapping pixels. Weights will be assigned based on the coverage an input pixel has over the output grid. 

85 WP4-045 There are other optimal methods for re-gridding data that may be investigated by the GHRSST-PP during the 

implementation of the GDS-v1.0 and may provide improvements over the simplistic method described here. 

85 WP4-046 in most optimal analysis systems, the analysis itself will optimise the re-gridding of data although re-gridding prior to 

L4A.0090 

L4A.0095 

L4A.0080 

interpolation provides a more straightforward processing system 

WP-ID4.2 Generate L4 SSTfnd data products (L4SSTfnd) 

85 WP4-047 Bias correction of all input data to the analysis procedure is critical to obtaining a valid output (see for example Reynolds et 

L4A.0080 

al, 2002). 

85 WP4-048 The GDS will use the L2P SSES derived bias as a measure of the overall uncertainty associated with each input data 

L4A.0080 

stream. 

85 WP4-049 bias due to diurnal stratification and cool skin effects must also be accounted for using additional data. L4A.0054 

85 WP4-050 Some satellite sensors provide a direct estimate of the SSTskin (AATSR) that must be adjusted to the SSTfnd. These data 

L4A.0054 

can then be used in an OI procedure to derive complete global fields. 

WP4-051 it is expected that the bias correction strategy will evolve and an upgrade of this component of the GDS is expected. L4A.0090 

86 WP4-052 L4FNDUHR data products will be generated for regions shown in Table 4.2.1. Other areas are expected in the future (e.g., L4A.0010 

© 2004 SOC Page 168 of 193




SR entry 

86 Table 

4.2.1 

European coastal seas) and will be described in Table 4.2.1 when operations begin. 

WP4-053 Name : Mediterranean, Regional project : Medspiration (EU-RDAC), Area : 30°N to 46°N and from 6°W to 36.5°E at 2 

km spatial resolution 

SYS.0081 

86 WP4-054 The GDS analysis scheme used to generate L4FND data products must: NASR 

86 WP4-055 • Provide a daily global coverage combined SSTfnd product that builds on the synergy between complementary SST data 

NASR 

streams having a grid cell size of 1/12° latitude x longitude (GDS-v1.0), 

86 WP4-056 • Provide error estimates for each analysed grid cell, L4A.0051 

86 WP4-057 • Account for differences in spatial and temporal sampling characteristics of each data stream L4A.0052 

86 WP4-058 • Account for gaps in coverage due to the presence of cloud, rain or lack of input L2P data L4A.0053 

86 WP4-059 • Account for SST diurnal variability both in space and time L4A.0054 

86 WP4-060 • Provide a measure of diurnal variability within the data product time domain to accompany the SSTfnd estimate that can 

also provide a best estimate of the skin temperature of the ocean (SSTskin) for each grid cell 

86 WP4-061 the analysis scheme described by Reynolds et al. (2002) may be modified to cater for high resolution spatial scales of 

L4A.0040 

L4A.0055 

L4A.0095 

SST. 

86 WP4-062 Appropriate spatial de-correlation length scales must be derived by the GHRSST-PP RDAC projects and close interaction 

L4A.0095 

with the GHRSST-PP Science Team. 

86 WP4-063 All parameters associated with the operation of the L4SSTfnd analysis scheme should be stored in a L4SSTfnd 

L4A.0035 

configuration file allowing for their easy editing and adjustment 

86 WP4-064 it is expected that alternative methods to the scheme proposed by Reynolds et al (2002) will be explored and compared 

L4A.0090 

during the GHRSST-PP within the framework of the GODAE inter-comparison project. 

WP-ID4.3 Generate L4 diurnal variation data fields 

86 WP4-065 Diurnal variation data fields form part of each L4 data product and are designed to enable a user to estimate the magnitude L4A.0055 

© 2004 SOC Page 169 of 193




SR entry 

and phase of diurnal variability at temporal intervals of 6 hours together with the SSTfnd. 

86 WP4-066 The diurnal variation will be referenced to the SSTskin. L4A.0055 

86 WP4-067 as the GHRSST-PP matures, a more comprehensive strategy will be adopted to generate estimates of SSTskin from 

L4a.0040 

multiple sensors 

87 WP4-068 a parameterisation of diurnal variability should be made available to the user community that allows the phase and 

L4A.0100 

magnitude of diurnal variation to be estimated at hourly intervals for each SST grid cell. 

87 WP4-069 The Diurnal signal will be referenced to the SSTsub-skin temperature so that warm layer effects are included L4A.0040 

87 WP4-070 an additional parameterisation for cool skin effects will be required to obtain the SSTskin. L4A.0040 

87 WP4-071 The initial specification is to use the diurnal variation scheme proposed by Alice Stuart-Menteth L4A.0040 

L4A.0070 

L4A.0055 

87 WP4-072 As an initial specification the bias correction strategy described in Donlon et al (2002) may be used to bias adjust SSTsubskin 

observations to SSTskin 

87 WP4-073 The appropriate coefficients for estimating diurnal variation are incorporated as part of the GHRSST-PP SSTfnd data 

format 

product using the Skin_parameterisation L4 SST grid cell ancillary data record described in Appendix A1.5, Table A1.5.2. 

87 WP4-074 In addition the L4 SST grid cell ancillary data record Skin_parameterisation_source should be updated according to 

format 

Table 4.3.1. 

87 Table 

WP4-075 Code values to be used to update the L4FND ancillary data record variable Skin_parameterisation_source (Table A1.5.2) format 

4.3.1 

87 Table 

WP4-076 0 : No parameterisation specified for this grid cell format 

4.3.1 

87 Table 

WP4-077 1 : Stuart-Menteth parameterisation format 

4.3.1 

© 2004 SOC Page 170 of 193




92 WP4-078 Figure 4.3.4 provides a schematic diagram showing one implementation approach for the Stuart-Menteth scheme within 

SR entry 

L4A.0070 

the GHRSST-PP L4 analysis system. 

93 WP4-079 It is clear that further work is required within the GHRSST-PP to develop and validate the Stuart-Menteth scheme 

L4A.0070 

discussed here. 

WP-ID4.4 Format L4 data product 

93 WP4-080 Each L4 data set will be formatted and archived in netCDF format following the data format described in Appendix A1.2, 

format 

A1.3. 

94 Rule 

WP4-081 

The L4FND grid cell ancillary data field Normalised_analysis_error should be updated with the normalised error of the 

format 

4.4.1 

analysis procedure. 

94 Rule 

WP4-082 The L4FND grid cell ancillary data field Bias should be updated with the analysis procedure bias error estimate. format 

4.4.2 

94 Rule 

WP4-083 

The L4FND grid cell ancillary data field Skin_parameterisation should be updated with a suite of coefficients that allow a 

format 

4.4.3 

user to compute an estimate of the SSTskin. The skin parameterisation scheme to be used is specified in the bitfield 

variable Skin_parameterisation_source according to Table 4.3.1. 

94 Rule 

WP4-084 If the grid cell is located over land, the L4FND ancillary data record bitfield Land_mask should be set to 1. format 

4.4.4 

94 Rule 

WP4-085 

The L4FND grid cell ancillary data field FractionalSeaIce variable should be set to the most appropriate value derived 

format 

4.4.5 

from the L2P input data streams appropriate to this output grid cell. A value of O indicates open ocean and 100 indicates 

100% sea ice coverage. In addition, the L4FND grid cell ancillary data field FractionalSeaIce_source should be set 

according to the source of data used to define the value of FractionalSeaIce as defined in Table 2.1.1.3. 

WP-ID4.5 Generate and deliver L4 MMR_FR metadata records 

94 WP4-086 a MMR_FR metadata record must be prepared and successfully submitted to the GDS MMR by the responsible Out of scope 

© 2004 SOC Page 171 of 193




SR entry 

processing centre for all L4 data products. 

WP-ID4.5.1 Format L4 MMR_FR metadata record 

94 WP4-087 A MMR_FR metadata record should be prepared for each L4 data file according to the specification provided in Appendix 

Out of scope 

A6.2. 

WP-ID4.5.2 Register L4 MMR_FR metadata record with MMR system 

94 WP4-088 L4 MMR_FR metadata records should be delivered to the MMR system as soon as possible after the L4 data set has been 

Out of scope 

produced following the procedure described in Appendix A6.4. 

94 WP4-089 WP-ID4.7 Extraction of L4 match up database file records (MDB_FR) NASR 

94 WP4-090 L4* MDB_FR should be extracted according to the procedures described in WP-ID3. Out of scope 

159 Appendix A5. GHRSST-PP High Resolution Diagnostic Data Set (HR-DDS) data granule data product format 

specification 

159 AP5-001 The GHRSST-PP High-resolution Diagnostic Data Set (HR-DDS) system provides a distributed data resource and a 

NASR 

framework to analyse and inter-compare L2P and L4 data products in near real time, together with other data products 

including NWP analyses, operational ocean and atmospheric model outputs and in situ observations 

159 AP5-002 In order to reduce the overhead of data storage and transport, the HR-DDS consists of about150 globally distributed 2º x 

NASR 

2º latitude x longitude sites 

159 AP5-003 Figure A5.1 shows a map of primary[1] HR-DDS sites (v2.3) for which all L2P and L4* data streams[2] will be extracted 

and archived as data granules. Each HR-DDS site is strategically positioned in order to address a particular issue; for 

implies 

CFI.DDS.0020 

example, a particularly dynamic or “quiet” oceanographic or atmospheric region, location of additional in situ infrastructure, 

areas known to be influenced by atmospheric aerosol or persistent cloud cover and areas already having a significant 

scientific interest. Each site shown in Figure A5.1 is defined in Section A5.3. 

159 AP5-004 The HR-DDS system provides a real time data resource the main learning tool for GHRSST-PP project scientists to NASR 

© 2004 SOC Page 172 of 193




SR entry 

develop and refine the GDS, to investigate differences between complementary data streams, to investigate regional and 

time variant bias statistics, to monitor the quality of input and output data streams and as a core component of the 

GHRSST-PP reanalysis (RAN) project 

159 AP5-005 The HR-DDS constitutes the virtual laboratory of the GHRSST-PP allowing, for example, a full implementation of 

NASR 

Integrated Global Observing Strategy (IGOS) measurement principles (see http://www.igospartners.org/). 

159 AP5-006 This Appendix provides a summary overview of the GHRSST-PP HR-DDS system. A complete Scientific and technical 

NASR 

description of the HR-DDS system can be found in GHRSST/13 available at http://www.ghgrsst-pp.org 

A5.1 Summary of the HR-DDS system configuration and operation 

159 AP5-007 HR-DDS granules are produced by RDAC and GDAC centres in real time as netCDF data files according to the 

DDS.0120 

specifications provided in Appendix A1 

159 AP5-008 HR-DDS granules are archived locally together with a corresponding HR-DDS metadata record DDS.0110 

159 AP5-009 HR-DDS metadata records are produced according to the specifications described in Appendix A6 and are identical to 

format 

other GDS metadata records 

159 AP5-010 HR-DDS archive centres are referred to as HR-DDS nodes and in general, HR-DDS nodes should be part of RDAC and 

DDS.0110 

GDAC 

160 AP5-011 Figure A5.2 provides a schematic diagram of the GHRSST-PP HR-DDS data system which is based on a number of 

NASR 

distributed HR-DDS nodes that are interconnected using the Distributed Oceanographic Data System (DODS, see 

http://www.dods.org). 

160 AP5-012 The DODS architecture uses a client/server model and the http protocol to provide a framework that simplifies . . . . . . NASR 

160 AP5-013 In addition to local data access via DODS/OPeNDAP servers at each HR-DDS node, HR-DDS nodal data archives are 

NASR 

virtually combined as a single data archive by a HR-DDS virtual server. The HR-DDS virtual server uses GHRSST-PP 

Master Metadata Repository (MMR) HR-DDS metadata records to catalogue HR-DDS data granules archived at all 

© 2004 SOC Page 173 of 193




SR entry 

distributed HR-DDS nodes. Using a HR-DDS interface, users at the HR-DDS virtual server may access all HR-DDS 

granules (maintained at distributed locations, served by local DODS servers) using DODS aware client applications as if 

they were a single data archive residing on a local computer. 

160 AP5-014 In addition to DODS access, HR-DDS granules may also be accessed using secure ftp (sftp) transactions or through a Live 

NASR 

Access Server (LAS, http://ferret.pmel.noaa.gov/Ferret/LAS/). LAS is a highly configurable Web server designed to 

provide flexible access to geo-referenced scientific data and can present distributed data sets as a unified virtual data base 

through the use of DODS networking 

160 AP5-015 Using a web browser interface LAS enables a user to visualize data with on-the-fly graphics; request custom subsets of 

NASR 

variables in a choice of file formats ;access background reference material about the data (metadata) ;compare 

(difference) variables from distributed locations 

161 AP5-016 LAS enables the data provider to unify access to multiple types of data in a single interface ;create thematic data servers 

NASR 

from distributed data sources ; offer derived products on the fly ; remedy metadata inadequacies (poorly self-describing 

data) ; offer unique products (e.g. visualization styles specialized for the data) 

161 AP5-017 LAS will be used extensively in the GODAE project and will allow data to be extracted from many operational ocean model 

NASR 

systems for inclusion and comparison with HR-DDS SST data. In addition, the LAS system is in active development to 

provide advanced features such as temporal aggregation of data and advanced display options in collaboration with the 

GODAE Data Sharing Pilot Project. 

161 AP5-018 Each HR-DDS node is thus responsible for NASR 

161 AP5-019 (a) Installing and maintaining a data archive of HR-DDS granules and associated MMR DSR and MMR-FS metadata 

DDS.0110 

records (see Appendix A6) 

161 AP5-020 (b) Operating a DODS server to serve HR-DDS data DDS.0140 

EXT.DDS.0030 

© 2004 SOC Page 174 of 193




SR entry 

161 AP5-021 (c) Operating an sftp server for HR-DDS granule access EXT.DDS.0040 

161 AP5-022 (d) Operating other optional data interface software (e.g., LAS) tbd 

A5.2 HR-DDS data granule file format 

161 AP5-023 HR-DDS granules are formatted as netCDF data files according to the format description laid out for L2P data file in 

DDS.0120 

Appendix A1 

161 AP5-024 The main difference between L2P data and HR-DDS data files is that HR-DDS data have been re-sampled using a nearest 

neighbour scheme to a uniform resolution grid specified in Table A1.1.3 

DDS.0030 

DDS.0090 

161 AP5-025 All L2P confidence data are re-sampled in the same manner to provide a multiple image netCF file. DDS.0030 

A5.3 HR-DDS metadata record format and registration 

161 AP5-026 HR-DDS granule metadata records are identical in content and format to GDS metadata records. A full description of 

format 

MMR-DSR and MMR_FR is given in Appendix A6. 

161 AP5-027 A MMR DSR will be registered at the GHRSST-PP MMR for each HR-DDS site that is described in Appendix A5.4. DDS.0060 

EXT.DDS.0050 

161 AP5-028 A MMR_FR will be generated for each HR-DDS granule and registered at the MMR following the procedure described in 

Appendix A6.4. 

DDS.0070 

EXT.DDS.0060 

A5.4 Location of HR-DDS sites 

162- 

AP5-029 

Tables A5.4.1, A5.4.2, A5.4.3 and A5.4.4 describe the locations and formal names of each HR-DDS (v2) site for open 

NASR 

167 

ocean, moored buoys, SIMBIOS and other sites respectively 

© 2004 SOC Page 175 of 193




Issue F 

Table A2. Trace between System Requirements and the relevant sections of the user 

requirement documents to which relate. 

Section SR ID ref. References in the main user requirements matrix (Table A1) 

3.1.1 SYS.0010 sow-026 urd-084 GDS-016 GDS-012 GDS-013 

3.1.1 SYS.0015 sow-059 sow-060 sow-064 sow-065 urd-83 urd-131 

GDS-018 GDS-042 

3.1.1 SYS.0020 sow-007 urd-106 urd-133 GDS-015 

3.1.1 SYS.0021 urd-133 GDS-017 

3.1.2 SYS.0030 sow-027 sow-028 sow-029 sow-030 sow-031 sow-032 

sow-033 sow-034 sow-035 urd-107 sow-062 

3.1.2 SYS.0040 (urd-109) 

3.1.3 SYS.0050 sow-040 urd-083 urd-084 urd-100 urd-111 GDS-19 

3.1.3 SYS.0051 urd-085 

3.1.3 SYS.0052 sow-042 

3.1.3 SYS.0055 sow-048 

3.1.3 SYS.0060 sow-057 urd-092 urd-115 ap4-002 GDS-013 

3.1.3 SYS.0061 sow-058 urd-115 

3.1.3 SYS.0070 sow-053 urd-091 urd-104 urd-114 GDS-013 

3.1.3 SYS.0071 sow-054 sow-055 soe-056 urd-114 

3.1.3 SYS.0080 sow-041 sow-050 urd-093 urd-100 urd-113 GDS-20 

WP4-001 GDS-022 

3.1.3 SYS.0081 urd-096 WP4-053 GDS-022 

3.1.3 SYS.0082 sow-052 sow-68 GDS-022 

3.1.3 SYS.0083 sow-051 

3.1.4 SYS.0090 urd-112 GDS-013 

© 2004 SOC Page 176 of 193




Issue F 


3.1.4 SYS.0100 urd-111 GDS-075 GDS-013 

3.1.4 SYS.0110 sow-046 sow-047 urd-132 

3.1.4 SYS.0120 

3.1.5 SYS.2010 GDS-056 GDS-057 

3.1.5 SYS.2020 sow-047 

3.1.5 SYS.2030 GDS-088 

3.1.5 SYS.2040 urd-112 

3.1.5 SYS.2050 GDS-089 GDS-064 sow-008 

3.1.5 SYS.2060 urd-129 GDS-050 ap4-002 

3.1.5 SYS.2070 

3.1.5 SYS.2080 GDS-051 GDS-091 

3.1.5 SYS.2081 GDS-095 

3.1.5 SYS.2082 GDS-095 

3.1.5 SYS.2090 

3.2. L2P.0010 sow-043 GDS-047 WP1-032 GDS-056 WP1-055 WP1-057 

3.2. L2P.0020 sow-043 GDS-047 WP2-010 GDS-057 

3.2. L2P.0030 GDS-048 WP2-048 

3.2. L2P.0040 sow-043 GDS-043 GDS-048 WP2-050 WP2-041 GDS-070 

3.2. L2P.0050 sow-043 GDS-043 GDS-049 WP2-054 WP2-041 GDS-068 

GDS-073 

L2P.0055 

WP2-005 

3.2. L2P.0060 WP2-236 WP2-055 WP2-041 GDS.060 

3.2. L2P.0070 sow-043 GDS-063 

© 2004 SOC Page 177 of 193




Issue F 


3.2. L2P.0080 WP2-042 

3.2. L2P.0090 WP2-014 WP2-043 

3.2.6 L2P.6010 WP2-175 

3.2.6 L2P.6020 WP2-176 WP2-177 

3.2.7 L2P.7000 WP2-231 WP-234 

3.2.7 L2P.7010 

3.2.7 L2P.7020 

3.2.7 L2P.7030 

3.2.7 L2P.7040 

3.2.2 ING.0010 WP1-024 

3.2.2 ING.0020 WP-007 

3.2.2 ING.0030 sow-048 WP1-008 WP1-017 WP1-025 

3.2.2 ING.0040 WP1-028 WP1-066 

3.2.2 ING.0050 WP1-044 

3.2.2 ING.0060 WP1-026 

3.2.2 ING.0070 WP2-060 WP2-075 

3.2.2 ING.0080 WP2-076 

3.2.2 ING.0090 WP2-077 

3.2.2 ING.0100 WP1-009 WP1-015 WP1-059 

3.2.2 ING.0110 WP1-056 

3.2.2 ING.0120 WP1-062 

3.2.2 ING.0130 sow-007 urd-085 urd-096 

© 2004 SOC Page 178 of 193




Issue F 


3.2.1 ING.1010 

3.2.1 ING.1020 

3.2.3 QLC.0010 WP1-009 WP1-016 WP2-002 WP2-003 

3.2.3 QLC.0020 WP2-011 WP2-065 

3.2.3 QLC.0030 

3.2.3 QLC.0035 WP2-016 WP2-096 

3.2.3 QLC.0040 WP2-071 etc. 

3.2.3 QLC.0045 WP2-145 WP1-058 

3.2.3 QLC.0050 WP2-149 

3.2.3 QLC.0060 WP2-153 

3.2.3 QLC.0065 WP2-197 

3.2.3 QLC.0070 WP2-071 WP2-059 WP2-187 

3.2.3 QLC.0080 WP2-072 WP2-074 WP2-187 

3.2.3 QLC.0090 WP2-102 WP2-099 

3.2.3 QLC.0100 WP2-118 

3.2.3 QLC.0110 WP2-131 

QLC.0120 WP2-119 WP2-132 WP2-103 

3.2.4 MRG.0010 WP2.-004 

3.2.4 MRG.0020 WP2-058 

3.2.4 MRG.0030 WP2-061 

3.2.4 MRG.0040 WP2-062 

3.2.4 MRG.0050 WP2-063 

© 2004 SOC Page 179 of 193




Issue F 


3.2.4 MRG.0060 WP2-064 

3.2.4 MRG.0070 WP2-080 

3.2.4 MRG.0080 WP2-081 

3.2.4 MRG.0090 WP2-082 

3.2.4 MRG.0110 WP2-083 WP2-085 

3.2.4 MRG.0120 WP2-084 

3.2.4 MRG.0130 WP2-093 WP2-090 WP2-091 

3.2.4 MRG.0150 WP2-095 

3.2.4 MRG.0160 WP2-096 

3.2.4 MRG.0170 WP2-097 

3.2.4 MRG.0180 WP2-211 

3.2.4 MRG.0190 WP2-212 

3.2.4 MRG.0200 WP2-213 WP2-215 

3.2.4 MRG.0210 WP2-214 

3.2.4 MRG.0220 WP2-122 

3.2.4 MRG.0230 WP2.123 

3.2.4 MRG.0240 WP2-124 WP2-126 

3.2.4 MRG.0250 WP2-125 

3.2.4 MRG.0260 

3.2.5 CFD.0010 GDS-070 

3.2.5 CFD.0020 WP2-176 WP2-228 WP2-143 

3.2.5 CFD.0030 WP2-012 

3.2.5 CFD.0050 WP2-139 WP2-133 WP2-179 

© 2004 SOC Page 180 of 193




Issue F 


3.2.5.1 CFD.0100 WP2-142 

3.2.5.1 CFD.0110 WP2-194 

3.2.5.1 CFD.0120 WP2-195 

3.2.5.1 CFD.0140 WP2-201 WP-199 

3.2.5.1 CFD.0150 WP2-202 WP-200 

3.2.5.1 CFD.0160 WP2-204 

3.2.5.1 CFD.0170 WP2-206 

3.2.5.1 CFD.0180 WP2-207 

3.2.5.1 CFD.0190 WP2-211 WP2-220 

3.2.5.1 CFD.0200 WP2-209 WP2-210 

3.2.5.1 CFD.0210 WP-208 WP2-216 

3.2.5.1 CFD.0220 WP2-220 WP2-181 WP2-182 

3.2.5.2 CFD.0300 WP2-158 WP2-154 WP2-156 

3.2.5.2 CFD.0310 WP2-159 WP2-156 

3.2.5.2 CFD.0320 WP2-160 WP2-161 WP2-162 WP2-163 WP2-167 WP2-134 

WP2-137 

3.2.5.2 CFD.0330 WP2-167 

3.2.5.2 CFD.0340 WP2-166 

3.2.5.2 CFD.0350 WP2-168 

3.2.5.2 CFD.0360 WP2-169 

3.2.5.2 CFD.0370 WP2-170 

3.3.1.1 ARC.0010 sow-026 GDS-059 

3.3.1.1 ARC.0020 

© 2004 SOC Page 181 of 193




Issue F 


ARC.0030 

ARC.0040 

sow-026 

3.3.1.1 ARC.0110 

3.3.1.1 ARC.0120 

3.3.1.2 ARC.0210 

3.3.1.3 ARC.0310 

3.3.1.3 ARC.0320 

3.3.1.3 ARC.0330 

3.3.1.4 ARC.0410 

3.3.2 L4A.0010 sow-050 WP4-052 

L4A.0015 

3.3.2 L4A.0020 GDS-045 WP4-005 WP4-020 

L4A.0025 

3.3.2 L4A.0030 WP4-035 WP4-006 WP4-007 WP4-025 

L4A.0035 WP4-025 WP4-063 

3.3.2 L4A.0040 WP4-022 WP4-060 WP4-069 WP4-070 WP4-071 

3.3.2 L4A.0050 GDS-035 WP4-036 

3.3.2 L4A.0051 GDS-081 WP4-009 

3.3.2 L4A.0052 GDS-082 

3.3.2 L4A.0053 GDS-083 

3.3.2 L4A.0054 GDS-084 WP4-019 WP4-049 WP4-050 

3.3.2 L4A.0055 GDS-085 GDS-086 WP4-022 WP4-028 WP4-065 

3.3.2 L4A.0060 WP4-026 WP4-038 to WP4-044 

© 2004 SOC Page 182 of 193




Issue F 


3.3.2 L4A.0070 WP4-071 WP4-078 WP4-079 

3.3.2 L4A.0080 WP4-027 WP4-033 WP4-046 

3.3.2 L4A.0090 WP4-034 WP4-045 WP4-051 WP4-064 

L4A.0095 WP4-033 WP4-045 WP4-061 WP4-062 

3.3.2 L4A.0100 WP4-009 

3.3.3 MDB.0010 WP3-006 WP3-019 

3.3.3 MDB.0020 WP3-010 WP3-024 WP3-038 

3.3.3 MDB.0030 WP3-033 WP3-034 WP3-060 WP3.059 

3.3.3 MDB.0040 WP3-009 WP3-011 

3.3.3 MDB.0050 WP3-026 

3.3.3.1 MDB0110 WP3-035 WP3-036 sow-037 

3.3.3.1 MDB.0120 WP3-037 WP3-007 WP3-042 

3.3.3.1 MDB.0130 WP3-035 WP3-043 WP3-041 

3.3.3.2 MDB.0210 WP3-054 WP3-051 WP3-028 

3.3.3.2 MDB.0220 WP3.047 

3.3.3.2 MDB.0230 WP3-027 WP3-048 WP3-044 WP3-045 

3.3.3.2 MDB.0240 WP3-049 WP3-046 WP3-052 WP3-053 

3.3.3.2 MDB.0250 WP3-029 WP3-054 

3.3.3.2 MDB.0260 WP3-030 

3.3.3.2 MDB.0270 WP3-039 WP3-040 

3.3.3.3 MDB.0310 WP3-058 

3.3.3.3 MDB.0320 WP3-057 WP-055 WP3-056 

3.3.3.3 MDB.0330 WP3-061 

© 2004 SOC Page 183 of 193




Issue F 


3.3.4 DIS.0010 sow-040 sow-041 

3.3.4 DIS.0020 sow-060 WP4-024 

3.3.4 DIS.0030 sow-060 

3.3.4.1 DIS.0110 sow-061 urd-083 

3.3.4.1 DIS.0120 sow-061 urd-060 urd-083 

3.3.4.2 DIS.0210 

3.3.4.3 DIS.0310 

3.3.5.1 CTR.0110 WP1-026 sow-066 WP2-241 

3.3.5.1 CTR.0120 WP1-026 WP1-048 WP1-054 

3.3.5.1 CTR.0130 WP2-035 WP3-020 WP4-017 

3.3.5.1 CTR.0140 WP1-050 

3.3.5.1 CTR.0150 WP1-050 

3.3.5.1 CTR.0160 

3.3.5.1 CTR.0170 WP1-050 

3.3.5.1 CTR.0180 WP1-049 

3.3.5.1 CTR.0190 

3.3.5.2 CTR.0210 

3.3.5.2 CTR.0220 

3.3.5.3 CTR.0230 

3.3.5.3 CTR.0240 

3.3.5.3 CTR.0250 

3.3.5.4 CTR.0260 

© 2004 SOC Page 184 of 193




Issue F 


3.3.5.5 CTR.0310 

3.3.5.5 CTR.0320 

3.3.5.6 CTR.0410 

3.3.5.6 CTR.0420 

3.3.5.6 CTR.0430 

3.3.5.7 CTR.0510 

3.3.5.7 CTR.0520 

3.3.5.8 CTR.0530 GDS-054 WP1-045 WP1-046 WP2-006 WP2-235 

3.3.5.8 CTR.0540 

3.3.5.9 CTR.0550 WP2-007 WP2-232 WP2-233 

3.3.5.9 CTR.0560 

3.3.5.10 CTR.0570 URD-060 

3.3.5.10 CTR.0580 WP2-007 WP3-025 WP3-015 WP3-063 

3.4.2 DDS.0010 sow-053 sow-056 

3.4.2 DDS.0020 urd-065 sow-054 

3.4.2 DDS.0030 GDS-093 GDS-036 GDS-051 AP5-024 WP2-015 

3.4.2 DDS.0040 GDS-053 WP4-011 

3.4.2 DDS.0050 

3.4.2 DDS.0060 AP5-027 

3.4.2 DDS.0070 AP5-028 

3.4.2 DDS.0090 GDS-036 AP5-024 

3.4.2 DDS.0091 GDS-094 

3.4.3 DDS.0110 sow-055 

© 2004 SOC Page 185 of 193




Issue F 


3.4.3 DDS.0120 AP5-007 AP5-023 

3.4.4 DDS.0140 AP5-020 

3.4.5 DDS.0170 

3.4.5 DDS.0180 

3.4.5 DDS.0190 AP7-001 

3.4. DDS.1000 

3.4.1 DDS.1010 sow-028 

3.4.1 DDS.1030 

3.4.1 DDS.1040 

3.4.1 DDS.1050 

3.4.1 DDS.1060 

4.1.1 INT.L2P.0010 

4.1.1 INT.L2P.0020 

4.1.1 INT.L2P.0030 

4.1.1 INT.L2P.0040 

4.1.1 INT.L2P.0050 

4.1.1 INT.L2P.0060 

4.1.1 INT.L2P.0070 

4.1.1 INT.L2P.0080 

4.1.1 INT.L2P.0090 

4.1.1 INT.L2P.0100 

4.1.2 INT.ARC.0010 

© 2004 SOC Page 186 of 193




Issue F 


4.1.2 INT.ARC.0020 

4.1.2 INT.ARC.0030 

4.1.6 INT.ARC.0510 

4.1.6 INT.ARC.0520 

4.1.6 INT.ARC.0530 

4.1.6 INT.ARC.0540 

4.1.6 INT.ARC.0550 

4.1.3 INT.DIS.0010 

4.1.3 INT.DIS.0020 

4.1.3 INT.DIS.0030 

4.1.4 INT.MDB.0010 

4.1.5 INT.L4A.0010 

4.1.5 INT.L4A.0020 

4.1.5 INT.L4A.0030 

4.1.5 INT.L4A.0040 

4.1.7 INT.DDS.0010 GDS-051 

4.1.7 INT.DDS.0020 GDS-053 

4.1.7 INT.DDS.0030 WP4-011 

4.1.7 INT.DDS.0040 

4.1.7 INT.DDS.0050 

© 2004 SOC Page 187 of 193




Issue F 


4.1.7 INT.DDS.0060 

4.1.7 INT.DDS.0070 

4.1.7 INT.DDS.0080 

4.1.7 INT.DDS.0090 

4.1.7 INT.DDS.0100 

4.1.7 INT.DDS.0110 

4.1.7 INT.DDS.0120 

4.1.7 INT.DDS.0130 

4.1.8 INT.CTR.0020 

4.1.8 INT.CTR.0030 

4.1.8 INT.CTR.0040 

4.1.8 INT.CTR.0050 

4.1.8 INT.CTR.0060 

4.2.1 EXT.ING.0010 WP1-024 

4.2.1 EXT.ING.0020 WP1-024 

4.2.1 EXT.ING.0030 WP1-027 

4.2.1 EXT.ING.0040 

4.2.1 EXT.L2P.0010 

4.2.1 EXT.SYS.0010 

4.2.1 EXT.SYS.0020 

4.2.2 EXT.MDB.0010 sow-037 

© 2004 SOC Page 188 of 193




Issue F 


4.2.2 EXT.MDB.0020 

4.2.2 EXT.MDB.0030 

4.2.3 EXT.CTR.0210 

4.2.3 EXT.CTR.0220 

4.2.3 EXT.CTR.0230 

4.2.4 EXT.CTR.0310 

4.2.4 EXT.CTR.0320 

4.2.4 EXT.CTR.0330 

4.2.4 EXT.CTR.0340 

4.2.5 EXT.CTR.0410 

4.2.5 EXT.CTR.0420 

4.2.5 EXT.CTR.0430 

4.2.6 EXT.CTR.0510 

4.2.6 EXT.CTR.0520 

4.2.6 EXT.CTR.0530 

4.2.7 EXT.DIS.0010 

4.2.7 EXT.DIS.0020 

4.2.7 EXT.DIS.0030 

4.2.7 EXT.DIS.0040 

4.2.8 EXT.DDS.0010 

4.2.8 EXT.DDS.0020 

© 2004 SOC Page 189 of 193




Issue F 


4.2.8 EXT.DDS.0030 AP5-020 

4.2.8 EXT.DDS.0040 AP5-021 

4.2.8 EXT.DDS.0050 AP5-027 

4.2.8 EXT.DDS.0060 AP5-028 

5.1. PER.SYS.0010 GDS-049 

5.1. PER.SYS.0011 

5.1. PER.SYS.0015 

5.1. PER.SYS.0020 

5.1. PER.SYS.0030 

5.1. PER.SYS.0040 

5.1. PER.SYS.0050 

5.1. PER.SYS.0060 

5.1. PER.SYS.0070 

5.1. PER.SYS.0080 URD-099 

5.1. PER.DDS.0010 

5.1. PER.DDS.0020 WP4-017 

5.1. PER.DDS.0030 

5.1. PER.DDS.0050 

5.1. PER.DDS.0060 

5.1. PER.DDS.0070 

6.1. EXP.SYS.0010 WP2-129 WP2-230 

© 2004 SOC Page 190 of 193




Issue F 


6.1. EXP.SYS.0020 urd-105 

6.1. EXP.SYS.0030 urd-073 sow-041 urd-093 

6.2. EXP.L2P.0010 sow-070 sow-071 

6.2. EXP.L2P.0020 

6.2. EXP.L2P.0030 WP2-173 

6.2. EXP.L2P.0040 WP2-224 

6.2. EXP.L2P.0050 WP2-221 WP2-222 

6.2. EXP.L2P.0060 

6.2. EXP.L2P.0070 WP4-012 

6.3. EXP.DDS.0010 sow-067 sow-71 

6.3. EXP.DDS.0020 sow-067 

6.3. EXP.DDS.0030 sow-067 sow-70 

6.3. EXP.DDS.0040 sow-067 

6.3. EXP.DDS.0050 

6.3. EXP.DDS.0060 

7.. SEC.SYS.0010 

7.. SEC.DDS.0010 

8.. DES.SYS.0010 sow-070 

8.. DES.SYS.0020 sow-069 

8.. DES.SYS.0030 sow-066 WP1-051 

© 2004 SOC Page 191 of 193




Issue F 


8.. DES.SYS.0040 sow-067 GDS-017 WP4-003 

8.. DES.SYS.0050 sow-071 

8.. DES.SYS.0060 sow-70 

9.. REL.SYS.0010 

9.. REL.ARC.0010 

10.. TST.SYS.0020 

10.. TST.SYS.0030 

10.. TST.SYS.0040 

10.. TST.SYS.0050 

10.. TST.SYS.0060 

10.. TST.SYS.0070 

10.. TST.SYS.0080 

10.. TST.SYS.0090 

10.. TST.SYS.0100 

12.. CFI.SYS.0010 sow-080 GDS-023 WP2-170 

12.. CFI.SYS.0020 sow-081 

12.. CFI.SYS.0030 sow-082 

12.. CFI.SYS.0040 sow-083 

12.. CFI.L2P.0010 WP1-053 

12.. CFI.L2P.0020 sow-086 

12.. CFI.DDS.0010 

© 2004 SOC Page 192 of 193




Issue F 


12.. CFI.DDS.0020 

12.. CFI.DDS.0030 WP5-003 

12.. CFI.DDS.0040 

© 2004 SOC Page 193 of 193

Medspiration â System Requirements Document - Data User Element

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?

Medspiration â System Requirements Document - Data User Element