Hi Jonathan,
Thinking in terms of CDAT, which is what I work with most of the time, there would actually be advantage (as well as space saving) in doing it this way. CDAT cannot handle character variables from NetCDF, therefore the flagged version would allow the data to be read and then some extra code would have to ensure that it mapped the attributes correctly. However, I can't think of an instance where it would be more useful to store an array of flag characters rather than integers.
Cheers,
Ag
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu on behalf of Jonathan Gregory
Sent: Fri 11/11/2005 8:02 AM
To: cf-metadata at cgd.ucar.edu
Cc: Burkhardt.Rockel at gkss.de
Subject: [CF-metadata] extended use of flag_values and flag_meanings
Dear all
Burkhardt Rockel asked whether it is possible to use flag_values and
flag_meanings (CF 3.5) for string-valued data variables. These two attributes
were introduced with ancillary data (CF 3.4) in mind e.g. data quality flags.
Burkhardt's suggestion would be to use them to encode a data variable. For
instance, we could encode this
variables:
char land_cover(lat,max_string_length)
land_cover:standard_name="land_cover";
data:
land_cover="needleleaf_tree","needleleaf_tree","shrub","ice","ice", ...;
like this
variables:
byte land_cover(lat)
land_cover:standard_name="land_cover";
land_cover:flag_values=0, 1, 2;
land_cover:flag_meanings="needleleaf_tree shrub ice";
data:
land_cover=0,0,1,2,2,...;
This doesn't require any new machinery, the file is no less self-describing,
it saves space and it might be more convenient for plotting. The string values
could be standardised but their numerical encoding would not have to be.
However this scheme requires a bit more work to get the meaning out of it.
Any views?
Cheers
Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Nov 11 2005 - 02:42:12 GMT
