Skip to end of metadata
Go to start of metadata
All meeting notes
Actions tasks from meetings
Decisions from meetings
|
2021-12-17 ET-W2AT Meeting
|
- To meet at the end of January
|
|
2022-02-02 ET-W2AT Meeting
|
- Data will always be made available via a MQ message that points to where the data is for download; with an optimisation to embed small data in the message [approved]
- Adopts the MQTT 3.1 and MQTT 5 in WIS2.0
- Shared services approach approved by the team (Global Cache, Global Broker and Global Discovery Catalogue)
- No requirement for NC/DCPC to connect to ALL instances of a shared-service
- NC/DCPC MUST connect to at least one instance of a shared service, and SHOULD connect to two or more instances of a shared-service
- NC/DCPC connects directly to the shared-service instance(s) - not via their GISC
- No requirement for all-to-all fully meshed connection
- There must be more than one instance of each shared service
- Global Monitoring approved as shared service
- There needs to be automated service monitoring of the WIS2 system from day 1
|
|
2022-02-07 ET-W2AT Meeting
|
- Global Brokers should connect to other brokers
|
|
2022-02-14 ET-W2AT Meeting
|
- Global Cache will hold "file" Data Objects - same as how "file" Data Objects are shared on the GTS
- Data Consumers who want to browse and download data should use the originating center (i.e. NC/DCPC) - Global Cache may be accessed directly, but its primary purpose is to host files that are identified in real-time "data availability" messages. Global Cache does not need to provide a mechanism for Data Consumers to browse the cached content (e.g. file-level STAC metadata). Effectively, this means the cached copy would not be identified in the discovery metadata as a Distribution of the dataset. The discovery metadata record would include "association" links that refer to the originating center for download, and to originating center and Global Brokers for where a Data Consumer can subscribe to updates.
- The Global Catalogue will update discovery metadata records to add "association" links for subscription URLs at Global Broker instances
- The Global Catalogue advertises the availability of datasets and how/where to access them or subscribe to updates, it does not advertise availability of individual Data Objects that comprise a dataset
- Data Consumers should subscribe to Global Brokers to receive "data availability" messages; exceptionally, a Data Consumer may decide to subscribe directly to the local message broker at the originating NC/DCPC; Data Consumers should not subscribe to the local message broker at Global Cache instances.
- Global Cache instances and NC/DCPC use consistent topic structure in their local message brokers
- Global Brokers should use distinct "channels" to keep messages from originating centers separate from messages originating from Global Cache instances]
- Data Consumers will need to implement logic to discard "duplicate" messages
- Only embed data in within a message in exceptional circumstances
|
|
2022-02-21 ET-W2AT Meeting
|
- A global monitoring dashboard for a real-time view
- Where metrics are available at NC/DCPC, these _should_ be made available in the standard form, but a provision of metrics is not mandatory. Technical Regulations will include requirements for Sensor centers. Both data and service availability types; at a minimum in terms of how they expose metrics to the Global Monitoring dashboard(s) [the definition of the metrics themselves may be part of other WMO manuals?
- WIS2 provides the "plumbing" for data but doesn't define which data need to be shared. WIS2 provides the "plumbing" for capturing [performance] metrics, but we don't define which metrics are needed - this is the responsibility for the other programs/activity
|
|
2022-02-28 ET-W2AT Meeting
|
- WCMP2 based on OGC-API Records
- WIS2 [Global] Catalogue implements OGC-API Records API
- Set up Task Team for NWP metadata (Tom, Peter involved), Enrico to take the lead with Yuki
- Agree a structured method and framework for activity areas to develop their own domain-specific standards for vocabulary and topic structure
- Next weekly meeting to discuss message structure
|
|
2022-03-14 ET-W2AT Meeting
|
- we delegate to communities of interest for them to develop their subtree? And provide a first attempt or some general guidance
- we need to provide a framework to constrain how they develop their subtree
- need to make sure that the Channel isn't part of the classification hierarchy
|
|
2022-04-11 ET-W2AT Meeting
|
- Next meeting: 13:30 - 15:30 UTC
|
|
2022-05-09 ET-W2AT Meeting
|
- the message structure and topic structure are agreed and approved
|
|
2022-06-08 ET-W2AT Meeting
|
- Should be Web based to be aligned with the principles and also should be a self describing and use the openAPI version 3.1 to discover and understand without any need for additional documentation
- Use interactive link providing a direct access to the data which not required no further interaction
- WIS2 guidance, to be simple to develop simple and flexible description, not be dramatically change in the future, for the API
|
|
2023-04-17 ET-W2AT Meeting
|
- Australia will contribute to Global Broker
|
|
2023-06-26 ET-W2AT Meeting
|
- DWD agrees to run the GTS to WIS2 Gateway during transition
|
|
2023-09-18 ET-W2AT Meeting
|
- Notification mechanism on updated data: two solutions (with operation property vs no operation property but with a relation link) to be decided
|
|
2023-10-16 ET-W2AT Meeting
|
- Agrees to remove WIS2 guide session 4- data and metadata flows and publish in a separate document with the simple data sharing removed
- Agrees that Global Cache treats metadata and data at the same level.
- Agrees that each component in WIS2 architecture has a local broker. (GDC needs a local broker too.)
|
|
2023-10-30 ET-W2AT Meeting
|
- To determine a communication mechanism with all the wis2node operators about the change of Topic Hierarchy (merge country and centre-id)
- Agrees the proposed transition plan, ensuring each Global Cache only needs to support one system during the transition period. (Cache A is ready for transition as soon as possible; Cache B or C stays the same as the current system until the last wis2node migrates)
|
0 Comments