-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting 2026 02 18
Wednesday 18 February 2026 15h - 16h UTC
MS Teams
| Name | Affiliation/Country | GitHub handle | Attendance |
|---|---|---|---|
| Tom KRALIDIS (Chair) | Canada/ECCC | @tomkralidis | X |
| Lance BRAASCH | Scripps | @lancebraasch | X |
| Gao CHEN | NASA | @gaochen-larc | X |
| Markus FIEBIG | NILU | @markusfiebig | |
| Jörg KLAUSEN | MeteoSwiss | @joergklausen | X |
| Thomas LATTER | WMO / OceanOps | --- | |
| Thinesh SORNALINGAM | Canada/ECCC | @thineshsornalingam | X |
| Fabrice THEBAULT | MFI | @fabricethebault | X |
| Alex VERMEULEN | ICOS | --- | X |
| Anna MILAN | WMO Secretariat | @amilan17 | X |
| Dave BERRY | WMO Secretariat | @david-i-berry | X |
| Luis NUNES | WMO Secretariat | X |
- Previous meeting minutes and actions (all)
- Secretariat updates (Anna)
- Development
- update on primary examples (Tom/Jörg)
- clarify entity relationships / generic instruments (Jörg)
- core and extensions design using WCMP2 (example) (Tom)
- document/schema status
- pywmdr status
- issues from WMDR1: Issue #6
- Alex to post detailed technical comments on GitHub Issue Tracker (vertical heights, instruments, UUIDs, TIDs): Alex was not present. Some comments may have been posted. Action carried forward.
- Markus to open a GitHub issue on WIS2 and WMDR2 integration requirement: Done — Issue #7 created. Action closed.
- Tom/Jörg to prepare example showing a WMDR2 record alongside an associated WIS2/WCMP2 record: Not ready. Carried forward to next meeting.
- Anna to ensure all team members have access to the WMDR development repository: Done. Anyone without access should contact Anna.
- Anna to rename the master branch in the wmdr2-devt repository: Done (completed just before the meeting).
- Tom to update the WMDR2 repo to reference the dev sandbox and repository: Done. Model work from Enterprise Architect was moved to wmdr2-devt and linked from the main WMDR2 readme. The main WMDR2 repo scope is the encoding schema, standard document, and examples; everything else (including software) lives in wmdr2-devt.
- Everyone to continue discussion on Issue #3: Discussion drifted toward Issue #8 topics. Jörg asked participants to stay focused on the issue title. The group agreed to consolidate and close the issue, with outcomes reflected in examples and the standard document.
The group is on a tight timeline — a proposal needs to be ready by the beginning of summer. Biweekly meetings continue, with significant asynchronous work expected between sessions.
Tom and Jörg held an offline session the day before the meeting to align on their respective example approaches for the same station (0-20008-0-THE). Jörg's example is a full translation of an existing OSCAR record (~1000+ lines); Tom's is a manually authored, compact representation (~80-100 lines). The two differ in approaches to encoding intervals, periods, and history, but convergence is expected. Jörg intends to automate record conversion using scripts so the approach can eventually be applied to all current OSCAR/Surface holdings. Key outcomes of the offline discussion included clarifications on use of OGC constructs and how an API might query the content — these API use cases should be documented.
Entity relationships / generic instruments (Issue #8, Jörg)
Jörg presented the proposed shift in the WMDR2 data model:
Current WMDR1 model: Centred on the observed quantity — a facility is mandatory and links to an "observation capability" describing the observed variable, process, temporal schedules, etc. Equipment/instruments are optional.
Proposed WMDR2 model: Centres on a facility as a wrapper for deployed instruments (or human observers). Instruments are deployed to a facility to perform observations of one or more quantities.
Key points from the discussion:
- This approach has been aligned between Tom, Jörg, and Fabrice, and was brought to the full group as a sounding board.
- Many existing OSCAR records lack explicit instrument information. The proposal accommodates "generic instruments" — where instrument type can be inferred from the observed variable (e.g., temperature measurement implies a thermometer), allowing migration without data loss.
- An instrument deployed at time T can be assumed to observe all its associated variables from that time, reducing duplication of temporal documentation per variable.
- Users querying the database can still search by observed variable, time, and method — discoverability is not reduced.
- Gao (NASA) noted that many users are variable-first and may not know instrument details beyond a basic description; partial instrument information must be supportable.
- Anna raised a caution based on experience with ISO 19115-2: platform → instrument → sensor hierarchies can become complex. The group should be careful not to over-engineer the depth of the hierarchy.
- Gao raised the case of ozonesondes carrying multiple redundant instruments for the same variable — Jörg clarified this is handled by specifying each instrument explicitly.
- Alex (ICOS) noted that users primarily care about data quality, flags, and fit-for-purpose filtering, and that the model should support those use cases. Users generally care about the variable first; instrument detail is secondary.
- Luis raised the importance of smooth, largely automated migration from WMDR1 and the increased complexity introduced by changing the central organising principle from observed variable to instrument. Tom and Jörg acknowledged this: no data will be lost; WMDR1 content will be imported as-is with the original XML preserved. WMDR1 records will likely need to be accepted by the new system during a transition period.
- Fabrice confirmed support for the new facility → instrument → observed variable hierarchy, contingent on a workable technical migration path.
- Tom emphasised the group is building a minimum viable product and should avoid scope creep; items not in the first pass can be added iteratively.
- Tom stressed working examples as the primary way to validate decisions: "examples will win."
Issue #6 — known issues from WMDR1
Jörg requested that the full team review Issue #6 and identify items relevant to WMDR1 model/representation limitations (as distinct from OSCAR/Servicedesk implementation issues). Each relevant issue should be either addressed in WMDR2 or explicitly declined with rationale. Anna will investigate whether the full team can be tagged/assigned to the issue.
- Core and extensions design using WCMP2 (Issue #9, Tom)
- Document/schema status
- pywmdr status
- Tom/Jörg: prepare example showing a WMDR2 record alongside an associated WIS2/WCMP2 record (carried forward)
- Alex: post detailed technical comments on GitHub Issue Tracker re vertical heights, instruments, UUIDs, TIDs (carried forward)
- Gao and Alex: provide end-to-end data search use cases as input to Issue #8, ahead of the next meeting (Gao has 5 use cases drafted; will share via email or issue upload)
- 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: reach out to Gao for a smaller offline meeting (end of next week) to walk through a gauge/instrument use case example