Hi Jonathan, Rurkhardt
I think this is an issue that will come to us more and more ... so coming up
with a standard solution makes a lot of sense.
Firstly, I agree the file should be self describing, and I think the solution
you propose will be compact and appropriate. However I would recommend that
we *eventually* standardise the string values *and* the numerical encoding
values (ie the standard name system would have to include the values as well,
and the numerical corrrespondents).
In doing so we should follow the ISO extension model for enumeriations, that
is, not allow users to add their own additional enumerations (if they have
extra classes of land cover for example that are not in the standard), but
rather allow users to add their own long_names and enemerations which could
eventually become standardised ...
One might argue that if we have standardised the numerical encodings and the
values in the standard name system then we don't need to repeat it in the
file. However, I think it is a level of redundancy which costs very little,
makes the software easier to build, and provides a lot of future proofing, in
that folk can lay down files which use their own encodings but also have some
hope of different folks doing things that are comparable (in time).
Meanwhile, until we have the new standard name person in post, I think your
proposed solution is workable and most of what I suggest above can be put in
hold (until someone has the time to make it less incoherent).
Cheers
Bryan
On Friday 11 November 2005 08:02, Jonathan Gregory wrote:
> 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
--
Bryan Lawrence
Director of Environmental Archival and Associated Research
Head of the NCAS/British Atmospheric Data Centre
CCLRC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence
Received on Fri Nov 11 2005 - 03:02:13 GMT
