-
Notifications
You must be signed in to change notification settings - Fork 285
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
[PI] Ensure flags are correctly loaded/saved to/from NetCDF #3474
Comments
This ticket is best tackled after #3473 |
The convention with status_flags is to be unitless. An example of a status flag being described within CF conventions is given here: cf-convention/cf-conventions#216
When such a file is loaded by Iris, the current behaviour is to assign the unit to be "1" (In fact, this is the behaviour when using iris to directly instatiate an AncillaryVariable without specifying the unit). As such, a round trip (loading then saving) would result in a unit being assigned to the status_flag against current convention. Additional 2019-12-12 |
In order to preserve unitless cf variables, it may be worthwhile changing the general behaviour defined here: iris/lib/iris/fileformats/_pyke_rules/fc_rules_cf.krb Lines 1654 to 1656 in 242a62f
Changing cf_units._UNIT_DIMENSIONLESS to "no_unit" or cf_units._NO_UNIT_STRING , combined with fixing #3394, ought to make round tripping consistent.
As an alternative to the general approach above, flag variables could be given special treatment, similar to that in the following line: iris/lib/iris/fileformats/_pyke_rules/fc_rules_cf.krb Lines 1673 to 1674 in 242a62f
The cases in which units would be set to "no_unit" could be decided by some combination of standard name, standard name modifier, and presence of flag values and meanings in the variable. |
Part of #3358
According to CF, flags contain
flag_values
,flag_masks
andflag_meanings
attributes.This ticket is to check whether flags require any special handling to ensure that they are correctly loaded/saved.
Additional, 2019-12-12
(from @pp-mo)
Following the "CF-metadata" email list, it seems to me that some of the expected forms and vocabulary usages for flags still rather fluid + changing,
That is, maybe despite statements already accepted in the cf 1.7 document
See cf-convention/cf-conventions#216 in particular,
which is also the issue referenced by this comment from @stephenworsley below
Acceptance Criteria
The text was updated successfully, but these errors were encountered: