1/29
JCOMM Observations Programme Area
First meeting of the JCOMM Observations Coordination, La Jolla, 24-27 April 2002
Proposed integrated mechanism for relaying quality information on in situ marine
observing systems (initially buoys, XBTs, and Argo floats) in deferred mode from
real time data users back to data producers.
DRAFT
Executive summary:

This document proposes an integrated JCOMM mechanism for relaying quality information from
data users back to platform operators.

The platforms concerned are data buoys, XBTs, and sub-surface profiling floats operated by DBCP,
SOOP and Argo.

Real-time GTS data users such as ECMWF, NCEP, FNMOC, UKMO and Météo-France are in an
excellent position to estimate data quality, but generally lack the capability to relay that information
back to the platform operators.

Within DBCP, however, a system (BUOY-QC) has operated for many years which has successfully
implemented such a quality feedback mechanism. This system might be used as a model for quality
feedback for other platform types.

JCOMMOPS is tasked (by DBCP, SOOP, and Argo) to maintain lists of operational platforms and
platform operators and has the resources to collect such information, and to relay available QC
information back to the platform operators.

The model could be improved and rationalized to:
(i)
(ii)
(iii)
(iv)

make problem reporting consistent among the different types of platforms and
relatively easy for the data centres;
speed up and automate the relay of the information to the platform operators;
eventually save human resources at JCOMMOPS;
eventually shorten the delays for noticed problems to be corrected (e.g. removing
platform data from GTS, recalibrating a sensor).
The proposed feedback mechanism, based on the successful BUOY-QC, would:
(i)
(ii)
(iii)
establish the concept of Principal Meteorological or Oceanographic Centre
Responsible for the Quality control of real-time GTS data for relevant platforms
(PMOC). PMOCs would participate on a voluntary basis;
establish the concept of Principal GTS Coordinator (PGC), typically a person
designated by the platform operator to make operational status changes for the
platforms (e.g. recalibrating a sensor);
task JCOMMOPS to act as a focal point to coordinate the system. JCOMMOPS
would automate the system and provide web based products and electronic mailing
lists to facilitate reporting of problems by PMOCs and access to the information as
soon as possible by the PGCs.

The proposed scheme can be implemented with existing resources available at JCOMMOPS.

Several operational centres involved in data quality control of marine data already expressed interest
in developing such an integrated scheme (e.g. NCEP, Météo-France).
-1-
2/29
1) Background
At the last session of the Data Buoy Cooperation Panel (DBCP), Perth, October 2001, the Panel proposed to
investigate the possibility to integrate its so called Quality Control guidelines into JCOMM to also include other
observing systems such as XBTs and sub-surface profiling floats. This was proposed because (i) DBCP QC
guidelines is a very efficient mechanism to relay quality information from Principal Meteorological or
Oceanographic Centres responsible for the Quality Control of GTS buoy data (PMOC) back to buoy operators,
(ii) JCOMM is stressing to integrate its activities as far as possible, (iii) integration is possible with existing
resources, namely JCOMMOPS, at least for buoy, XBT and Argo float data.
The panel recalled that the DBCP QC guidelines were based upon the following principles which are also valid
for XBT and profiling float data if considered in JCOMMOPS context: (i) meteorological and oceanographic
centres are in the best position to operate quality control procedures, (ii) the technical coordinator is in the best
position to identify platform operators (e.g. based upon WMO number), (iii) principal GTS coordinators must be
designated by programme managers as being responsible to actually change platform status. The technical
coordinator reported that JCOMMOPS could provide tools to facilitate relay of QC information back to
programme managers regarding data buoys (existing DBCP PMOCs), XBTs (as is presently done by MEDS),
and profiling floats (e.g. UK met. Office, among other centres, to control the quality of southern ocean profiling
floats). Considering that such formal relay mechanisms do not presently exist for XBTs and profiling floats, and
there is a need for it, the panel agreed that such an integration could be valuable for these observing systems,
including of course data buoys, and therefore asked the technical coordinator to make a specific proposal which
would eventually be submitted to the JCOMM Observations Programme Area Coordination Group meeting in
early 2002.
2) Proposed relay mechanism within JCOMM
2.1) Principles:
The mechanism would be based upon the following principles:
a)
Concerned data: real-time buoy, XBT, and float data. These real-time data would basically be
GTS data, at least initially.
b) Purpose: Rationalizing and speeding up the mechanism to relay quality information from data
users or specialized centres (e.g. DACs, scientific centres) who are in the best position to operate
quality control procedures back to data producers who can take action when a problem is
identified.
c)
Quality Control: Meteorological centres and Oceanographic centres are in the best position to
operate QC procedures and estimate the quality of the data (e.g. see Annex A for QC procedures
by NCEP). In the context of the QC DBCP guidelines, these centres are called Principal
Meteorological or Oceanographic Centres responsible for Quality Control of GTS buoy data
(PMOC). A number of centres are presently acting as PMOC on a voluntary basis. However, the
proposed mechanism does not state what QC procedures should be used nor who should
undertake such procedures (except for buoy data with existing DBCP PMOCs). This will be the
responsibility of the JCOMM Data Management Programme Area to define independently from
this proposed relay mechanism. For readability of this document below, we may however call
these centres PMOCs although they are not defined here and should be defined in the context of
the JCOMM DMPA. They would at least initially include those PMOCs participating in the
DBCP QC guidelines. So far we have the following centres for buoy data:
·
·
·
·
·
·
·
·
The Australian Bureau Of Meteorology (ABOM),
Environment Canada (AES),
The European Centre for Medium-Range Weather Forecasts (ECMWF),
The Icelandic Meteorological Office (IMO),
The Japan Meteorological Agency (JMA),
Météo France (CMM, Centre de Météorologie Marine),
The Meteorological Service of New Zealand, Ldt. (NZMS),
The National Data Buoy Center (NDBC of NOAA, USA),
-2-
3/29
·
·
·
·
·
The National Center for Environmental Protection (NCEP of NOAA, USA,
see annex A),
The Pacific Marine Environmental Laboratory (PMEL of NOAA, USA),
The South African Weather Bureau (SAWB),
The United Kingdom Meteorological Office (UKMO).
The Marine Environmental Data Service (MEDS).
Also, GTSPP is presently providing two quality monitoring reports on upper ocean thermal data
which are being relayed to the SOOP operators.
d) Identifying platform operators: Data users, Quality Control centres do not necessarily know
who operate the platforms or who is in charge of GTS distribution of the platform data. All they
see are GTS reports with a WMO number to identify the platform but this do not tell them who
operates the platforms. Lists of WMO numbers with information on platform operators do exist.
These are generally updated monthly and are provided by the DBPC, SOOP, and Argo
Coordinators. However, in order to contact platform operators, PMOCs would have to consult
the different lists, perhaps develop specific tools in order to rationalize this work, and contact the
different platform operators each time a problem is identified.
e)
Focal point: DBCP, SOOP, and Argo coordinator have the responsibility of keeping lists of
operational platforms (i.e. data buoys, XBTs, Argo floats) and programme information up to date
and are therefore in a good position to identify platform owners. JCOMMOPS which includes
the coordinators is therefore in a good position to act as focal points and to relay that QC
information from PMOCs to data producers. This would make things easier for PMOCs since
they wouldn't have to worry regarding who operates a specific platform, and would have only to
notify JCOMMOPS each time a problem is identified.
f)
Principal GTS Coordinators: When problems are identified, platform owners are not
necessarily keen to take care of the operational GTS aspects such as removing platform data
from GTS, recalibrating a sensor, etc. In the context of the DBCP guidelines, Principal
Investigators can therefore designate so called Principal GTS Coordinator (PGC) who are in
charge of this task for their platforms. There can be one PGC for a programme or one PGC for a
coordinated programme (as is the case for the EGOS buoy programme for example where all PIs
had designated one single PGC for the whole EGOS programme). In a wider scheme, perhaps we
should call the PGC Principal Real-time delivery Coordinators (PRC) as there are now other
ways to distribute the data in real-time than the GTS (e.g. GTSPP, Argo DM).
g) Automation: With standardization of reporting procedures for the identified QC problems, it is
possible to automate the relay of such QC information. With the DBCP QC guidelines, it was
done by using a mailing list: subject line is standardized and includes the WMO number. With
access to a database containing WMO/Argos cross reference and Argos programme information,
it was possible to automatically redirect via emails QC messages sent to [email protected] mailing list by the PMOCs. In a more general scheme which would include
XBT and float data as well (which data can also be collected through other systems than Argos),
we would use a database which is maintained and constantly kept up to date by the
DBCP/SOOP/Argo coordinators at JCOMMOPS. We could also use a web based product
instead of a mailing list (or both): QC centre would go to a web page, enter minimum of
information such as WMO number, sensor name, description of the problem in a text box, click
on submit and the message would go directly to the PGC without having to know who actually
operates the platform. Other optional fields could be available to describe the problem e.g. GTS
bulletin header, filling out an URL where products are available for providing details (e.g. QC
graphs, maps, Obs versus first guess diagrams and statistics etc.). For those PGCs who do not
have email, the Argo/DBCP/SOOP Coordinators would intercept the QC information and
manually redirect it to the PGC by fax or some other mean. Also, sub-sets for specific platform
operators from the various quality monitoring reports presently being produced for buoy and
XBT data could be extracted and forwarded to them. Hence, platform operators would only
receive information from these monitoring reports for the platforms they operate. This would
permit to avoid them sorting out their platforms from a comprehensive lists of platforms and
would therefore ease their work and increase the likelihood of them to actually check these
reports.
-3-
4/29
2.2) The proposed mechanism
As defined above, we have the following actors playing:



PMOCs who operate quality control procedures and report identified problems. They also produce
specific quality monitoring reports.
JCOMMOPS who acts as a focal point for relaying identified problems back to data producers and for
relaying sub-sets of the monitoring reports to platform operators for the platforms they operate.
PGCs who are designated by platform operators to take action whenever a problem is identified
It is proposed to develop the following tools at JCOMMOPS in order to facilitate relay of quality control
information:



A dedicated electronic mailing list for PMOCs to report problems and submit specific quality
monitoring reports (e.g. buoy monitoring statistics, GTSPP monitoring reports).
A web page where PMOCs can go and report problems through filling out a simple form.
A web page where platform operators can go and consult history of problems previously reported for a
particular platform or series of platforms.
PMOCs would have the option of either using the mailing list or the dedicated web page to report problems.
Specific monitoring reports which include quality information regarding specific types of platforms would only
be submitted via the mailing in an agreed format. Format might be inspired from the present recommended
DBCP format for the buoy monitoring statistics produced by ECMWF, UKMO, Météo France, and NCEP (see
annex B).
The operations of the proposed mechanism would:
(i)
(ii)
(iii)
(iv)
make problem reporting consistent among the different types of platforms and relatively easy for the
data centres (PMOC),
speed up and automate relay of the information to the platform operators,
eventually save human resources at JCOMMOPS,
eventually shorten the delays for noticed problems to be corrected (e.g. removing platform data
from GTS, recalibrating a sensor).
2.2.1) The electronic mailing list
The electronic mailing list would basically include (i) PMOCs so that each time a given PMOC makes a specific
comment regarding the quality of a platform, all other PMOCs receive the information and can have the
opportunity to comment and perhaps to provide complementary information or even suggest that the data were
actually good, (ii) JCOMMOPS so that the information can be redirected to the platform operator, (iii) PGCs and
platform operators so that they have a record of the information provided for all platforms, including those that
they do not operate, (iv) any other person interested in receiving such information (e.g. other data users). Note
that PGCs and platform operators don't necessarily have to register on the mailing list because they would
systematically and automatically receive the information for their specific platforms directly from JCOMMOPS.
Messages sent onto the mailing list would only be related to the quality of in situ marine data which are being
received in real time. A specific format for the subject line when reporting problems will be proposed. Specific
monitoring reports for each type of platform would also be distributed by PMOCs onto the mailing list.
Establishing an electronic mailing list is a straight forward thing to do which can easily be done by JCOMMOPS
using existing resources. Automating relay of messages to the PGCs would require some software development
which could be realized at JCOMMOPS using existing resources. However, the subject line would have to be
standardized as is done in the context of the DBCP QC guidelines, basically to automatically extract WMO
number from the message, in order to automate redirection of the messages to the PGCs.
2.2.2) The web form to report problems
-4-
5/29
PMOCs would also have the option of using a dedicated web page at JCOMMOPS for entering information
regarding a particular problem they noticed with an observing platform. Information would be entered through a
simple web form which would include mandatory and option fields such as (mandatory fields are indicated in
bold below):









Name of PMOC
Type of comment (i.e. request to suppress from GTS, recalibration asked, just comment)
WMO number
GTS format (e.g. BUOY, TESAC, BATHY)
Name of sensor (or "all" sensors if the whole platform is concerned)
Short comment in free format explaining what the problem is
GTS bulletin header
Image providing specific evidence and explaining the problem
URL (web address) of specific tools made available by the PMOC which can be used by the platform
operator to understand what the problem is.
Using the WMO number, JCOMMOPS would automatically redirect the information to the PGCs. This would
require specific software developments at JCOMMOPS which could be realized using existing resources.
2.2.3) The web page to consult list of identified problems
Although they automatically receive information on notified problems by PMOCs via JCOMMOPS, PGCs and
platform operators would be able to consult the archives of previously reported problems. This is useful to obtain
an history of problems for a specific platform or the list of problems for nearby stations so that inter-comparisons
if required can be made in an informed manner. System would provide a user-friendly search engine in order to
extract needed information rapidly from the JCOMMOPS database which would contain all the QC reports
received from all PMOCs. Search engine would permit to sort out messages based upon the following
information:











Name of PMOC who notified problem
Type of comment (i.e. request to suppress from GTS, recalibration asked, just comment)
WMO number
GTS format (e.g. BUOY, TESAC, BATHY)
Name of sensor (or "all" sensors if the whole platform is concerned)
Specific ASCII character string from the PMOC comments describing problems
GTS bulletin header
Platform position or area (e.g. a box)
The type of platform
The name of the agency operating the platform
The country of the agency operating the platform
Results would include all information meeting selected criteria and provided by the PMOCs when they notified
problems.
This would require specific software developments at JCOMMOPS which could be realized using existing
resources.
2.3) Role of JCOMMOPS and required resources
JCOMMOPS which includes the DBCP, SOOP, and Argo Coordinators (i.e. two full time persons) would be
responsible for (i) implementing the mailing list, (ii) developing tools and web pages, (iii) developing automated
procedures to redirect QC messages from PMOCs back to PGCs, (iv) redirecting the QC messages manually
when automated procedures are not applicable (e.g. syntax error in subject line, or PGC does not have email and
must be contacted by fax or telephone), and (v) developing automated procedures to automatically extract subsets from the quality monitoring reports for specific platform operators and relay these sub-sets to them.
This work is consistent with the Terms of References (ToR) of JCOMMOPS although a task team on Ship
Observations Team coordination is working on a detailed development plan for SOT coordination activities
-5-
6/29
where JCOMMOPS could play a role (see final report of first SOT meeting, Goa, 25 February - 2 March 2002).
JCOMMOPS ToR might therefore be changed according to the conclusions of the task team. The plan should be
available by September 2002, for consideration by the Observations Coordination Group, and eventually by the
JCOMM Management Committee at its second session in early 2003. One of the JCOMMOPS ToR presently
says "Assist as appropriate in relaying quality control information produced by relevant data centres to the
responsible observing platforms managers". It is therefore recommended to keep this ToR.
Note also that proposed mechanism is also consistent with the ToR of the Technical Coordinator of the DBCP,
the Coordinator of SOOP, and the Technical Coordinator of Argo who provide the human resources needed to
run JCOMMOPS.
At the same time, as detailed in above paragraphs, no additional resources would be needed to develop
this mechanism as the resources are already provided by the DBCP, SOOP, and Argo.
2.4) Implications for the DBCP, SOOP, Argo
It is proposed to integrate this feedback mechanism only for the DBCP, SOOP, and Argo programmes mainly
because there are resources available to do that at JCOMMOPS through the DBCP&SOOP Technical
Coordinator, and the Argo Technical Coordinator. No extra resources are needed. Below are detailed
implications of establishing such a scheme fir each of those Panels.
One should notice that observing cycles and data availability delays are substantially difference for the various
observing systems considered:



Data buoys: 1 to 3 hours for the observing cycle; 30 minutes to a few hours for the delays.
XBTs: Cycle depends upon line sampling (typically one hour for HDX lines, and a few hours for LDX
and FRX lines); delays ranging from 30 minutes to one hour for data collected in real time to several
days or weeks for the data which were collected in delayed mode only.
Argo floats: 10 days for the observing cycle; delays ranging from 1 hour to 24 hours.
Also the nature of the quality control procedures and tools being used would substantially vary depending upon
the type of data which are being considered. For example, for buoy data which produce mainly surface
meteorological data in GTS reports, extensive use is being made of NWP models and first guess field. This
would not be the case for sub-surface profile data which would rely mostly on specific tools (e.g. GTSPP
monitoring report), manual checks, comparisons with the climatology, and possibly use of ocean models in the
near future.
For these reasons, the delay for quality control centres to provide feedback might vary substantially for the
different types of observing platforms. This does not however prevent integration of the feedback mechanism for
all three observing systems.
2.4.1) Implications for the DBCP
There are already so called DBCP QC guidelines which provide a similar feedback mechanism (see annex B).
The DBCP agrees that these proved very efficient. However, integrating the DBCP guidelines into a wider
scheme to include also XBT and Argo profiling float data would substantially change the way the DBCP
guidelines are functioning. Among implications we have:
1.
2.
3.
Dedicated mailing list will need to be renamed. Present mailing list ([email protected]) is maintained
by the Icelandic Meteorological Office. We can investigate whether the IMO would be willing to
continue providing similar support for a new integrated mailing list which would include more names
and might therefore require a little bit more resources to maintain. In the contrary mailing list service
could be offered by JCOMMOPS where resources exist to provide that service.
All participating DBCP PMOCs will have to be contacted and made aware that a new mailing list
replaces the [email protected] one and that the format in which to make comments through the mailing
list (subject line) changed. This would have come implications on the way they operate. They might
have developed specific tools to prepare their QC messages which they'll have to upgrade.
New dedicated web page will be introduced so the PMOCs will have the option of either using the
mailing list or the web page to make comments regarding the quality of the data. This should make
-6-
7/29
4.
things more flexible for them. Some may actually decide to use the web form only in order to avoid
upgrading the tools they developed for preparing the QC messages.
There would not probably be the need to change the format in which the buoy monitoring statistics are
formatted as these are (i) specific to buoy data (e.g. specific algorithm was proposed for wind direction),
and (ii) efforts were made in recent years to have consistency between the various monitoring statistics
produced (ECMWF, NCEP, UKMO, Météo France) and the process took a long time; trying to have
consistency among the various monitoring reports produced for the DBCP, SOOP, and Argo would be
an almost impossible tasks considering that the nature of the products is different in essence (e.g.
comparisons with first guess field for buoy data (NWP), specific QC procedures for sub-surface profile
data using oceanographic tools).
2.4.2) Implications for SOOP
GTSPP is producing several monthly monitoring reports, including: (i) a QC report providing information on
specific problems according to QC procedures operated by MEDS, (ii) data quality statistics (e.g. number of
stations per cruise, number of stations which failed QC specific tests), (iii) JJXX/JJYY/JJVV and KKXX/KKYY
reports to monitor BATHY and TESAC code changes implementation respectively, and (iv) line reports, which
tentatively automatically allocate line numbers to received GTS reports.
There is presently a feedback process for SOOP mainly through the work of GTSPP (monitoring reports above)
and the work of the SOOP Coordinator acting as a focal point and contacting the SOOP participants directly
when problems are noticed. However, this process is not optimised at the moment. Proposed feedback
mechanism would (i) rationalize the process, (ii) provide automation, (iii) ease the work of the SOOP
Coordinator, and (iv) eventually speed up the relay of quality information back to the SOOP operators. At the
same time, the SOOP operators would get information specifically regarding the ships they operate. Hence they
would not have to sort out the ships they operate from the various monitoring reports they get since this would be
done automatically in the integrated scheme at JCOMMOPS.
New integrated scheme would provide an efficient media for relaying quality information from existing (GTSPP)
and future quality monitoring centres which work will be defined through the JCOMM Data Management
Programme Area back to SOOP operators.
2.4.3) Implications for Argo
Argo is still in its conceptual phase at this point and specific deferred time data quality control procedures are
being defined by the Argo Data Management Team. There is no specific plan to establish an integrated
mechanism for relaying quality information eventually produced through these QC procedures back to the float
operators. Each float operator of course handles QC procedures on his own. However, a float operator might be
interested to know how other centres in other countries using different tools estimate the quality of their floats.
The UK is for example establishing a regional data management centre for southern ocean Argo float data and
might develop specific quality control procedures to deal with float data in this region (e.g. cold waters). All float
operators should take advantage of the results from these QC procedures. This can be done provided that a sound
relay mechanism exists. Argo Data Management Team will probably take some time to develop its QC
procedures. Meanwhile, there are tools already available such as the monitoring reports produced by GTSPP for
temperature and salinity profile data (see paragraph above regarding implications for SOOP) and the QC
procedures already being operated at the national level. All float operators are of course interested to know about
the results from these procedures and the integrated relay mechanism proposed here would be an efficient way of
doing it.
2.5) Coordination with JCOMM Data Management Programme Area
As detailed above, the concept of Principal Meteorological or Oceanographic Centre responsible of the quality
control of real-time data from in situ marine platforms (PMOC) needs to be defined and specific PMOCs
selected. This can only be done in the context of the JCOMM Data Management Programme Area. By no way
this proposal is defining that concept nor what the QC procedures should be. However, whatever QC procedures
are proposed by the JCOMM DMPA, results from evaluation of the quality of real time in situ marine data will
have to be relayed to the data producers. It is proposed that this will be the role of this relay mechanism.
At the same time, this relay mechanism proposed by the JCOMM OPA will have to be reviewed by the JCOMM
DMPA as well and possibly adopted by both Programme Area as an integrated JCOMM mechanism. It could
actually be implemented initially as a pilot project, then reviewed, and eventually proposed for adoption by the
JCOMM Management Committee.
-7-
8/29
2.6) Proposed recommendations by the JCOMM Observations Coordination Group
The meeting is invited to adopt the following recommendations




Keep in JCOMMOPS ToR the one related to the relay of quality information from data users back to
data producers.
Submit the proposal to the JCOMM Data Management Programme Area, seek comments, amendments,
and possible approval. Ask JCOMM DMPA to define the concept of PMOC and seek participation of
specific PMOCs.
Establish an interim pilot project and Task Team to develop the mechanism, including the format in
which to report problems and the monitoring report, and eventually review its efficiency. Before the
JCOMM DMPA make specific recommendations in this regard, participating PMOCs would initially be
those presently participating in the DBCP QC guidelines plus these centres already involved in data
quality evaluation of profile data from SOOP and Argo (e.g. GTSPP).
If agreeable by the DMPA and the OPA, eventually submit the proposal to the JCOMM Management
Committee.
-8-
9/29
Annex A
Information on Manual Surface Marine QC Flags at NOAA/NCEP
Real-time interactive quality control (QC) of global surface marine meteorological data
and sea surface temperature is performed by meteorologists of NCEP's Marine
Prediction Center (MPC). The interactive program used by MPC meteorologists to
perform this QC is known as CREWSS (Collect, Review, and Edit Weather data from
the Sea Surface). CREWSS replaces the old QUIPS (QUality Improvement
Performance System) program, which ran on outdated VMS-based VAX workstations
that were not Y2K- compliant. CREWSS runs on several UNIX-based HP workstations
located at MPC. CREWSS has the same basic functionality as QUIPS but has a new
graphical interface and runs faster than QUIPS. The CREWSS system was developed
and is maintained by computer specialists of NCEP/Central Operations (NCO).
CREWSS compares global surface marine data (downloaded from an NWS IBM
supercomputer) to first guess fields (usually, a 6 hour forecast from NWS's Aviation
model (AVN) for all 4 synoptic periods). Data that differ from the first guess fields by
more than certain amounts are flagged for the MPC meteorologist to QC via CREWSS
(see Table 1 for CREWSS flagging criteria). The meteorologist must decide whether the
flagged data are correct or incorrect when compared to the first guess fields and can set
keep or reject flags on the data in question. Corrections to data may also be made. Upon
completion of interactive QC, an ASCII text file containing all QC flags and corrections
is then uploaded to the NWS IBM for assimilation by NWS numerical models. QC
decisions and corrections may be accessed by any program retrieving surface marine
data from the NWS IBM BUFR database.
Table 1: Flagging Criteria for CREWSS
Parameter
Threshold
Sea-level pressure (SLP)
+/- 4.0 mb
Air temperature
+/- 8.0 deg C
Wind direction
140 degrees
Wind speed
+/- 15.0 kts
Sea surface temperature (SST) +/- 8.0 deg C
At present, QC is performed on surface marine meteorological data and sea surface
temperatures received from the following platform types:





Ships
Moored buoys
Drifting buoys
Coastal Marine Automated Network (CMAN) Platforms
Tide gauge stations
-9-
10/29
The complete Surface Marine QC Flags file contains all QC flags and decisions made
by MPC meteorologists for approximately the last 3 weeks (maximum file size is 9000
lines). This file is updated every time the QC flags file (produced via CREWSS) is
uploaded to the IBM. The most recent QC flags are at the bottom of the file. The oldest
QC flags will be deleted from the top of the file each time the flags file is updated. The
following sample data are used to explain the format for the QC flags file:
64528
325
QL05744QG02188
VGMV
4230
ELVF6
4270
OW34041QW34014
SYFT
4060
OP10010QP10110
WPGK
5060
0108QT00108
46181
5380
SHIP
-3430
73506
-6221
8VSBU2
-1290
DUCN7
3620
MD020
3898
OUNI5
3960
QG04930
20190 20001007 1800
562
8710 20001007 1800
13010 20001008 0300
522 PH
522
34160 20001008 1200
522
14910 20001008 1200
522
12880
4750
26499
24390
7570
7648
9430
561 H
523 PPPP
562 P P
522L P
VSBU2
531 H
532
H
522
20001008
20001009
20001009
20001009
20001009
20001009
20001009
1300
1200
1100
1200
1200
1200
1200
OT-
The format is as follows:
Parameter
Column(s) Description
Callsign
1-8
Original callsign or WMO id. Letters should be upper
case.
Latitude
10 - 14
Latitude x 100. (e.g. -1290 = 12.90S; 4230 = 42.30N)
Longitude
16 - 20
Longitude x 100. From 0 degrees to 360.00 (encoded as
36000) westbound, so 14910 = 149.10W, 20190 =
158.10E (360.00 - 201.90 = 158.10), etc.
Date
22 - 29
Observation date. Format is YYYYMMDD.
Time
31 - 34
Observation time, in UTC. Format is HHMM (hours and
minutes).
Report type
37 - 39
Platform type:
-10-
11/29
522
= named ship
523
= unnamed ship
531
= CMAN platform
532
= tide gauge station
561
= moored buoy
562
= drifting buoy
40
If the ob is a duplicate of another, the letter 'L' will be
placed in this column. The report will not be used by
NWS numerical models.
41
'P' for purged (rejected) SLP, 'H' for held (kept) SLP,
blank if neither. Please note that if the SLP is purged, the
entire report will be rejected for use by NWS numerical
models, regardless of flags set on other parameters. A
keep flag ('H') will force the NWS models to use the
report's SLP. If no flag is set on the SLP, the numerical
models' built-in QC programs may still decide to toss the
report, or they may decide to keep it. Flags set on other
parameters will be checked by the models if the SLP has
a keep flag set, or if the SLP has no flag set and the
models' built-in QC decides the SLP is of neutral or good
quality.
Wind flag
42
'P' for rejected wind dir or wind speed, 'H' for kept wind
direction or wind speed, blank if neither. NOTE: there
can't be a keep on wind dir and a purge on wind spd (or
vice versa). Speed and direction are converted back to uand v-wind components when used in NWS numerical
models, so there can't be a direction with no speed or
speed with no direction. Wind direction and speed must
either both be kept or both purged, which is why there's
only one flag for the winds (not separate columns for
direction and speed).
Air temp.
flag
43
'P' if air temp. was rejected, 'H' if it was kept, blank if
neither.
SST flag
44
'P' if SST was rejected, 'H' if it was kept, blank if neither.
Callsign
correction
46 - 53
If the callsign was corrected, the new callsign goes here.
Letters are in upper case.
56 - 123
Corrections to latitude, longitude, SLP, wind, air temp.,
and/or SST. If the correction is to a parameter other than
latitude or longitude, the original value for that parameter
must precede the corrected value. The original values for
Duplicate
flag
SLP flag
Data
corrections
-11-
12/29
parameters other than latitude or longitude are designated
by the letters 'O' and either a 'P' (SLP), 'T' (air temp.), 'W'
(wind), or 'S' (SST), immediately followed by the
original value as read from the NWS BUFR file. The
quality-controlled values for all parameters are
designated by the letters 'Q' and either an 'L' (latitude),
'G' (longitude), or one of the four letters previously given
('P', 'T', 'W', or 'S') for the other parameters, immediately
followed by the corrected value for that parameter. The
original values for latitude and longitude are found in
columns 10-14 and 16-20, respectively.
QC flag/correction examples
Example 1:
64528 325 20190 20001007 1800 562
QL05744QG02188
Drifting buoy 64528 was originally located at 3.25N 158.10E. The observation date is
October 7, 2000 and obs. time is 1800 UTC. Its latitude was corrected to 57.44N and its
longitude was corrected to 21.88W.
Example 2:
VGMV
4230 8710 20001007 1800 522 PH
Ship VGMV is located at 42.30N 87.10W. The observation date is October 7, 2000 and
obs. time is 1800 UTC. Its SLP observation was purged and its wind observation was
kept.
Example 3:
ELVF6 4270 13010 20001008 0300 522
OW34041QW34014
Ship ELVF6 is located at 42.70N 130.10W. The observation date is October 8, 2000
and obs. time is 0300 UTC. Its original wind has direction 340 at 41 kts and its
corrected wind has direction 340 at 14 kts. NOTE: For the 5 digits that follow 'OW' and
'QW', the wind direction (divided by 10) is the first 2 digits and wind speed is the last 3
digits. Wind direction is direction from true (north) and wind speed is in knots, so for
this example, original wind direction of 34 means 340 degrees and wind speed is 041
kts. Corrected wind has direction of 340 (encoded as 34) and wind speed of 14 knots
(encoded as 014).
Example 4:
SYFT
4060 34160 20001008 1200 522
OP10010QP10110
Ship SYFT is located at 40.60N 18.40E. The observation date is October 8, 2000 and
obs. time is 1200 UTC. Its original SLP is 1001.0 mb and its corrected SLP is 1011.0
mb.
Example 5:
WPGK
5060 14910 20001008 1200 522
-12-
OT-0108QT00108
13/29
Ship WPGK is located at 50.60N 149.10W. The observation date is October 8, 2000
and obs. time is 1200 UTC. Its original air temperature is -10.8 deg C and its corrected
air temperature is 10.8 deg C. SST corrections are done in the same way (also in degrees
C), except the letters 'OS' and 'QS' are used.
Example 6:
46181 5380 12880 20001008 1300 561 H
Moored buoy 46181 is located at 53.80N 128.80W. The observation date is October 8,
2000 and obs. time is 1300 UTC. Its wind was kept.
Example 7:
73506 -6221 26499 20001009 1100 562 P P
Drifting buoy 73506 is located at 62.21S 95.01E. The observation date is October 9,
2000 and obs. time is 1100 UTC. Its SLP and air temperature were purged.
Example 8:
SHIP -3430 4750 20001009 1200 523 PPPP
Unnamed ship SHIP is located at 34.30S 47.50W. The observation date is October 9,
2000 and obs. time is 1200 UTC. Its SLP, wind, air temp., and SST were all purged.
Example 9:
8VSBU2 -1290 24390 20001009 1200 522L P VSBU2
Ship 8VSBU2 is located at 12.90S 116.10E. The observation date is October 9, 2000
and obs. time is 1200 UTC. It is a duplicate report, its wind was purged, and its callsign
was corrected to VSBU2.
Example 10:
DUCN7 3620 7570 20001009 1200 531 H
CMAN station DUCN7 is located at 36.20N 75.70W. The observation date is October
9, 2000 and obs. time is 1200 UTC. Its SLP was kept.
Example 11:
MD020 3898 7648 20001009 1200 532 H
Tide gauge station MD020 is located at 38.98N 76.48W. The observation date is
October 9, 2000 and obs. time is 1200 UTC. Its air temperature was kept.
Example 12:
OUNI5 3960 9430 20001009 1200 522
QG04930
Ship OUNI5 was originally located at 39.60N 94.30W. The observation date is October
9, 2000 and obs. time is 1200 UTC. Its longitude was changed to 49.30W.
Please note that there may be multiple parameter corrections for a single report. If
multiple corrections exist, the hierarchy for them (beginning in column 56) would be:

original SLP
-13-
14/29









corrected SLP
corrected latitude
corrected longitude
original air temperature
corrected air temperature
original SST
corrected SST
original wind
corrected wind
Files available on web site
Five QC Flag files are available on NCO's web site as follows:
Complete File
contains all QC flags for approximately the last 21 days (total
of 9000 entries)
Current Day
contains all QC flags for the current day, beginning at 0000
UTC
Previous Day
contains all QC flags for the previous day (0000 UTC thru 2359
UTC)
Current Week
contains all QC flags for Current Day through Current Day - 6
(Day - 6 begins at 0000 UTC of that day or the earliest QC flag
time available for that day, if no 0000 UTC flags are available).
E.g. if current day is September 23, 2000, this file would
contain QC flags for September 23, 2000 back through 0000
UTC of September 17, 2000 (or the earliest available on Sep.
17)
Previous Week
contains all QC flags for Current Day - 7 through Current Day 13 (if available). E.g. if current day is September 23, 2000, this
file would contain QC flags for September 16, 2000 back
through September 10, 2000. Due to the 9000 line limit on the
Complete File, the Previous Week file may contain QC flags
for less than 7 days
All 5 Surface Marine QC Flags files are sorted in the following order:





observation date (oldest data at top of file, newest data at bottom of file).
observation time
WMO id/callsign
latitude
longitude
Users of these files who have access to a Unix PC or workstation, and who wish to see
only those QC decisions for a particular platform, may download the file(s) to their
-14-
15/29
workstation/PC and use the Unix 'grep' command to extract only those QC decisions for
the desired platform.
Questions
Any questions regarding the manual surface marine QC flags may be directed to NCO's
QC Flag Specialist.
National Weather Service Web Page Disclaimer
Last updated Oct. 25, 2000
-15-
16/29
Annex B
DBCP Quality Control Guidelines
At its seventh session (Toulouse, October 1991), in order to rationalise and speed up status change process of
buoys reporting bad data onto the GTS, the Data Buoy Co-operation Panel decided to implement on a trial basis
Quality Control Guidelines for buoy data. The guidelines worked effectively on 20 January 1992. It formally
endorsed these at its following session (Paris, October 1992).
At the tenth session of CBS (Geneva, November 1992), the Guidelines were formally incorporated as part of the
World Weather Watch (WWW).
The scheme is based on an Internet distribution list (i.e. mailing list) used by all actors involved in the process.
Particularly, when felt necessary, and according to quality control procedures they undertake on their own,
Principal Meteorological or Oceanographic Centres (PMOC) responsible for Buoy data Quality Control can make
status change proposals by the mean of an Internet mailing list ([email protected]). The meteorological
centres are indeed in the best position to undertake Quality Control procedures. The Technical Co-ordinator of the
DBCP, acting as a focal point between these centres and the owners of the buoys forwards the proposals to them.
In addition, monthly buoy monitoring statistics produced by PMOCs and WMO/Argos list of identification
numbers as well as the list of Principal GTS Co-ordinators are available via the mailing list.
The following PMOCs are presently participating actively in the Guidelines:












The Australian Bureau Of Meteorology (ABOM),
Environment Canada (AES),
The European Centre for Medium-Range Weather Forecasts (ECMWF),
The Icelandic Meteorological Office (IMO),
The Japan Meteorological Agency (JMA),
Météo France (CMM, Centre de Météorologie Marine),
The Meteorological Service of New Zealand, Ldt. (NZMS),
The National Data Buoy Center (NDBC of NOAA, USA),
The National Center for Environmental Protection (NCEP of NOAA, USA),
The Pacific Marine Environmental Laboratory (PMEL of NOAA, USA),
The South African Weather Bureau (SAWB),
The United Kingdom Meteorological Office (UKMO).
Full description of the Guidelines is given in annex A. Information regarding the
mailing list and how to register is given in annex B
For Internet mailing list matters, you can contact Ms. Halla-Bjorg Baldursdottir of the
Icelandic Meteorological Office directly:
Email:
[email protected]
Telephone: (+354) 560 06 00
Fax:
(+354) 552 81 21.
For details regarding the DBCP QC Guidelines, you can contact Etienne Charpentier,
Technical Co-ordinator of the DBCP:
Email:
[email protected]
Telephone: (+33) 5 61 39 47 82
Fax:
(+33) 5 61 75 10 14
-16-
17/29
Annex A:
Quality Control Guidelines for GTS buoy data
These are principles adopted during previous DBCP sessions:
(i)
Meteorological Centres are in the best position to undertake data Quality Control (DBCP VI).
(ii)
Principal Investigators and Meteorological Centres share the responsibility of data Quality Control
(DBCP VI).
(iii)
The Technical Co-ordinator is in the best position to act as a focal point between GTS users and
Principal Investigators (DBCP V, VI).
(iv)
Argos is responsible for assuring that gross errors are automatically eliminated from reports
distributed on GTS (DBCP VI).
In order to realise these principles, the following operating procedures or actions are proposed:
1.
PGCs
Each Principal Investigator (PI) of an Argos buoy programme reporting data on GTS, designates
a person responsible for making changes on PTT or sensor information present in the Argos GTS subsystem. This person is named the Programme GTS Co-ordinator (PGC). The PGC can, of course, be the
PI himself but could also be a designated programme Technical Co-ordinator, as is done for the EGOS
programme. If such a person does not exist as yet, for a given Argos Programme, the Technical Coordinator of the DBCP would contact the Principal Investigator and discuss the issue in order to find one.
In a few cases, when a PI allows his platforms being distributed on GTS but does not want to be involved
in the process, the Technical Co-ordinator could act as a PGC (i.e. the Technical Co-ordinator of the
DBCP can directly ask Argos to make status changes).
The Technical Coordinator of the DBCP is in charge of maintaining the list of PGCs.
2.
PMOCs
The DBCP requests one or more Agencies or Institutions to volunteer for acting as Principal
Meteorological or Oceanographic Centre responsible for deferred time GTS buoy data Quality Control
(PMOC). PMOCs work on an operational basis, for given physical variables, either regionally or globally.
The following centres are presently acting as PMOCs:
-
The Australian Bureau Of Meteorology (BOM, Melbourne, Australia);
-
Environment Canada (AES, Edmonton, Canada);
-
The European Centre for Medium Range Weather Forecasts (ECMWF, Reading, United
Kingdom);
-
The Icelandic Meteorological Office (IMO, Reykjavik, Iceland);
-
The Japan Meteorological Agency (JMA, Tokyo, Japan);
-
Météo-France (the Centre de Météorologie Marine, Brest, France);
-
The Meteorological Service of New Zealand, Ltd. (NZMS, Wellington ,New Zealand);
-
The National Data Buoy Center (NOAA/NDBC, Stennis Space Center, Mississippi, USA);
-
The National Center for Environmental Prediction (NOAA/NCEP, Camp Spring, Maryland,
USA);
-17-
18/29
-
The Pacific Marine Environmental Laboratory (NOAA/PMEL, Seattle, Washington, USA);
The United Kingdom Meteorological Office (UKMO, Bracknell, UK).
-
The South African Weather Bureau (SAWB, Pretoria, South Africa).
National Focal Points for Drifting Buoy Programmes are requested to designate National
PMOCs, and possibly to act themselves as PMOCs.
3.
INTERNET distribution list (mailing list).
It is proposed that the mechanism for exchanging QC information among the Guidelines Participants shall
be an INTERNET distribution list. PMOCs send the proposed messages to a unique INTERNET address
which name is BUOY-QC@node_path. "node_path" depends upon who actually operates the distribution
list. The full INTERNET address of the Distribution List shall be circulated among the Guidelines
participants.
To date the Icelandic Meteorological Office is operating the distribution list server and the Internet
address is:
[email protected]
The messages are then automatically forwarded to all the individual addresses from a maintained
distribution list. Adding, reading, modifying, or deleting a name form the list can be done via INTERNET
messages according to an agreed format.
3.1
ECMWF, NOAA/NCEP/NCO, METEO FRANCE, and UKMO monitoring statistics are
delivered onto the INTERNET Distribution List.
3.2
Any suggestion for modification (i.e. recalibrate or remove sensor from GTS) or any problem
noticed (e.g. bad location) on a drifting buoy reporting data on GTS should be placed on the Distribution
List. Meteorological Centres are encouraged to make such suggestions.
3.3
Any feed back available on a recalibration actually implemented shall be placed on the
distribution list.
4.
Operating Procedures for dealing with Potential Problems on GTS (Drifting and Moored
Buoy data)
4.1
PMOCs noticing potential problems on GTS can suggest an action via the INTERNET
Distribution List. A standardised, telegraphic format is proposed (see Appendix): one message per
platform or per sensor, showing the WMO number and the proposed change, directly in the "subject" line,
with additional comments appearing in the text itself, using a free format if felt necessary by the PMOC
(see example in Appendix).
4.2
PMOCs noticing bad location or bad sensor data episodically appearing on GTS message can
copy the message on the INTERNET Distribution List, indicating from which source the message was
transmitted. Although it is recommended that LUT operators access to the INTERNET Distribution List
as well, if not possible, the Technical Co-ordinator of the DBCP or the responsible PGC or a designated
PMOC (see paragraph 4.7.2) would keep them informed by telefax or another mean.
4.3
The Technical Co-ordinator of the DBCP can immediately (including using automated tools)
contact the Principal GTS Co-ordinator (usually the person in charge of the buoy programme) and
forward the PMOC message to him. It is recommended that the PGC waits for a few days before taking
any action unless he/she is confident enough in the quality status of the data. Other meteorological centres
-18-
19/29
may therefore have an opportunity to also comment on a particular problem. Other data users who are on
the INTERNET Distribution List are encouraged to check the received messages regularly.
4.4
Then, if the PGC accepts the modification, he requests the adequate Argos centre (i.e. CLS or
SAI) to make the change. In order to keep the GTS user community informed, Service Argos announces
the change as soon as possible by means of the INTERNET Distribution List (a standardised message is
proposed in the Appendix) and also effects the change as prescribed. It is recommended that the PGC also
requests appropriate LUTs to implement the same changes.
4.5
If the PGC is not willing to go ahead with a proposed change, the Technical Co-ordinator of the
DBCP deposits a standardised message on the INTERNET Distribution List (see Appendix) in order to
inform PMOCs.
4.6
Local User Terminals are urged to adopt these Quality Control Operating Guidelines.
4.6.1
It is desirable that LUTs not willing to participate should distribute drifting buoy data on GTS
only to local users (i.e. no global GTS distribution).
4.6.2
LUT operators participating and registered on the INTERNET Distribution List are encouraged
to inform the participants back by the mean of the Distribution List each time a change is implemented,
using the same format as Argos (see paragraph 4.4). If LUTs are not on the Distribution List, they would
be encouraged to inform the Technical Co-ordinator of the DBCP of actual changes so that he can
forward adequate messages onto the Distribution List.
5.
List of PGCs
This list is published by the Technical Co-ordinator of the DBCP on a monthly basis. It is
forwarded onto the INTERNET Distribution List and sent by regular mail.
6.
DBCP, WMO and IOC Secretariats
They will promote these Quality Control operating guidelines and encourage participation in this
scheme.
-19-
20/29
Operating QC Guidelines for buoy data
Principal GTS
Co-ordinator
(PGC)
Service Argos
Local User
Terminals (LUT)
GTS
Feed-back
on changes actually
implemented
BUOY-QC
mailing list
GTS
WMO/Argos &
PGC lists
Buoy status change
proposals or comments,
Buoy monitoring statistics
Principal
Meteorological or
Oceanographic Centre
(PMOC)
Technical Coordinator of the DBCP
(TC DBCP)
-20-
21/29
Appendix
Standardized Format for Information Deposited on the INTERNET Distribution List
Notations:
-1-
UPPERCASES in bold are constant field values and will appear "as shown" in the subject line;
e.g. ASK will appear as the 3 characters 'ASK' in the subject line.
-2-
Lowercases are used to designate variable data fields; If the name of the field is on 5 characters,
then the field value must be coded using 5 characters (completed with spaces if necessary); e.g.
ttt can be coded as 'AP ' to indicate Air Pressure or as 'SST' to indicate Sea Surface Temperature.
-3-
The line 12345678901234567890123456789012 is just here to indicate the number of
characters used (32 maxi) and their position; It has no other specific meaning.
1.
Proposals for status change (by Meteo Centres, i.e. PMOCs):
When detecting bad data circulating on GTS, Meteorological Centres can propose changes on buoy status
(remove or recalibrate sensor) via the INTERNET Distribution List. Proposals are done using a
standardised telegraphic format in the subject line. Comments can be added in the body text.
Format:
12345678901234567890123456
hASK ttt wmo## ppp ovalue
Meaning:
It is proposed to remove or recalibrate one or more sensors for one given buoy.
h:
One figure, 1 to 9, to indicate the number of the request for the same buoy, for example, the first
proposal would be coded 1ASK..., and if another Meteo Centre feels necessary to comment on
the same proposal, it can suggest another action and name it 2ASK, etc...
ttt :
Type of proposal:
RMV :
for removing sensor data from GTS
REC
:
for recalibrating a sensor
CHK :
for checking data carefully; in that case, it is recommended to add in the body text
of the message: (1) Example(s) of the suspicious or erroneous GTS message(s), (2)
the GTS bulletin header that was used (i.e. originating centre for the bulletin), (3) a
description of the problem and (4) if possible, proposed action to solve it.
COM :
for commenting on a particular problem. Explanation is given
in the body text of the message.
wmo## : WMO number of the buoy (A1bwnbnbnb) or LIST if more than one buoy are concerned.
It is preferable to make status change proposals for different buoys on distinct messages.
However, in case the LIST option is used, proposals can be detailed in the body text of the
message: it is recommended to state the proposal for each buoy by starting with a line encoded
according to the standard format followed by the comments on a few lines included inside
brackets; then the next proposal can be listed etc.. General comments can be included in free
format after the last proposal.
Example for the body text in case more than one proposal are included (subject line could be
1ASK CHK LIST AP):
1ASK CHK 61412 AP
(this buoy has been transmitting erroneous data
in the last 2 week)
1ASK CHK 54814 AP
-21-
22/29
(this buoy shows strong departure of Air Pressure
from the first guess field)
...
Mr. W. Xyz., National Meteorological Service.
ppp :
Physical variable (sensor) to consider:
AP
:
Air Pressure (coded as 'AP ')
AT
:
Air Temperature (coded as 'AT ')
SST
:
Sea Surface Temperature
WD
:
Wind Direction (codes as 'WD ')
WS
:
Wind Speed (coded as 'WS ')
APT
:
Air Pressure Tendency
POS
:
Position of the buoy
TZ
:
Subsurface temperatures (coded as 'TZ '): The depths of the probes and proposed
actions should be placed in the body text, not in the subject line (not enough room)
ALL
:
All buoy sensors (e.g. remove all buoy data from GTS)
Blank :
(coded as 3 space characters, i.e. ' ') Informations are detailed in the body text.
o:
Operator to use for proposed recalibration (mandatory and used only when ttt='REC'):
+
:
Add the following value to the calibration function
:
Subtract the following value from the calibration function
*
:
Multiply the calibration function by the following value (e.g. rate for recalibrating
wind speed sensor)
value:
Value to use for proposed recalibration (mandatory and used only when ttt='REC'); the value is
coded on 5 characters and completed with space characters if necessary. It is provided using the
following physical units:
Air Pressure :
Hecto Pascal
Temperatures :
Celsius degrees
Wind speed :
m/s
Wind Direction :
Degrees
Air Pressure Tendency :
Hecto Pascal
Positions :
Degree + Hundredth
Rate :
No unit
Examples:
From
Date
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Subject
10-Oct-1994
11-Oct-1994
11-Oct-1994
11-Oct-1994
12-Oct-1994
1ASK
1ASK
2ASK
1ASK
1ASK
REC
RMV
REC
CHK
REC
17804
62501
17804
44532
44704
AP +2.2
ALL
AP +2.4
POS
WS *1.5
Message1:
NZMS proposes to recalibrate Air Pressure sensor of buoy 17804 by adding 2.2 hPa.
Message2:
UKMO proposes to remove buoy 62501 from GTS distribution. Explanations are given
in the body text.
Message3:
Météo France comments (2ASK) on NZMS proposal for recalibrating air pressure
sensor of buoy 17804. Météo France suggests to add +2.4 hPa instead of +2.2 hPa.
Argumentation is provided in the body text.
Message4:
NDBC suggests to check positions of buoy 44532. Details are given in the body text,
including copy of one suspicious GTS message, the GTS bulletin header, and a
description of the error.
Message5:
BOM proposes to recalibrate Wind speed sensor of buoy 44704, by multiplying data by
1.5.
-22-
23/29
2.
Argos or LUT answer for changes actually implemented
When a change is implemented on GTS platforms, a message is normally forwarded to the
INTERNET Distribution List, by Argos or the considered LUT, no later than 24 hours after the change
was implemented. All the information is encoded in the subject line, the body text is empty. The format of
the subject line is as follow:
Format:
123456789012345678901234567890123456
cccc ttt wmo## ppp ovalue yymmddhhmm
Meaning:
Argos (i.e. the French Global Processing Center of Toulouse (FRGPC) or the US Global Processing
Center of Landover (USGPC)) or Local User Terminals (LUT) inform the INTERNET Distribution List
each time a change is actually implemented on a buoy status.
cccc :
Originating Center:
LFPW
= FRGPC, Toulouse
KARS
= USGPC, Landover
ENMI
= Oslo LUT
BGSF
= Sondre Stromfjord LUT
CWEG = Edmonton LUT
ttt, wmo##, ppp, ovalue: Same as for paragraph 1. In addition, for recalibrations, when the transfer
function has been completely modified, ovalue can be coded as a question mark followed by 5 space
characters,
i.e. '? ' , to indicate that the change is not as simple as a +X, -X or *X transformation.
yymmddhhmm: UTC time the change was implemented: Format=Year (2 digits), Month (2 digits), Day of
the month (2 digits), Hour (2 digits), and Minutes (2 digits).
Example:
From
[email protected]
[email protected]
Date
14-Oct-1994
14-Oct-1994
Subject
KARS REC 17804 AP
KARS REC 33809 AP
+2.3 9410141216
?
9410141306
Message6: Buoy 17804 Air Pressure sensor was recalibrated by adding +2.3 hPa. the change was
implemented at 12h16 UTC the 14 October 1994. As you may notice, two proposal had been
made for this buoy: NZMS proposed +2.2 hPa and Météo France proposed 2.4 hPa. The
Technical Co-ordinator of the DBCP contacted both agencies and it was then decided to apply a
2.3 hPa correction.
Message7: Buoy 33809 Air Pressure sensor was recalibrated. The change was implemented at 13h06UTC
the 14 October 1994. The question mark '?
' indicates that the transfer function was
completely modified.
-23-
24/29
3.
PGC Answer if the proposal was denied
Format:
12345678901234567890123456
DENI ttt wmo## ppp ovalue
Meaning:
The proposal was denied by the Principal GTS Co-ordinator (PGC) of the drifting buoy programme. No
action was taken. Complementary information can be included in the body text.
ttt, wmo##, ppp, ovalue: same meaning as in paragraph 1. ovalue is mandatory and used only when
ttt='REC'.
Example :
From
[email protected]
Date
15-Oct-1994
Subject
DENI RMV 62501 ALL
Message8: In the body text: Data were sent on GTS before deployment by mistake. The buoy is now
deployed and data look good. There is therefore no need for removing data from GTS
distribution.
-24-
25/29
4.
Monitoring Statistics
4.1. Subject line Format:
12345678901234567890123456789
STAT center ppp year mm dd
Meaning:
The monitoring statistics are available in the body text (format is standardised and detailed in paragraph
4.2).
center:
Name of the center producing the statistics, e.g.
ECMWF
= European Center for Medium Range Weather Forecasts
NCO
= NOAA NCEP Central Operations
CMM
= Météo France, Centre de Météorologie Marine
UKMO
= United Kingdom Meteorological Office
ppp:
Type of physical variable concerned or ALL if many variables are included. Same as for
paragraph 1 (i.e. AP, AT, WD, WS, SST ...)
year:
Year concerned (e.g. 1994)
mm:
Month concerned (e.g. 08 for August)
dd:
Last day of the 1-month period concerned. It is optional and used only if the 1-month
period does not end on the last day of the month. For example dd=15 if the 1-month
period concerned is 16 July to 15 August.
Example :
From
[email protected]
Date
02-Oct-1994
Subject
STAT CMM ALL 1994 09
Message9: The September 1994 monitoring statistics for many geo-physical variable and produced by the
Centre de Météorologie Marine of Météo France are available in the body text.
4.2. DBCP standard format for exchanging buoy monitoring statistics.
Example of ECMWF statistics produced in the standard format for the
month of May 1995:
ALL STATISTICS ARE FOR DATA WITH GROSS ERRORS EXCLUDED
GROSS ERROR LIMITS RELATED TO ECMWF FIRST GUESS FIELDS
Pressure
: 15 hPa
Temperature : 10 Celsius
Wind
: 25 m/s (RMS VECTOR)
Explanation of fields:
Date## :
WMO##:
Sns:
Last day for the monthly statistics
WMO number of buoy or Ship's Call Sign
Sensor Name :
AP (Pressure), AT (Air Temp), SST (Sea Surf Temp), WS (Wind Sp),
WD (Wind Dir), WV (Wind vector), APT (Tendency), HUM (Humidity),
TD (Dew Point).
Orig: GTS Origin of the data (ALL or cccc from GTS Bulletin header)
C:
GTS code (B: BUOY, S:SHIP, Y:SYNOP)
Cntr#:
Monitoring Center producing the stats (e.g. ECMWF, UKMO, OPC, CMM)
Lat##:
Last Latitude of buoy/ship during the month
-25-
26/29
Long##:
Last Longitude of buoy/ship during the month
Rcei: Total number of obs received at the center including obs not used
Acpt: Total number of obs accepted by the model
GE#: Number of Gross Errors (i.e. number of (Obs-Field) exceeding limits)
Bias#:
Mean Bias (Obs-Field)
SD##: Standard Deviation, SD = RMS (Obs-Field-Bias);
For Wind Vectors (WV), by convention, SD = RMS(WS/Rate - Field)
RMS#: Root Mean Square, RMS = RMS (Obs-Field);
For Wind Vectors (WV), by convention,
RMS=RMS(SQRT(Vec(WV-Field)**2))
Rate: Mean (Obs/Field)
F:
Flag for Field used : A=Analysis, G=First Guess, B=Both.
Date##, WMO##,Sns,Orig,C,Cntr#,Lat##,Long##,Rcei,Acpt,GE#,Bias#,SD##,RMS#,Rate,F
950531,15153, WD,
950531,15153, WV,
950531,21002, AP,
950531,21002, AT,
950531,21002, WS,
950531,21002, WD,
950531,21002, WV,
. . . . .
ALL,S,ECMWF,
ALL,S,ECMWF,
ALL,S,ECMWF,
ALL,S,ECMWF,
ALL,S,ECMWF,
ALL,S,ECMWF,
ALL,S,ECMWF,
34.9,
34.9,
37.9,
37.9,
37.9,
37.9,
37.9,
-62.3,
-62.3,
134.5,
134.5,
134.5,
134.5,
134.5,
1,
1,
145,
245,
245,
199,
245,
-26-
1,
,
123,
123,
124,
124,
,
0, 42.5, 0.0,42.5,
0,
,
, 8.6,
0, 0.2, 0.9, 0.9,
0, 0.3, 0.9, 1.0,
0, 0.1, 2.3, 2.3,
0,-10.7,31.1,32.9,
0,
,
, 4.0,
,G
,G
,G
,G
,G
,G
,G
27/29
5.
WMO/Argos cross reference list
Format:
12345678901234
WMOS year mm
Meaning:
The WMO/Argos cross reference list sorted by WMO numbers is available in the body text.
year:
Year concerned (e.g. 1994)
mm:
Month concerned (e.g. 08 for August)
Example :
From
[email protected]
Date
02-Oct-1994
Subject
WMOS 1994 09
Message10: The September 1994 WMO/Argos cross reference list is available in the body text.
6.
Principal GTS Co-ordinators (PGC) list
Format:
12345678901234
PGCS year mm
Meaning:
The list of Principal GTS Co-ordinators (PGC) sorted by Argos program number is available in the body
text. The Principal GTS Co-ordinators are designated by the owners of the buoys for being responsible to
request Service Argos and/or LUT operators to implement required status changes.
year:
Year concerned (e.g. 1994)
mm:
Month concerned (e.g. 08 for August)
Example :
From
[email protected]
Date
02-Oct-1994
Subject
PGCS 1994 09
Message11: The September 1994 list of Principal GTS Co-ordinators is available in the body text.
-27-
28/29
7.
Information message
Format:
12345678901234567890123456789
INFO subject...
Meaning:
An information message in free format is included in the body text.
subject...:
Subject of the message (free format)
Example :
From
[email protected]
Date
02-Oct-1994
Subject
INFO: New on DBCP W3 server
Message12: This message is to indicate that new products or information are available from the DBCP
World Wide Web (W3) server. Details are given in the body text.
-28-
29/29
Annex B:
DBCP QC Guidelines distribution list (mailing list)
Once registered on the mailing list, you will automatically receive any message posted by anybody onto
the mailing list. For posting messages onto the mailing list, just send an Email to the following address:
[email protected]
To be included in the [email protected] Internet mailing list you can automatically assign to it by
sending a message to the following Internet address : [email protected]
The messages in the body of your mail must comply with the syntax detailed below. You must send your
commands in the body of a mail message. Subject lines in mail messages are ignored.
The following commands can be handled automatically through the -Request interface:
SUBSCRIBE
SIGNOFF
REVIEW
QUERY
SET NOMAIL
SET MAIL
SET CONCEAL
SET NOCONCEAL
SET NOREPRO
SET REPRO
LIST
HELP
- to subscribe to a mailing list
- to remove yourself from a mailing list
- to get a list of subscribers
- to get the status of your entry on the list
- to remain on the list but not receive mail
- to reverse the NOMAIL setting
- to conceal yourself from REVIEW listings
- to reverse the CONCEAL setting
- to prevent the list from sending you your own postings
- to reverse the NOREPRO setting
- to get a list of mailing lists available on this host
- to receive a help file
The syntax of these commands is:
Syntax
Example
SUBSCRIBE {list-name}
SIGNOFF {list-name}
REVIEW {list-name}
QUERY {list-name}
SET {list-name} [NO]MAIL
SET {list-name} [NO]CONCEAL
SET {list-name} [NO]REPRO
LIST
HELP
SUBSCRIBE BUOY-QC
SIGNOFF BUOY-QC
REVIEW BUOY-QC
QUERY BUOY-QC
SET BUOY-QC NOMAIL
SET BUOY-QC CONCEAL
SET BUOY-QC NOREPRO
LIST
HELP
-29-