On Mon, Jun 4, 2012 at 2:17 PM, Jonathan Gregory
<[email protected]> 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
> [email protected]
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to