technical requirements from WIS2.0 point-of-view

[sbasart-wmo]

Hello Jörg,

This week I had a meeting with some WMO colleagues to try to understand how is organised the WIS2.0 system and provide some feedback on the proposal.

Important technical considerations to be aware of the WIS2.0 for the hierarchy design are the following:

• Only considers NRT information. This means that operational systems submit files to WIS2.0 every day.
• WIS2.0 hierarchy does not refer to the data itself, it's the notification system to track the submission of the data files for operational users, i.e. their availability. For this reason, for example, you can find weather > aviation, this category includes all synop and metar.
• Only it is possible to associate one notification with a file/system. This is, for me, the most important point because it has direct implications in the hierarchy design and is on top of the "user" requirement.
• No more than 4 levels in the hierarchy.
• Although it is not mandatory, it is suggested trying to be aligned with the structure of the rest of the disciplines in GitHub.

Considering these points, I would suggest the following structure:

1. atmospheric-composition 1.1. surface-based-observations We need to take into consideration the operational workflow that follows the structure of the GAW Word Data Centers. I mean how the files are submitted in the Data Centers, because this is what I understand will be associated with the notification. Also before defining the categories here, we would need to identify what datasets are potentially available in NRT. 1.2 space-based-products (at the moment, there is no example for weather-space, but I would say that here we should consider the different satellite-retrieved products, that are associated with different datasets. For example, aod > modis-retrieval, or no2 > omi-retrival. But this is something that we need to double-check with the WMO satellite group. 1.3. analysis-predictions 1.3.1. analysis: Datasets of analysed atmospheric conditions for a specified time or period in the past 1.3.2 forecast: Datasets of expected atmospheric conditions for a specified time or period in the future, typically including the T+0 fields 1.3.3 reanalysis: Datasets of retrospective run for a specified time or period in the past 1.3.4 hindcast: Datasets constructing a record of past conditions 1.4 advisories-warnings 1.4.1 sand-and-dust 1.4.2 air-pollution (@all, here is it also considered tropospheric ozone) 1.4.3 fires 1.4.4 nuclear-fallout (@Anna, we need to check if there is already the notification in weather/aviation) 1.4.5 volcanic-eruptions (@Anna, we need to check if there is already the notification in weather/aviation) 1.4.6 ultraviolet-radiation (@all, the alert is connected with the UV levels, not the ozone, and we need to check if there is already a notification in weather)

[sbasart-wmo]

this issue is added to the existing discussion #20