Should ParameterGroup be split

[chris-little]

ParameterGroup has two main use cases:

1. to group values that are really a single vector or tensor value, rather than scalar. such as Wind Velocity expressed as Wind Speed and Wind Direction, or Surface Wind Stress;
2. to group a value with some derived statistical values, such as standard deviation.

ParameterGroup addresses both of these use cases effectively, but in the future, should the two above patterns be explicitly identified?

[jonblower]

There are examples of both in the current spec but they would need to be turned into proper specifications rather than illustrative examples.

Just to clarify the second use case - it's not about grouping values with statistics that are derived from them, it's about grouping scalar fields that represent the parameters of a probability distribution function, thereby enabling us to represent uncertainty or sub-grid variability. So for each element in the domain, if the PDF is Gaussian, we would have the mean and the standard deviation of the quantity at that location. Other PDFs would need a different set of parameters.

[KathiSchleidt]

Working on a CovJSON encoding for TSML, we've started wondering if it's possible to nest ParameterGroups to enable provision of the 2 orthogonal concepts listed by @chris-little above. How do you deal with cases where you provide multiple Observed Properties (e.g. Wind Speed and Wind Direction) as well as various statistical values (e.g. mean, std. dev.)?

If we could nest ParameterGroups, we could first create a Group with one ObsProp and its statistical values, then group these groups.

[jonblower]

Hi @KathiSchleidt - yes, the use case of "vectors with uncertainty" is valid, and nesting of ParameterGroups could be a solution. It would be quite complex but it's probably hard to avoid the complexity. Are there other standards that address this issue? Perhaps something from the EO community (wind scatterometry)?