Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion to review the WMDS element 7-14 "Schedule of International Exchange" #39

Open
nuneslf opened this issue Jun 2, 2020 · 7 comments
Assignees
Labels
discussion needed Issue needs further discussion within the team enhancement New feature or request

Comments

@nuneslf
Copy link

nuneslf commented Jun 2, 2020

Rationale:
The WMDS should allow for three levels of schedule:
i) observation (6-08 Schedule of observation),
ii) reporting to a central location, e.g. NMHS headquarters (7-03 Temporal reporting period)
iii) international reporting (7-14 Schedule of international exchange)
When ii and iii are the same, it is okay that 7-14 is a binary element (Y/N); the issue is when they are different, then 7-14 needs to be allow providing the actual schedule.

Element 7-14 was introduced to distinguish international reporting from non-international reporting, i.e. from the first level of reporting, for which 7-03 is used; So, in the WMDS element 7-14 should be "detached" from the non-international level of reporting to allow describing a different schedule if needed.
Example: an AWS is configured to collect data every minute all-year-round (schedule of observation); it sends data to a central system every 30 minutes; reports are disseminated to GTS/WIS every hour.

Below are the current WMDS definition and note, with some suggestions:
Current definition = Allows distinction if/when observations are made/not made available internationally;
Suggested new definition = Schedule of observations reported internationally
Current NOTE:
A binary element (yes/no), that should be associated with the observed variable for each declared observing schedule (7-03 Temporal reporting period)
Suggestion to remove the current NOTE.

@joergklausen joergklausen assigned RMaerz and amilan17 and unassigned nuneslf and KarlBureau Oct 16, 2020
@amilan17 amilan17 removed their assignment Nov 26, 2020
@joergklausen joergklausen transferred this issue from wmo-im/wmds Jan 25, 2021
@joergklausen
Copy link
Contributor

The DataTypes "Schedule" (which is really a coverage) and "Reporting" are currently mandatory attributes of the FeatureType "DataGeneration" (cf. https://schemas.wmo.int/wmdr/1.0RC9/html/). So, logically, for each DataGeneration validPeriod, a Schedule and Reporting need to be defined. This allows for changes over time. The example given by @nuneslf can be partially translated using elements as follows:

  • collect data every minute all year round: temporalSamplingInterval + Schedule
  • send data to central system every 30': this cannot be explicitly expressed. Using aggregationPeriod, the aggregation to 30' data can be described, but it is only implicitly assumed that these data are available locally.
  • reports are disseminated to GTS/WIS every hour: This can be expressed with the elements under "Reporting", although the target "GTS/WIS" cannot be stated. If internationalExchange=True, the Reporting is to some international target, if internationalExchange=False, the Reporting is to some national target.

If a more explicit differentiation between national and international reporting is really needed, it appears that changing the cardinality of the "Reporting" attribute of DataGeneration from currently 1 to 1..2 is the most appropriate way to go. The existing flag internationalExchange would indicate if exchange is international or not. This would also create the flexibility to specify different dataFormat, dataPolicy, officialStatus etc. for national and international reporting. A specific recipient would still not be specified.

@nuneslf and other interested stakeholders: Please comment if this meets the requirements.

@joergklausen joergklausen added the enhancement New feature or request label Apr 23, 2021
@nuneslf
Copy link
Author

nuneslf commented Apr 27, 2021

If I understand correctly the "wmdr schema" language used in the comment by @joergklausen, I'd say that the main point is not about the reporting target (WIS or something else), the issue comes if/when the frequency and/or aggregation is different between the 2nd to the 3rd bullet above, i.e. from the central (national) collection (every 30' in the example) to the international exchange (every 60' in the example). The current configuration doesn't allow distinguishing these two.

@KarlBureau
Copy link

KarlBureau commented Apr 28, 2021 via email

@amilan17
Copy link
Member

amilan17 commented Feb 3, 2023

https://github.com/wmo-im/tt-wigosmd/wiki/2023.02.03-TT-WIGOSMD notes:
this is one of the most requested changes to the standard.

@david-i-berry
Copy link
Member

david-i-berry commented Feb 3, 2023

I may be missing something obvious but is this not covered by having multiple DataGeneration entries for a given instrument.

In principle there should be one entry for the data generation and transmission from sensor to a central location (e.g. 5 second data), one for the national exchange of e.g. 10 minute data and then a final one for the international exchange (e.g. hourly data). There will be processing applied at each of these steps, different software, different aggregation periods, different formats etc. The ability to do this is covered by the existing data model (the capabilities of OSCAR Surface may be different), see figure below:

image

@amilan17 amilan17 added the discussion needed Issue needs further discussion within the team label Apr 21, 2023
@david-i-berry
Copy link
Member

Here's an example from https://oscar.wmo.int/surface/#/search/station/stationReportDetails/0-20000-0-06791 where the above is used in practice, we have hourly reporting for internationally exchanged data, 10 minute reporting for non internationally exchanged data.

image

@joergklausen
Copy link
Contributor

Cf. https://github.com/wmo-im/wmdr2/wiki/WMDRRoadmap where this is taken up as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion needed Issue needs further discussion within the team enhancement New feature or request
Projects
Development

No branches or pull requests

6 participants