Topic hierarchy and filename

Principles

1. Mapping between discovery metadata and topic hierarchy shall allow subscription to the data described in the metadata item.

2. Topic hierarchy built from GTS is going to be temporary and used only to make GTS data available on WIS2

3. WIS2 hierarchy will be built gradually following the requirements of WMO domains.

WIS2 topic hierarchy and filename

scope/ data policy / data type

wis2/[core | recommended | other]/[ obs | nwp ]

1. Starts with WIS2 to mark the scope and syntax.

2. data policy will be high in the hierarchy because it imposes a distinction in access permissions

3. At the moment we have observations and nwp data, but we will add climate statistics and possibly other data types.

The hierarchy under this level is significantly different for obs and nwp.

obs/country/station-type/observation-type/

1. For observations, the topic hierarchy and the associated metadata shall be consistent with OSCAR metadata.

2. Country where the observing station is located. This is sometimes a problem with the sea stations.

3. station-type is about the location of the station (land, air, sea) and whether it is fixed or mobile: OSCAR surface

4. observation-type is about the type of observation (e.g. surface, upper-air)

Filename: WSI_[WSI value]_[timestamp].[data format]

1. WSI as shown in OSCAR surface

2. timestamp in the following format

3. data format: grib, bufr, tac, nc, json, geojson, xml

GTS topic hierarchy and filename

This is the current output of the TT-Protocols team

https://github.com/wmo-im/GTStoWIS2

Question to be answered.

Given that GTS will be dismissed does it make sense to develop a topic hierarchy based on GTS headers?

Shall we make a topic structure directly with GTS headers (T/T/A/A/ii/CCCC )?