Skip to content

Meeting 2026 06 24

Jump to bottom
amilan17 edited this page Jun 25, 2026 · 3 revisions

Date/Time

Wednesday 24 June 2026 14h - 15h30 UTC

Location

MS Teams

Attendees

Name Affiliation/Country GitHub handle Attendance
Tom KRALIDIS (Chair) Canada/ECCC @tomkralidis X
Lance BRAASCH Scripps @lancebraasch
Lucia CAPPELLETTI MeteoSwiss @luciacap
Gao CHEN NASA @gaochen-larc X
Markus FIEBIG NILU @markusfiebig
Jörg KLAUSEN MeteoSwiss @joergklausen X
Thomas LATTER WMO / OceanOps @tomlatter
Thinesh SORNALINGAM Canada/ECCC @thineshsornalingam X
Fabrice THEBAULT MFI @fabricethebault
Alex VERMEULEN ICOS @atverm
Anna MILAN WMO Secretariat @amilan17 X
Dave BERRY WMO Secretariat @david-i-berry
Luis NUNES WMO Secretariat X
Enrico FUCILE WMO Secretariat X
Timo PROESCHOLDT WMO Secretariat X

Agenda

  • Previous meeting minutes and actions (all)
  • Secretariat updates (Anna)
  • OSCAR/Surface renewal update (Tom)
    • wigosbox: WIGOS Node
    • wis2-gdc: WIGOS Global Station Catalogue (extending WIS2 GDC)
    • web ui/portal: TBD
  • Development
    • UML model updates (Jörg)
    • document/schema status (Tom)
    • pywmdr status (Tom)
    • core and extensions design using WCMP2 (example) (Tom)

Notes (DRAFT)

Previous meeting minutes and actions

  • No formal review of prior actions; given the gap since the last meeting, the group moved directly into updates.

Secretariat updates (Anna)

  • In mid-May, the final report of the OSCAR task team was approved by the President at the executive meeting. Anna offered to share it (Task_Team_Report_new_OSCAR_WMO_Final-Clean.pdf).
  • The report covers use cases for station metadata and a more streamlined WIS architecture, with emphasis on removing single points of failure.
  • Next steps: stand up a WIGOS node as a proof of concept, with simple metadata and a simple back-end workflow. Canada has offered to host a catalogue; eventually there could be multiple WIGOS nodes/catalogues.
  • A governance structure for the metadata work is forming, drawing on SC-IMT and the standing committees, with key members from organizations such as EUMETNET and CMA. Some members of this group are likely to participate.
  • Enrico: reaffirmed the earlier decision to experiment with WMDR2 and to build an editor for WMDR2 that can also share the data; the underlying mechanism is already in place.
  • Luis / Timo: nothing further from the Secretariat side.

OSCAR/Surface renewal update (Tom)

  • The renewal is fast-forwarding to phase 2, bypassing phase 1, in order to remove the single point of failure. The goal is a minimum viable product (MVP) of the spec that the group can iterate on and test.
  • Architecture (per Anna's report): a WIGOS node (wigosbox), a single WIGOS Global Station Catalogue extending the WIS2 Global Discovery Catalogue (wis2-gdc), and a web UI/portal fronting the system (TBD).
  • The Secretariat is building a test WIGOS node application; the catalogue work is underway (hosted in Canada), with a portal in front. Sticking to the standard allows multiple independent implementations and publication via channels without additional work.
  • Timeline: targeting the end of this calendar year.
  • Optional elements: Tom favours the WIS2 extensions approach — group many optional elements into downstream extensions so that WMDR2 core stays thin. The detail gets worked out once the MVP sprint begins.
  • WMDR1 → WMDR2 transition will need translation tooling: the WIGOS node can import WMDR1, and/or standalone translator utilities can live on GitHub. As nodes import WMDR1, the canonical representation becomes WMDR2 and the WMDR1 import is lossy. Therefore, the WMDR1 XML will need to remain available in the WIGOS node.

Development — UML model updates (Jörg)

  • Walked through the v0.2 of the WMDR2 UML model (wmdr2-devt) and example records. The model keeps the facility-centric view from WMDR1: a facility hosts observations; instruments are deployed (via deployments) to produce observations; observations are treated as time series.
  • Most entities carry histories with begin/end dates (e.g. position, observing methods, territory); program affiliation remains mandatory.
  • Reusable / cataloged entities: instruments are catalogue entries (manufacturer/model) referenced by instances; schedules are reusable and compliant with JS Calendar (extended with a few OSCAR Surface elements); reporting is handled the same way.
  • Schedule "trick": schedule start dates are pinned to year 1 (1 January) so JS Calendar schedules can be reused; the actual observation start is specified at the deployment level, where it matters.
  • vs WMDR1: structurally similar (to enable transition without major information loss), with a cleaner separation of deployment (an instrument deployed to do something) from observation (the data collected). The main change is how reporting (a time series of observations) is modelled.
  • Experimental / optional concepts: observation sets and instrument sets — kept for a few use cases but may be dropped.
  • Naming: Jörg proposed "historical reporting"; Tom preferred keeping it as "reporting" (arrays of objects), with dates kept as date rather than an interval, per OGC.
  • Territory: the historical-territory box already existed; it was renamed from "temporal …" for clearer, more common language.
  • Optionality: much of the model is optional/conditional — mandatory in ~99% of cases but relaxed to accommodate edge cases (very old/historical observations, human observations with no instrument/deployment).
  • Examples are public on GitHub (200+ test cases): XML records emitted from OSCAR Surface are transformed into OGC-records-compliant WMDR2. Jörg flagged that instruments were missing from the on-screen example (they should appear as a collection under deployment) and will fix it.

Discussion:

  • Gao: instruments link to observations via the deployment, and a deployment can support multiple observations. Contacts can sit at both the deployment and reporting levels to capture different roles (PI vs operator vs data submitter). Raised field-campaign/gauge data as a possible edge case; WDCGG is already ingesting the gauge data.
  • Thinesh: serial numbers belong to the deployment (instance), not repeated per catalogue entry; confirmed "official status" is not a new element (it exists in WMDR1); suggested sharing the model with the WDQMS team for feedback on GeoJSON integration.
  • Anna: raised the risk of bidirectional class relationships allowing infinite/recursive nesting. Tom: the UML is a conceptual model, not the JSON schema — the JSON schema will prevent circular imports.
  • Timo: the standard is expressive but complex; the MVP input interface should be simplified for the WIGOS node, with a clear view of what is essential vs deferred to extensions. Looking forward to the release candidate.

Document / schema status (Tom)

  • The group has been asked to deliver a schema within roughly a month. Tom will produce a WMDR2 core JSON schema for the group to iterate on and test. A development sprint starts now; MVP targeted for end of year.

pywmdr status / core and extensions (WCMP2)

  • Not discussed in detail due to time. The WCMP2-style core-and-extensions design pattern (example issue #9) will be applied as the sprint proceeds.

Actions

Next meeting

End of summer 2026 — date to be confirmed

Clone this wiki locally