Dear Thomas
> Proposed new standard name: sea_ice_classification
>
> Please comment and/or indicate if this is accepted and can be included in
> next version of the CF standard name table.
I think it is fine. Alison Pamment deals with updating the standard name table
and I expect she will revie
Dear Jonathan, and all,
Since there was no further discussion on this subject, I would like to conclude
it by proposing a new standard name for sea ice classification products. The
definition I propose is strongly inspired by that of the "soil_type" standard
name, but also refers to the WMO Sta
Dear Seth
> Attached below are the 93 unique values for surface types from
> these 3 models. If it looks like we could hash out the details
> and extend the existing area_types list could be extended to
> cover this list in fairly short order, then I think we can say
> that the current system wil
Seth, I'm not sure it's a fair test.
By way of piling onto Seth's point, though: When MMI did a vocabulary mapping
workshop a long while ago, by far the least mappable set of vocabularies was
habitat, which I think it is a fair analog to area_types. The problems (sic)
with 'habitat' were that
Jonathan Gregory wrote:
>> Do we get enough benefit by "standardizing" them
>> [area-type names] to offset the cost in time and trouble
>> of the growth of yet another complex name hierarchy? (I
>> know. Some people will say "Yes!" I just have to ask.)
>
>It's a fair question. I am one of thos
Dear Thomas
I think your arguments are persuasive for having a new standard_name of
sea_ice_classification. The definition could refer to WMO's list with a URL.
At a later point we might decide we could include the classification as new
area_types, as you say, but this seems like a good compromise
Dear Jonathan, and Jim,
I must say Jim's soil_type example appeals to me. It is a pragmatic solution
that would get my dataset rapidly into the CF convention. It would require
minimal interaction with the CF table of area_type. I would feel strongly
encouraged to use as many existing area_type
Dear Jim
> If that is OK within the convention, the only issue I see is that
> the convention states that names for area types *must* come from the
> area type table. That seems unnecessarily restrictive to me, and
> I'd encourage the deletion of the requirement. I know that more
> table entries
Jonathan,
If that is OK within the convention, the only issue I see is that the
convention states that names for area types *must* come from the area
type table. That seems unnecessarily restrictive to me, and I'd
encourage the deletion of the requirement. I know that more table
entries can
Dear Jim and Thomas
It is fine to use flag_meanings to encode a string-valued field, as Jim
suggests. It's been suggested before in other contexts. This is a kind of
data compression and I don't think a special standard name is needed for it.
It's still an area_type field.
Best wishes
Jonathan
Thomas,
Is there a particular reason why you aren't using a single variable to
indicate your different classifications? If you want to go with a
variable that uses the standard name "area_type", it seems to me that it
should be constructed like
string sea_ice_type(time, xc, yc):
Dear all,
This message is to revive (part of) a short-lived thread in the last days of
May 2011. Jonathan was kind enough to answer some of my questions then, but it
never ended in a definite solution to my problem, thus the need (for me) to
revive the subject.
I have a (satellite product) dat
Any other opinions?
Cheers, Roy.
*From:* cf-metadata-boun...@cgd.ucar.edu
[cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Karl Taylor
[taylo...@llnl.gov]
*Sent:* 23 February 2011 17:54
*To:* cristina.tronc...@artov.isac.cnr.it
*Cc:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [C
y as it sounds. Any other opinions?
>
> Cheers, Roy.
> From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On
> Behalf Of Karl Taylor [taylo...@llnl.gov]
> Sent: 23 February 2011 17:54
> To: cristina.tronc...@artov.isac.cnr.it
> Cc: cf-metadata@cgd.uca
tronc...@artov.isac.cnr.it
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] help
Hi Chritina,
For dimensionless variables, you can either omit the units attribute or set it
to "1". I don't understand why this error is raised. Did you assign a
"standard_name" to C
Hi Chritina,
For dimensionless variables, you can either omit the units attribute or
set it to "1". I don't understand why this error is raised. Did you
assign a "standard_name" to CHL_count? If so, what did you assign?
thanks,
Karl
On 2/23/11 6:48 AM, cristina.tronc...@artov.isac.cnr.it
Hello,
I have a problem. iN MY NETCDF FILE I define the CHL_count variable.
it is a dimensionless variable.
I used the "standard name modifier: COUNT" for the variable CHL.
for IT I define: units="1" as indicated in the Appendix C of the
"cf-conventions1_4.pdf".
but the cf checker gives me
im looking at an grib1 file from Canadian Centre for Climate Modelling,
downloaded here:
http://cera-www.dkrz.de/WDCC/ui/Compact.jsp?acronym=CCCma_CGCM2_SRES_A2
the docs on that page says that
"The atmospheric component AGCM2 is a spectral model with
triangular truncation at wave no. 32 and 10
18 matches
Mail list logo
