-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting 2026 03 18
Wednesday 18 March 2026 15h - 16h UTC
MS Teams
| Name | Affiliation/Country | GitHub handle | Attendance |
|---|---|---|---|
| Tom KRALIDIS (Chair) | Canada/ECCC | @tomkralidis | X |
| Lance BRAASCH | Scripps | @lancebraasch | |
| Lucia CAPPELLETTI | MeteoSwiss | --- | --- |
| Gao CHEN | NASA | @gaochen-larc | X |
| Markus FIEBIG | NILU | @markusfiebig | X |
| Jörg KLAUSEN | MeteoSwiss | @joergklausen | X |
| Thomas LATTER | WMO / OceanOps | --- | X |
| Thinesh SORNALINGAM | Canada/ECCC | @thineshsornalingam | X |
| Fabrice THEBAULT | MFI | @fabricethebault | X |
| Alex VERMEULEN | ICOS | --- | |
| Anna MILAN | WMO Secretariat | @amilan17 | X |
| Dave BERRY | WMO Secretariat | @david-i-berry | X |
| Luis NUNES | WMO Secretariat | X | |
| Enrico Fucile | WMO Secretariat | X |
- Previous meeting minutes and actions (all)
- Secretariat updates (Anna)
- Updates from INFCOM Management Group (Tom)
- Review of Terms of Reference (Tom)
- Development
- latest model proposal (Jörg)
- core and extensions design using WCMP2 (example) (Tom)
- document/schema status (Tom)
- pywmdr status (Tom)
- issues from WMDR1: Issue #6 (all)
The meeting opened with a review of the previous actions.
- The working timeline is: remainder of March, April, and May to finalise the work. Meeting invitations (every two weeks, adjusted to accommodate Tom's schedule) will be updated as needed — participants asked to watch for updates in Teams.
- At the INFCOM Management Group meeting the previous week, the work on a simplified WIGOS metadata representation was acknowledged and noted without any change to previous decisions.
- Enrico Fucile confirmed that the focus for WMDR2 remains on the Minimum Viable Product (MVP). Funding for OSCAR/Surface Next Gen development is still under discussion, with no news to report yet.
- Tom confirmed that INFCOM President has endorsed the MVP approach for WMDR2 and that the OSCAR/Surface NextGen ad-hoc task team — which agreed on a Phase 1 architecture — will be reconvened to ensure alignment between the WMDR2 specifications and the software implementation.
- Hard deadline: The document must be ready for submission by 3 September 2026 (formal deadline for INFCOM session materials). The team's effective working deadline is before the summer holidays (July/August). The document will be submitted as an information paper for INFCOM session in November 2026, after which it requires endorsement by EC or Congress. Anna confirmed the approval pathway: task team → SC-IMT → INFCOM President / Management Group → INFCOM Session.
The deliverables for the task team are:
- A standards document describing WMDR2
- A JSON Schema implementing the rules, with examples
- A reference implementation (working software) serving as proof of concept
The approach follows the WCMP2 model — a minimal, extensible core — deliberately scoped to avoid trying to address every requirement at once given the tight timeline. An agile approach will be followed; element names and details may change through iterations.
Jörg shared his screen and walked through the updated UML diagram and associated documentation (posted to GitHub just before the meeting).
- Purpose: Enable adequate use of observations — not merely product discovery. This distinction was emphasised.
-
History concept: A key inherited concept from WMDR1. The
temporalprefix on an element signals that it carries an explicit time history (i.e., a series of timestamps or intervals associated with changing values). The one exception istemporalExtent, which is simply a begin/end interval without history. - Geometry: Used in the OGC Records API sense, equivalent to geolocation (coordinates + elevation).
The model comprises three primary classes:
1. Facility
A station or platform, with its properties. Facilities can be grouped into Facility Sets (flexible clusters, with no prescribed grouping rule). Key identifier is WSI (WIGOS Station Identifier); an additional WSI array accommodates multiple identifiers. Tom confirmed that OGC requires a single unambiguous ID per facility, which is the primary WSI. Jörg noted that the WSI field in the facility set header was tentatively included but may be removed following Luis's confirmation that the WSI concept was not designed for facility sets.
2. Observation
Describes what is being observed at a facility, including whether data are exchanged internationally and on what schedule (supporting applications such as WDQMS). Observations are composites of one or more Deployments.
3. Deployment
The instrument (or model, in the case of NWP data) used for the observation over a period. Multiple deployments may run in parallel; the model assumes only one carries "official" status at a time.
Additional model elements:
- Procedure — linked as a would-be extension; allows documentation of observing procedures to the level of detail required by different applications.
- Contact information — included as part of the model.
- Territory — retained despite political sensitivities, as listing stations by country is one of the most common use cases. Jörg noted that if territory were to be removed it would require a change to WMO No. 1192, and that the standard should look beyond a narrowly WMO-specific scope.
Observed variables are broken into four aspects:
- Observable property — the state or non-state variable (e.g., temperature, sea-ice thickness, CO₂ concentration, aerosol scattering coefficient)
- Observable property constraints — further qualification (e.g., "temperature at 2 m above ground"); Jörg noted a possible typo in the UML still using "observed variable constraints"
- Object of interest — the entity being observed (atmosphere, sea surface, etc.)
- Statistical measure / processing — how the measurement is derived
Jörg acknowledged that these are subtleties requiring further discussion and invited participants to test the model against their own datasets.
Terminology alignment with I-ADOPT
Markus Fiebig raised that the term "object of interest" is used in I-ADOPT but with a different meaning (roughly equivalent to "matrix" in that framework), and that "observable property" similarly overlaps. He urged avoiding identical terms with different definitions. Jörg acknowledged awareness of I-ADOPT, agreed in principle to avoid conflicting terminology where possible, but noted that "matrix" does not encompass concepts like the atmosphere, and that terminology choices in I-ADOPT are themselves a moving target. Gao Chen noted that I-ADOPT's variable definitions are well-grounded scientifically and suggested leveraging them, while also noting that the framework is heading in a very semantic direction. No resolution reached; Jörg suggested a smaller offline meeting or extended call to work toward consensus, given time pressure.
Mobile platforms
Gao confirmed that the temporalGeometry element attached to the facility is intended to support mobile platforms (aircraft, ships, cars). Jörg confirmed this.
Model data / NWP
Gao asked whether the instrument slot in the deployment entity could accommodate a numerical model (e.g., ECMWF). Jörg confirmed yes; a model version could substitute for a serial number in that context.
Instrument serial numbers vs. broader identifiers
Gao noted that many instruments (especially campaign/homemade instruments) have no serial number, but version or date may be relevant. He suggested using a broader term. Jörg agreed this needs to be tested.
WIS / WCMP2 linkage
Thinesh asked how WMDR2 connects to WIS2. Tom explained that the key principle is linkages between datasets and facilities (and facility sets). The upstream management node (Oscar/Surface) may have a richer internal model; what matters is that the information provided to the WIS2 catalogue matches this representation for high-level discovery and interoperability. JSON schema translation will clarify many of these linkages.
Facility ID vs. additional WSI
Discussed whether ID and additional WSI in the facility set could be collapsed. Tom confirmed that OGC requires a single unambiguous ID per entity; the rationale for a separate additional WSI array is to accommodate multiple identifiers where needed.
Instrument measuring multiple variables
Fabrice noted this was raised as a GitHub comment by Lucia Cappellitti. Jörg confirmed this has been addressed in the UML.
GitHub comment workflow
Anna raised that when the UML is updated in response to comments, a note should be added in the corresponding GitHub issue so reviewers can see what changed. Jörg and Tom agreed; acknowledged the latest version was posted immediately before the meeting with no time for annotations.
Tom asked whether anyone had strong objections to proceeding with the current model. No objections were raised.
Agreed next steps:
- Jörg and Tom to incorporate comments and update the UML/documentation accordingly
- Begin drafting the standards document and JSON schema
- Post responses in GitHub comments when the UML is updated in response to issues
- All participants asked to test the model against their own data and raise issues in GitHub before the next meeting
- Remaining comments to be submitted via GitHub for tracking
Next meeting: 24 April (meeting invitation sent by Anna)
- Gao Chen: No further comments.
- David Inglis Berry: No further comments.
- Enrico Fucile: Noted good progress.
- Fabrice Thébault: No further comments.
- Jörg Klausen: Reiterated the goal of simplifying WMDR1 without introducing major mistakes; encouraged participants to do the mental exercise of applying the model to their own datasets to check for catastrophic failures.
- Luis Filipe Nunes: Asked whether real use cases would be brought to future meetings. Tom confirmed yes (Gao's use case documents will be circulated and incorporated).
- Markus Fiebig: Left comments in GitHub.
- Thinesh Sornalingam: Supportive of the agile approach; noted the model appears to meet minimum requirements. Asked that future discussion address what support will be provided to users transitioning from WMDR1 to WMDR2 (translation services, tooling). Agreed this can be addressed closer to implementation.
- Thomas Latter: No objections; intends to test the model against his metadata.
- Anna Milan: Welcomed the tangible progress. Raised a concern about whether the fields in the Observation class marked as 1-01 imply changes to how code lists are managed, and asked that this be considered going forward.
- Tom/Jörg: prepare example showing a WMDR2 record alongside an associated WIS2/WCMP2 record (carried forward)
- Circulate Gao's use case documents to the full team or on Issue #8
- Anna: investigate tagging/assigning the full team to Issue #6 on GitHub
- All: review Issue #6 and contribute comments identifying WMDR1 model/representation issues (not OSCAR implementation issues)
- All: document any concerns with the proposed facility → instrument → observed variable model in Issue #8
- Anna: provide an update on OSCAR NextGen status at the next meeting
- Tom/Jörg: Update UML and documentation incorporating meeting comments
- Tom/Jörg: Begin drafting standards document and JSON schema