2022-04-11 ET-W2AT Meeting
Date
Apr 11, 2022 13:30-15:30UTC
Participants
@Rémy Giraud
@Peter Silva (Unlicensed)
@Baudouin Raoult (Unlicensed)
@thorsten.buesselberg (Unlicensed)
@Kenji Tsunoda (Unlicensed)
@Tom Kralidis (Unlicensed)
@Henning Weber (Unlicensed)
Other Experts
@Kari Sheets (Unlicensed)
WMO Secretariat
@Enrico Fucile
@HADDOUCH Hassan
@Xiaoxia Chen
@Timo Proescholdt
@David Berry
@Anna Milan
Apologies
@Jeremy Tandy (Unlicensed)
@Kai Wirt (Unlicensed)
@Pablo Loyber (Unlicensed)
@Wang Peng (Unlicensed)
@sabai.fatima (Unlicensed)
@Dana Ostrenga (Unlicensed)
Goals
Discussion topics
Item | Presenter | Notes |
---|---|---|
1. message structure | All | Remy summaries the discussion from the last week presented the slide related the message structure Peter > id is chosen because it is almost required in geojson. So then the id will need to contain the topic hierarchy, and some sort of record to identify this product or record within the topic. in my mind this is exactly the function of relPath in v03 format. so it would amount to renaming v03 'relPath' fo v04 'id' Remy> I would like to know the team views on that Thorsten> I’m not an expert by referring to my discussion with Kai, He agrees for the Geojson , but no use of keys Peter> I think Geojson is not the good solution, not yet tested and we have already the solution which have been tested and work well Remy> What is important is to cheek if what we are proposing is working. The fact that we have a solution working that doesn’t mean that we don’t try other solution to be aligned with WIS2 Peter>Kai says that keys is a bad idea Remy> It’s not exactly that Baudouin> Real time is different from other data. WIS2 is for all programmes and need to consider all data not only real time data. Peter> I don’t say that we need to use STAC. We can see the gaps and see how to deal with. wis2box with new format, message from the request, gaps in implementation, and see how the gaps be filled and suggestions to be proposed. Remy> In Geneva, We discussed the opportunity of the preoperational phase: It’s to test these kind of things and align it if needed. Tom> I prefer the Geojson, for the interoperability and also for its use by a large community Dave> The version 4 of Geojson make sense |
2. Message distribution | All | Remy> presented the update slides on WIS2 message and (meta)data flows:
Peter> all protocols implementation per connection is semantic identical to “msg_id”. the antilop can be based on the relpath to deal with duplication Baudouin> to use only the relpath in some cases it’s a risk. we can’t compare two machines time. How can we avoid duplication from two GBs or two GCs? Baudouin> do you use the checksum to verify the integrity or to to cheek the version Peter> you can use it for both Remy> We need to consider a solution clear aligned with WIS2 and to cover all data from all WMO programmes |
3. data access and download | All | Boudouin > Hash is used to verify the integrity 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 is the best way to deal with 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 and the provider 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 |
Remy> What we discussed in Geneva:
Thorsten> mid May is good, 23rd is better 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) Kenji> GISCs can collect comments from NCs/DCPCs in their area of responsibility Remy> no need to have comments from NCs or DCPCs, what we need is comments from GTS experts and we will come back to this in 23rd may |
Action items
Decisions
- Next meeting: 13:30 - 15:30 UTC