Page Comparison

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:

• message distribution

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

• Register a new NC or DCPC

• Register a new dataset

Remy> What we discussed in Geneva:

• how to manage the transition

• how to ensure GTS users will continue receiving data

• need 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, 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