...
Jeremy TANDY (ET-W2IT Chair)
Rémy GIRAUD (SC-IMT Chair)
Hyumin EOM (KMA)
Masato FUJIMOTO (JMA)
Steve Olson Kari Sheets (NOAA)
José MauroSteve Olson (INMETNOAA)
Max Marno (Synoptic)
José Mauro(INMET)
Tom Kralidis (ECCC)
Kai Wirt-Thorsten (DWD)
Kari Sheets Elena Arenskotter (NOAADWD)
Saad Mohammed Almajnooni Elena Arenskotter (DWD)
Majed Mahjoub (NCM)
WMO Secretariat
Enrico Fucile
Hassan Haddouch
Xiaoxia Chen
David Inglis Berry
Anna Milan
Timo Proescholdt
...
Proposals for other types of centres
Sensor Centres and data availability/quality monitoring
Global Replay service
Global Cache “for friends” (i.e., for NMHS institutions only)
Metadata publisher / validator service
Domain/theme-specific portals
Proposals for future of RTHs (requested by Exec Council) - i.e., encouraging them to operate a WIS2 service once their RTH function expires? Option: run 2x workshops Sep-Dec 2025 angled at on-boarding RTHs to be WIS2 service operators.
Meeting Note
Proposals for other types of centres
Sensor Centres and data availability/quality monitoring
Global Replay service
Global Cache “for friends” (i.e., for NMHS institutions only)
Metadata publisher / validator service
Domain/theme-specific portals
How many instances that we need at regional/national?
Description of each type
How are we going to develop further?
(Rémy) Argo data ? How do they publish the argo data via WIS2? Q2: Any broker service can provide to entities which have already provide the data via their established websites, working as an interface role? Global MQTT server as a service. (David) for ocean, climate, cryosphere community, considering it is a barrier for them to publish notification, a shared broker service will be beneficial for them. (Maaike) a shared regional broker service may be contradicting to our WIS2 architecture, local broker + Global broker.
(Rémy) To offer an option for those data providers who have already published their data to website without the need to publish via a WIS2 node. Shared MQTT broker service as a 6th type of service. Discussion on the additional global services - a shared broker for those entities who have already published data to website.
Jeremy introduced the agenda and then presented the first topic, focusing on other types of centers. He introduced the five proposals outlined in the agenda and emphasized the importance of considering how many instances might be required—or whether it is even possible to determine the necessary number of such services.
Rémy reported on the example of ARGO data and asked how we can support them while lowering the barriers for their integration into WIS2. He suggested considering Broker that could be provided by a suitable entity.
In response to questions regarding the architecture of WIS2—such as whether it will be changed or if additional Global Services will be added—Rémy clarified that this is solely about providing an MQTT service to data providers that already have websites, making it easier for them to onboard into WIS2. He emphasized that the existing organization of WIS, including NCs and DCPCs, will remain unchanged.
This approach can be extended to various communities, including ocean, climate, and cryosphere.
(Kai) DWD’s current practice (Israel wis2node wis2 node running on DWD infrastructure) is based on the bilateral LoAagreement. If it is going this to be become an official service, we need to identify the procedure to be followed. Who is eligible to use such services? MQTT server with streamlined service. How many instances that might be needed. (No fixed number) Is global or regional responsibility? (it depends on service provider’s decision). When it might be needed? (by mid year? Currently, the service doesn’t existed.)
(Maaike) Can we have a shared broker for non-real time data to publish WCMP2 records?
(Jeremy) to identify a small list of RTHs to be willing to develop and provide these services. (Potential list could be from GISCs not providing any global services or from big RTHs) a formal procedure needs to established.
Key considerations for the MQTT service:
Eligibility: Who will be allowed to access and use the service?
Service Structure: Ensuring an efficient and streamlined MQTT server for users.
Number of Instances: No fixed number, but an estimate is needed based on demand.
Scope of Responsibility: Should it be a global or regional service? This depends on the service provider’s decision.
Timeline: When should it be available? Possibly by mid-year, though the service does not currently exist.
Global Replay service :
Description: Listening to Global Broker, and caching to Global Cache; this provides the service after the service is down for some time. API is Tom introduced the Global Relay as a service listening to the Global Broker, that collects, caches, and distributes messages, ensuring that users who were offline can retrieve any missed notifications once they reconnect. API are based on OGC APIs; implementation on GitHub repo: https://github.com/wmo-im/wis2-grep
Key considerations for the Global Replay:
Number of Instances
...
: At least 2
...
Scope of Responsibility: Global
(Question from Max: retention: how long?) (Rémy: by seconds) (Tom: retention is currently set as 24 hours. to subscribe to origin and cache.)
...
Retention: at lest 24 hours
Timeline: No specific milestone for implementation
Candidate operator: ECCC,
...
which already has an instance
...
running this service.
Sensor Centres
Description: Type of sensor centres
Decision: (Rémy) to create one or two pages on GitHub Repo to review and then for discussion. To compare two Gateways (GTS to WIS2 Gateways provided by DWD and JMA, very differently, Chems to decode BUFRs to compare two Gateways)Regarding the sensor centers, a discussion took place and it was concluded to create a GitHub page to present these proposals for review and completion.
Action: Rémy will describe the sensor center on the evaluation of the GTS2WIS2 gateway, on which Chems is working, as well as that one on the evaluation of global caches.
Action: Hassan to share the ET with team the right repo for discussion on sensor centres.
Action: all Everyone is encouraged to contribute to ideas for other types of sensor centres.centers
Metadata publisher / validator service
Description: Tom introduced the Metadata publisher as standalone web applications metadata editors. To , designed to edit, to validate, to and assess the quality assess of the metadata. to have some validation before passing This tool aimed ensuring the accuracy and completness of metadata prior to submission to GDC. (it is a software)
Key considerations:
Instances: at least
...
one
Global or regional responsibility: Global
When is it needed: as soon as people
...
start using WIS2 regularly
Candidate operator: Option 1: a metadata editor available in wis2box. Option 2: metadata editor provided by SYNOPTIC
Action: Tom to provide an analysis on both options and report back
Domain/theme-specific portals
Description: A portal
(Timo) WIPPS portal: two-phase project, phase 1 is to design the portal interface; phase 2 is to be linked to the metadata discovery catalogue. Current WIPPS portal.
(Kai) WIS2 catalogue should be good enough for users to build their portal. We should not focus on building The purpose is to develop a Shiny portal that enhances the visibility and accessibility of WIS2. This platform will serve as a central hub for users to easily access WIS2-related information, data, and services. It will also play a key role in marketing WIS2, promoting its capabilities and engaging stakeholders, ultimately increasing its adoption and usage across the community.
The WIPPS portal Current WIPPS portal has been discussed as example, however, the team agreed to focus more on a WIS portal. The WIS2 catalogue is more enough for domains to build their portals.
Proposals for future of RTHs (requested by Exec Council) - i.e., encouraging them to operate a WIS2 service once their RTH function expires? Option: run 2x workshops Sep-Dec 2025 angled at on-boarding RTHs to be WIS2 service operators.
"Requests from the Executive Council for INFCOM to consider the elaboration of a comprehensive guidance for the cease of functions of RTH;" Quote from EC-78
Action: to create one a dedicated page for the RTH functions (To firstly develop the prototype and then demonstrate to RTHs in Q4 to host)and eventual roles in WIS2. The first step will be to develop a prototype, which will then be demonstrated to the RTHs in Q4 2025 workshop for hosting and further feedback.
Next meeting
24 February