On Mon, Jun 4, 2012 at 2:17 PM, Jonathan Gregory
<j.m.gregory at reading.ac.uk> wrote:
> Dear Etienne
>
> I think the structure you have adopted for the data is fine.
>
>> ? ? ? double pft(pft) ;
>> ? ? ? ? ? ? ? pft:long_name = "plant functional type" ;
>> ? ? ? ? ? ? ? pft:units = "none" ;
>>
>> ? ? ? double npp(time, pft, latitude, longitude) ;
>> ? ? ? ? ? ? ? npp:long_name = "npp of carbon for each pft" ;
>> ? ? ? ? ? ? ? npp:units = "kg m-2 year-1" ;
>
> The specific problem you raise is concerned with the axis attribute. That
Yes, I am mostly concerned with representing the pft axis in a
practical manner, it is not a requirement that it adheres strictly to
the cf conventions (besides, there are none for this case).
> attribute is really intended for identifying spatiotemporal coordinates;
> although it may be convenient, it is redundant because they can also be
> identified in other ways. It has not been extended for non-spatiotemporal
> axes like pft. In your CDL, the pft axis is identified by its long_name.
> To make this more reliable, you might want to use a standard_name for this
> pft coordinate variable. There isn't such a standard_name at present, but
> area_type is often vegetation type in practice, so you could perhaps use
> that. We could standardise new area_types by proposals to this email list.
The problem with area_type is that it mostly deals with "vegetation
types" rather than "plant function types", some models make a
distinction between them.
For example, a "savanna" vegetation type is made of several "plant
function types", such as grass, shrubs and deciduous trees
Also currently, area types only has one type for vegetation.
>
> Also, there is the new proposal, which I expect will go into the
> standard_name table, for UN/FAO land cover types, which in many cases are
> also vegetation types.
> See http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2012/033507.html
I will look into that and see if we can adapt our terms to the UN/FAO ones.
>
> The quantities identified by these standard_names are string-valued, whereas
> you expect a numeric pft. However, a string-valued one could be encoded as a
> number by using the flag_values and flag_meanings attributes.
Numeric values are easier to deal with in many models, and also in
displaying (e.g. in grads)
>
> There is an existing standard name for NPP as well viz
> net_primary_productivity_of_carbon (kg m-2 s-1)
Thanks, I will see if we can change our names to the CF spec.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Mon Jun 04 2012 - 13:19:54 BST
