2022-06-13 ET-W2AT Meeting

1

Hassan

Hassan presented the GTS2WIS2 summary on previous discussions.

Open

• GTS2WIS2

• Thoughts on bulletins production

• WIS2 to GTS gateway

2 Discussion

All

Remy> the principles agreed on the previous meetings are:

1. WIS2 side is a center who is implemented the WIS2 node should note provide data to GTS

2. GTS only side shouldn’t change any thing on the GTS configuration before the migration

3. The bulletin production is complicated and should be operated by RTH

Enrico> To force Centers to run this bulletin production is complicated and difficult to decide today. What can we imagine is that to provide a software for RTHs to get data from WIS2 and then they will push to GTS

Remy>Agree, when we see the list of RTHs, some of them we are not sure that they are capable to do that

Enrico> They need only to download data from the Global Cache and ingest it in GTS. We can provide a software for that

Remy> we can have the following options:

1. NCs providing the GTS data

2. RTH providing the packing

3. No packing

Jeremy>What is the packing looks like?

Remy> Packing is taking data from WIS and presented them in GTS formats

Peter> the grouping of the individual obs is the most complicated thing expected of GTS switches... most of the data types are produced elsewhere and just pass through.

Peter>We could avoid the light blue(bulletin production) box if... wis2node included a "generate GTS core  products" module ... so the GTS gateway would subscribe to that... and once the GTS is retired, these modules could be turned off

Remy> Exactly.. that is an option

Peter> Doing it centrally is more complicated than doing it each node.... would have to build the per node software as a pre-requisite to the central one

Jeremy> Need to consider a configuration for the WIS migration

Enrico> that what we expect from NC to control the migration

Peter> the number of messages is limited to two or three types of things to be collected

Enrico> there is a complexity for the aviation data TAF and Metars not be exchanged by the Global Cache

Remy> Do we agree that RTHs can do something if we need packing service. In this case WIS2 can provide a tool for that using a GTS topic

Jeremy> Agree, but what topic structure should we use for that?

Peter> we can use TTAAii in the topic hierarchy

Kai> We need to consider the two directions: GTS to WIS and WIS to GTS. But in the last side the WIS2 nodes don’t know any thing about the TTAAii. If we send data to WIS2 we need to translate with TTAAii. the difficulty is how to do the mapping from WIS2 to GTS

Peter> you need a mapping table ....from sites to what AHL (including ii) 

Enrico> We have 2 aspects:

1. data from GTS

2. data data from WIS repacked and send to the GTS

Peter> I tend to agree with Kai Wirt (Gast) (Guest) ... the GTStoWIS2 module is then the right idea for this...

Weiquing> the only way I see is that the Global Cache do that

Remy> I don’t think so. We can provide a software to receive data in the GTS way. It’s a way to encourage centers to switch to WIS2. By subscribing to the GTS topic they can access to GTS data

Kai> are you talking about a new channel?

Remy> during the transition we provide this new channel and we will not improve the GTS data. New data GBON…, will not be in the GTS

Jeremy> how can we determine which topic for which data without providing metadata

Remy>If we provide metadata GTS will never stop

Peter> are you expecting to stop GTS from day 1

Remy> No, but limit the use of GTS. and encourage centers to migrate to WIS2

Weiquing> Agree with Remy but in this case GTS data will not be visible for us

Jeremy> not visible means not discoverable through WIS2 catalogue

Action>> Next week will resume that