Dear @davidhassell Thanks for raising this point. I agree with your suggestion (when we spoke) that it would be better to *require* `sigma` and `zlev` to contain missing data at levels to which they do not apply. In that case, if the first element `zlev` contains missing data, or the first element of `sigma` does _not_ contain missing data, you can infer that the layers are arranged in order of increasing depth, from the surface to the bottom; if the opposite, that they are arranged from the bottom upwards. This should be stated in the text. It also implies that the non-missing elements of both `sigma` and `zlev` are in monotonic order.
In writing this, I wondered why we assume that layers should be numbered from 1, rather than 0, or any other number. We don't have to make any such assumption, since layer number is not part of formula terms. What matters is only the _order_ of the elements along the dimension. Furthermore, if we require the missing data, `nsigma` is redundant, because you can count the number of non-missing `sigma` values. We could omit `nsigma` from `formula_terms`. Possibly that would be better, because there is a danger of `nsigma` not being updated if the data is processed to keep only subset of the sigma layers; the `formula_terms` might be copied without modification, and thus the metadata could become incorrect and would lead to misinterpretation of the coordinates. However, I expect that existing software may rely on `nsigma`. We don't normally have conformance rules for `formula_terms`, but maybe we should include one to require `nsigma` to agree with missing data in `sigma` and `zlev`, if we keep `nsigma`. What do you and @johnwilkin think of this? Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/314*issuecomment-823390755__;Iw!!G2kpM7uM-TzIFchu!jImfKhpSUquY8HuiGlJL3xLfR_4gfFcDSI0rfAx1AKmtoabfOmlyDeg5xmTrfEH3kLUN7w5Ds74$ This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
