Principles
Mapping between discovery metadata and topic hierarchy shall allow subscription to the data described in the metadata item.
Topic hierarchy built from GTS is going to be temporary and used only to make GTS data available on WIS2
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 ]
Starts with WIS2 to mark the scope and syntax.
data policy will be high in the hierarchy because it imposes a distinction in access permissions
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/
For observations, the topic hierarchy and the associated metadata shall be consistent with OSCAR metadata.
Country where the observing station is located. This is sometimes a problem with the sea stations.
station-type is about the location of the station (land, air, sea) and whether it is fixed or mobile: OSCAR surface
observation-type is about the type of observation (e.g. surface, upper-air)
Filename: WSI_[WSI value]_[timestamp].[data format]
WSI as shown in OSCAR surface
timestamp in the following format
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 )?
Add Comment