Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

\uD83D\uDC65 Participants

Other Experts

WMO Secretariat

Apologies

Other Experts

WMO Secretariat

Apologies

 Goals

\uD83D\uDDE3 Discussion topics

...

Item

...

Presenter

...

Notes

✅ Action items

  •  

...

 Goals

\uD83D\uDDE3 Discussion topics

Item

Presenter

Notes

1. message structure

All

  • Peter: wis2box with new format, message from the request, gaps in implementation, and see how the gaps be filled and suggestions to be proposed.

  • Baudouin: catelogorization is missing

  • Tom: put GeoJSON in my case

2. Message distribution

All

  • Remy presented the update on message distribution and data access and download.

  • Peter: all protocols implementation per connection is semantic identical to “msg_id”

3. data access and download

All

  • Boudouin: hash not checked, verify correct or not,

  • Remy: data_id (msg_id to identify the message), do we use hash to check the integrity (checksum)?

    • Peter: same id-->same hash

    • Boudouin: so currently, we don’t use hash to do the checksum

  • Tom: data_id, header, apply to the response, to serve as cache validation, ear Tag

  • Remy: how to identify the duplicated messages

  • Boudouin: we have problems of deduplication and loops which are different problems. Using unique ID

  • Peter: message id is generated by Global cache

  • Remy: Do we want some tailored to WIS2? Our goal is to design a solution that people can implement in different ways.

  • Tom: any objection to testing the proposal? To add an identifier element to the properties and then to test it

  • Remy: we need the guide on WIS/WIS2 to be approved by Cg2023. Our goal to deduplicate the data download.

  • Thorsten: I agree to test the new proposal of data format.

  • Peter: how the user can tell whether the data can be downloaded or not

    • Remy: no access control to cache, data can be controlled by the metadata

    • Topic be included in ID?

    • Remy: both message ID and data ID are UUID

  • Remy: preoperational phase will start later this year. The main functions of GB/GC are clear.

  • Hassan: For the constraint of time, the details will be described into Guide. The next year will be the experimental year. So currently, we need to agree on the concepts and then try to test it.

  • David: I am a big fan of tidy data and keeping everything explicit with one piece of information per field rather than mixing up multiple pieces of information and then having to parse it to extract the data.

4 dataflow of a center

All

  • Register a new NC or NCPC

  • Register a new dataset

  • Remy: The next step is to contact GTS experts to see how the transition looks like. Transition proposal to be ready in Mid May. No general rules for GTS to switch off to WIS2.

    • Thorsten: mid May is good

    • Kenji: Workshop in January (8 countries joined), most of them concerned their GTS. If GTS messages stop, the forecasting and warning issues will be a concern. It is not only for GTS, but also for operational issues. (internal downstream central system)

  • Remy: Transition is important, which means we need to work on the design, to explain WIS2 and time frame and the centers willing to migrate from GTS to WIS2 need to modify their systems to comply with the new design. For the downstream or upstream system is out of the scope of the ET-W2AT.

  • Decision: May 23rd: for the first review of potential proposal for transition plan (to invite GTS experts to join the meeting)

  • Remy: to help NC transite is different from GTS/WIS2 transition, although it is also important work.

✅ Action items

  •  

⤴ Decisions

  • Next meeting: 13:30 - 15:30 UTC