Wmo paramids#62
Conversation
Co-authored-by: Olivier Iffrig-Petit <olivier@iffrig.eu>
Minor edits on WMO units
There was a problem hiding this comment.
Pull request overview
Adds a new MARS language decision record describing how to handle short-name ambiguity for new WMO-unit paramids (including an explicit units= post-processing keyword concept), and updates the MARS language ADR index/statuses accordingly.
Changes:
- Mark MARS-007 as Accepted in both the index and the decision record status line.
- Add new decision record MARS-008 (“WMO Units”) proposing an approach for short-name handling and on-the-fly unit coercion.
- Add MARS-008 to the MARS language README index.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| MARS language/README.md | Updates the ADR index to reflect MARS-007 acceptance and add MARS-008. |
| MARS language/MARS-007-Timespan-Absence.md | Updates the ADR status line to Accepted. |
| MARS language/MARS-008-WMO-Units.md | Introduces a new ADR proposing handling/UX for WMO-unit paramid transitions and a units= concept. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| This approach is the simplest/most natural approach. It maintains the contextually unique mapping of short names to `paramid`s in the MARS language expansion, and as a result ensures that the old/new behaviour of the language will be the same for requests using short names as for `paramid`s. | ||
|
|
||
| The biggest issue with this approach is that we already have data produced in production systems (DE/AI) which use the ambiguous short names. A remapping to change this would result in systems that either need to hard code the date to support this old data, to rearchive this old data after processing, or would break access to it. Further, it would require changing user requests for unchanged data queries. | ||
|
|
There was a problem hiding this comment.
In addition, renaming the post-migration short names for base parameters would force corresponding renames for many related parameters that are generated by design from the same short-name root. Statistical variants follow a structured naming pattern (for example tp as the base, avg_tp for averages, min_tp for minima, and max_tp for maxima), so changing one base short name propagates into a wide family of derived short names.
| #### 1. Unique Short Name Mapping | ||
| This approach is the simplest/most natural approach. It maintains the contextually unique mapping of short names to `paramid`s in the MARS language expansion, and as a result ensures that the old/new behaviour of the language will be the same for requests using short names as for `paramid`s. | ||
|
|
||
| The biggest issue with this approach is that we already have data produced in production systems (DE/AI) which use the ambiguous short names. A remapping to change this would result in systems that either need to hard code the date to support this old data, to rearchive this old data after processing, or would break access to it. Further, it would require changing user requests for unchanged data queries. |
There was a problem hiding this comment.
Why would a rearchival be necessary ? The data are indexed with the paramId. The shortName is not used to index.
Description
Contributor Declaration
By opening this pull request, I affirm the following: