Martin,
I looked over the CMIP5 tables and the CF standard names, and it seems
to me that the varied nature of the landCoverFrac variable means that it
should probably have its own standard name - 'vegetation_area_fraction'.
As part of its definition you would probably also want to call out a new
coordinate variable standard name for the vegtype coordinate -
'plant_functional_type'. This could be defined as using a non-controlled
vocabulary (see soil_type), and you could also specify how to provide
sufficient detail of what each plant functional type represents.
The alternative is to continue to use area_type, and to explain to
people that they need to request new area types when the existing ones
don't match their model outputs and explain to them how to make the
requests. Doable, but it might generate a large and confusing number of
area type table entries.
I've no idea why the cfchecker didn't complain when the entries weren't
present in the area type table used by the application.
Grace and peace,
Jim
On 3/20/15 6:09 AM, martin.juckes at stfc.ac.uk wrote:
> Hello,
>
> I have a question about the specification of area_type in the CF Convention and its usage in CMIP5 -- motivated by the need to define how it might be used in CMIP6.
>
> The convention document appears clear: "Some standard names (e.g. region and area_type) are used to indicate quantities which are permitted to take only certain standard values. This is indicated in the definition of the quantity in the standard name table, accompanied by a list or a link to a list of the permitted values." (section 3.3) In the case of "area_type", values must be taken from the area_type table.
>
> In the CMIP5 variable request, however, the "landCoverFrac" variable is defined to have a dimension with standard name "area_type" that takes values corresponding to the model land cover scheme. Consequently, files have been submitted using terminology chosen by the data providers (e.g. "Temperate_Evergreen", "Temperate_Deciduous" in landCoverFrac_Lmon_MIROC-ESM_historical_r1i1p1_185001-200512.nc). Such files are clearly inconsistent with the convention but they appear to be passed by the CF checker (http://puma.nerc.ac.uk/cgi-bin/cf-checker.pl ).
>
> For CMIP6 we want to have compliant files, of course, but in practise we can only hope to have compliance where there is an automated check. So should we treat the rule about area_type only taking values from the approved list as a recommendation, or should the checker and the CMIP request be adjusted to comply with the existing wording? (Or have I completely misread something?)
>
> regards,
> Martin
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150320/e6492033/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bicfegbg.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150320/e6492033/attachment-0001.png>
Received on Fri Mar 20 2015 - 08:49:29 GMT
