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.juc...@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@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: jbi...@cicsnc.org
o: +1 828 271 4900
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
