Home - wmo-im/WSI GitHub Wiki

WIGOS Stations Identifiers operational implementation

The purpose of this wiki is to clarify the requirements for the implementation of WIGOS Stations Identifiers in the data exchange and to discuss suitable solutions for the implementation and monitoring of WSIs. The operational implementation of WSI is a complex operation affecting a significant number of systems and activities across WIS, WIGOS, GDPFS, and Members' operations.

List of issues

The following issues are considered in the context of the implementation activities in the following chapters. They are listed here for convenience.

1. General requirements

According to the Manual on WIGOS WMO observing stations and platforms shall be uniquely identified by a WIGOS station identifier. This includes also WWW/GOS data that since July 2016 are uniquely identified by WSI and not anymore by the WMO block/station number. At the same time all the content of Vol. A as of 1st July 2016 was loaded in OSCAR/surface and WSI was assigned to all the stations by the Secretariat according to the guidance provided in the Guide on WIGOS.

WIGOS operational implementation requirement

To provide users the ability to publish metadata of a WIGOS station on OSCAR/surface and to exchange data on WIS. The data of a station exchanged on WIS shall be linked with the record of the same station on OSCAR/surface to enable the required monitoring capabilities currently implemented in wdqms.wmo.int.

2. Activities

The following activities need to be completed for the WSI implementation with a focus on resolving the issues across the systems that each activity is impacting.

2.1. Procedure to assign WSI to new stations

There is a large degree of freedom for the Members to decide the schema of WSI. Therefore clear procedures are needed for the Members to be able to assign WSI to new stations. In this respect, each Member shall develop a WSI national schema complying with the Manual on WIGOS and following the guidance in the Guide on WIGOS.

Issues

2.2. Encoding BUFR/CREX messages with WSI

Encoding of BUFR/CREX messages have to follow the guidance provided in the circular letter Reporting of WIGOS Station identifier in BUFR/CREX messages

  • Where to place WSI

When Members report data using BUFR/CREX templates defined in B/C Regulations (Section d, Part C, Volume I.2 of the Manual on Codes) or other BUFR/CREX sequences suitable for reporting specific data sets and include the WSI, the sequence for reporting WSI (3 01 150) should be placed before the BUFR/CREX templates or other BUFR/CREX sequences in BUFR/CREX messages.

  • How to encode WSI

When Members report data from observation sites that have traditional station identifiers, such as WMO block number (0 01 001)/WMO station number (0 01 002) and buoy platform identifier (0 01 005), they should also be reported in addition to corresponding WSI (3 01 150), to ensure the continuity of data use. On the other hand, the traditional station identifiers should be reported as "missing" when observation sites do not have the traditional identifiers.

  • Versions applicable

BUFR/CREX messages that include the sequence for reporting WSI (3 01 150) should have master table version number 28 or later, because the sequence 3 01 150 is not defined in the tables with version numbers before 28.

  • Advanced notification

Members should issue advanced notification at least three months before they start distributing new reports that include both traditional station identifier and WSI (3 01 150), clearly stating the date of change, WSI, corresponding traditional station identifiers (when available), and new and existing bulletin headings. All Members will be notified of these changes through METNO messages defined by the Manual on GTS and as an entry of Operational Newsletter.

  • Distribution not parallel

Parallel distribution of BUFR/CREX messages with and without WSI (3 01 150), which consists of same contents, is discouraged, as the messages coded in conformity to the practice in (2) above, satisfies user requirements and duplicated reporting of same contents could cause confusion for users.

Issues

2.3. Adaptation of GTS message switching software

GTS message switching software operated by NCs, RTHs and GISCs has to be able to operate with a mixture of messages having and not having the WSI. Guidance on how to compose bulletins from mixed WSI and non-WSI messages has to be provided. The GTS message switching software in all the WIS Centres has to be adapted in compliance with the guidance that will be provided.

Issues

2.4. Adaptation of users’ and NWP software and systems

The ecosystem of users’ software designed to work with the Traditional Station Identifier (TSI) requires significant adaptations to be able to make use of the WSI schema. The transition from TSI to WSI is made gradual by the requirement to have the WSI in addition to the TSI in the BUFR messages. The presence of both TSI and WSI in the data allows legacy systems to work using the TSI without any need for changes. Similar considerations apply to NWP software and systems. The following milestones are proposed to complete the transition. Implementation of “Exchange WSI BUFR on GTS” (C. below) is conditional (to a large extent) to the implementation of “Software to process WSI” (D. below) due to the risk of losing data, that currently being shared internationally if the majority of NWP Centres are not ready to use BUFR with WSI.

Issues