The Baltic Sea is surrounded by nine countries: Denmark, Estonia, Finland, Germany, Latvia, Lithuania, Poland, Russia and Sweden. The Baltic Operational Oceanographic System (BOOS) comprises various national governmental agencies that are responsible for environmental observations, modelling operations and production of forecasts, services and information for the marine industry, the public and other end-users. BOOS is built on different systems. The goals of BOOS are to [12]:
The development of BOOS was supported with the start-up financing from the EU THEMATIC NETWORK project “Programme for a bAltic network to assess and upgrade an oPerational observing and forecAsting System in the region” (PAPA, EVR1-CT-2002-20012). PAPA’s main objectives are to demonstrate constructive ways to implement a basin wide operational oceanographic system according to the ambitions of GOOS:
During the PAPA-project a password protected FTP-box system was developed for data exchange between member institutions. It is a decentralised system where each member puts data it wants to exchange in its own FTP-box, where it can be collected by the other members. Therefore, each institute is free to put what data they want in their own box in whatever format they like. All partners are obliged to setup an FTP-box (read only by the other partners) for publishing operational data, metadata, disclaimer, header and format information. The only restriction is the use of the ASCII format. By using the ASCII format, individual datasets are readily available for all partners (e.g. real-time data and the inventory of the QA database are available via the web). However, resulting from the SEPRISE project, a number of regional data centres have been given responsibility for collating the various in situ datasets from various FTP-boxes in the BOOS region. Each regional centre specialises in a particular parameter. These collated datasets are placed in a single FTP-box per regional centre. The institutes who are responsible for collating regional data within BOOS are listed in the Table below
| Parameter | Regional centre |
| currents | SMHI |
| temperature and salinity profiles | BSH |
| water level | DMI |
| waves | FIMR |
This section outlines the currents, temperature and salinity profiles, water level, and waves data formats for BOOS.
SMHI are responsible for collecting currents data from FTP-boxes in the BOOS region. This compiled currents dataset is stored in a single ASCII file and disseminated via a central FTP-box. A single row of data in the ASCII file stores currents data from all stations for a single instance of time. The data format for each column within a row is illustrated here:
1 YYYYMMDDhhmm → data and time
2 currents direction → degrees at depth x for station 1
3 currents direction → degrees at depth x+1 for station 1
4 currents direction → degrees at depth x+2 for station 1
.
? currents speed → cm/s at depth x for station 1
? currents speed → cm/s at depth x+1 for station 1
? currents speed → cm/s at depth x+2 for station 1
.
.
? currents direction → degrees at depth y for station 2
? currents direction → degrees at depth y+1 for station 2
? currents direction → degrees at depth y+2 for station 2
.
? currents speed → cm/s at depth y for station 2
? currents speed → cm/s at depth y+1 for station 2
? currents speed → cm/s at depth y+2 for station 2
.
.
Date and time is recorded in the first column of each row (YYYYMMDDhhmm format, e.g. 200706171600). The time zone is always UTC. For the first station, columns two, three, four, etc. stores a series of currents direction values (degrees) for a particular depth, where each columns measurement is associated with a depth value referenced in the current’s readme file. Following the currents direction values is a series of currents speed values (cm/s) for the first station. Again, each of these measurements is associated with a depth value referenced in the current’s readme file. For all subsequent stations, respective measurements are stored in successive columns and associated with a depth value referenced in the current’s readme file. The code for erroneous or missing data is -999.0000.
BSH are responsible for collecting temperature and salinity (T/S) data from FTP-boxes in the BOOS region. This compiled T/S dataset is stored in two ASCII files: one for sea temperature and another for sea salinity. This data is disseminated via a central FTP-box. The format for both ASCII files is:
Long Lat StatName Time depth:value depth:value ….
Representing longitude, latitude, station name, data and time (YYYYMMDDhhmm), and a series of water depth and associated measurement values.
BOOS water level observations from tide gauges are collected by DMI via FTP-boxes from the various BOOS partners. Sixty days of data from each observation station is stored in a single individual ASCII file and disseminated via a central FTP-box. However, the frequency of the data is the original data sampling frequency provided from the original data provider. The format of the file is:
YYYYMMDDhhmm wl
where the left hand value represents date and time (e.g. 200704192300) and the right hand value represents water level in metres (e.g. 0.6). Missing water levels data is represented with the value -9.99. Water level is referenced to national reference levels.
This information was not available during the writing of this report.
Developed during the PAPA project, a metadata database was setup on a server at the BSH which can be accessed by the BOOS members. The database is password protected and the access information was first announced at the BOOS/PAPA meeting in May 2004 in Norrköping, Sweden. The database interface has two main features: one is a map based overview function and the other consists of parameter based queries.
PAPA database on fixed stations
The queries return tables containing the desired information and thematic maps can be produced interactively. This so called ‘PAPA-OBS database’, contains metadata of operational stations or measuring sites and the ‘QA database’, the quality assurance database, containing information on sensors, accuracy, calibration and data processing procedures used in the BOOS community. They are linked to an interactive web site where the information can be retrieved. This database can be accessed at:
Following the results of the PAPA project, the upgrade of an operational observing and forecasting system in the Baltic Sea was established using common protocols for quality control to obtain high quality data. They are based on the evaluation of basic data pre-processing procedures and existing quality assurance (QA) protocols. The main objective of quality control for operational data is to ensure data consistency for each measured parameter within a collection of operational data. One of the most important goals must be to assure that the quality and errors associated with the data are transparent to the user. Therefore, additional quality assurance procedures have to be applied and metadata must be collected regularly as quality assurance information. Data quality assurance information notifies users of the data about the way in which they were gathered, checked, and processed. It also provides information about the types of algorithms used, the kinds of errors that occurred, and how these errors were corrected or flagged. These common protocols include all steps, which are necessary to collect quality controlled operational data:
For BOOS, three classes of common protocols for operational real-time measurements have been defined:
Additional information on BOOS quality assurance is available in the PAPA report “Design of common protocols for data collection, transmission and quality control” which is available at this link:
http://www.boos.org/papa/doc/PAPA%20-%20Report%20on%20quality%20assurance.doc
Next Table summaries BOOS quality assurance protocols.
| Step | Description | Minimum Performance | Good Performance | Best Performance | |
| 1 | Pre-conditions | • use of accurate, low drift sensors (e.g. with fouling protection). • analog/digital data transmission protocols. | • use of accurate, low drift sensors (e.g. with fouling protection). • analog/digital data transmission protocols. | • use of accurate, low drift sensors (e.g. with fouling protection) and digital outputs. • digital data transmission protocols meet modern common standards with error protection. |
|
| 2 | Pre deployment calibration | • calibration from producer. • sensor / instrument check and documentation. | • current calibration from producer. • sensor / instrument check. • documentation of calibration parameters. • test of data transmission, processing performance and recording facilities. | • brand -new calibration from producer. • Sensor / instrument check and calibration with reference standards at laboratory. • documentation of calibration parameters. • test of data transmission, processing performance and recording facilities. |
|
| 3 | Pre deployment check | • check and comparison before deployment (e.g. ship borne CTD / water sample). | |||
| 4 | Deployment documentation | • recording of parameters (location, instrument information, meta information, sampling scheme etc.). | |||
| 5 | During deployment comparison | • reference measurements during deployment / measuring period for sensors/instruments with noticeable drift. | • reference measurements during deployment / measuring period (e.g. with ship borne CTD and water samples as often as possible). | • reference measurements during deployment / measuring period (e.g. every month with ship borne CTD and water samples or as often as possible). | |
| 6 | Post deployment check | • comparison measurements after deployment (e.g. ship borne CTD / water sample). | |||
| 7 | Post deployment calibration | • sensor- / Instrument check and calibration with reference standards at laboratory. • documentation of calibration parameters. |
|||
| 8 | Data pre-processing | • correction and validation by using reference / comparison measurements. • flagging /labelling of data (including meta data and validation steps). | • quality control of data (e.g. corrupted data, spikes, identification of gaps etc.). • transfer to files/databases. • flagging. | • automatic quality control of data (e.g. corrupted data, spikes, identification gaps etc.). • transfer to database. • flagging. |
|
| 9 | Data post processing | SAme as pre-processing | • correction and validation by using reference / comparison measurements. • application of quality flags to files / databases (including meta data and validation steps). |
||
| 10 | Data presentation | • user-friendly presentation of data, meta data and graphics. | |||