⇐ ⇒

[CF-metadata] new standard names: day, night, and day/night terminator area_fractions

From: rhorne at excaliburlabs.com <rhorne>
Date: Wed, 8 Jan 2014 11:51:40 -0500

Dear All:

I made (at least) one mistake below.

Option (3) requires separate variables for day, night, and terminator region because a variable has a single cell_methods attribute, and cell_methods is used to specify the areal extent.

very respectfully,

randy

----------------------------------------
From: "Randy Horne" <rhorne at excaliburlabs.com>
Sent: Wednesday, January 08, 2014 8:11 AM
To: "Jonathan Gregory" <j.m.gregory at reading.ac.uk>
Cc: "CF Metadata List" <cf-metadata at cgd.ucar.edu>
Subject: Re: [CF-metadata] new standard names: day, night, and day/night terminator area_fractions

Dear Jonathan:

All the options identified so far all have pros and cons. I'll take a crack at a summary-level recap ..

(1) add a type of area fraction consistent with current definition of existing area_fraction (i.e.. day_area_fracton, night_area_fraction, day_night_terminator_area_fraction)

pros: clear, consistent with current use and definition of area
cons: 3 standard names where 1 can be made to work

(2) add a new grammatical form of a standard_name containing area_fraction i.e.. area_fraction_X_solar_zenith_angle, area_fraction_for_solar_zenith_angle_within_bounds)

A variety of options have been set forth for X, such as "of", "as a function of", "with", "defined_by", "with_given"

pros: one standard name, one variable can hold all three values
cons: new form of standard names containing area_fraction, options are either not particularly clear or violate (to varying degrees) conventions associated with existing standard names,

(3) make use of existing area_fraction names and qualify the type of area_fraction with one or more coordinate variable(s) and accompany use of cell_methods attribute

pros: no need for an additional standard name, unambiguous, flexible (allows for a variety of yet-to-be-defined quantities), one variable can hold all three values
cons: modification to the definition of area_fraction required, more complex than other options

(4) a hybrid of (1) and (2) (i.e. area_fraction_of_night_defined_by_solar_zenith_angle, area_fraction_of_day_defined_by_solar_zenith_angle, area_fraction_of_terminator_region_defined_by_solar_zenith_angle)

pros: very clear
cons: new form of standard names containing area_fraction, 3 standard names where 1 can be made to work

Despite the additional complexity, I like option (3) because of the flexibility it provides.

very respectfully,

randy

On Jan 7, 2014, at 10:09 AM, Jonathan Gregory <j.m.gregory at reading.ac.uk> wrote:

> Dear Randy
>
>> what about area_fraction_defined_by_solar_zenith_angle ?
>>
>> "defined_by" exists in a couple of other standard names.
>
> That's a good idea. I *almost* like it! In fact all the stdnames with this
> phrase have ocean_mixed_layer_thickness_defined_by_X. This is almost the same
> situation, but it doesn't seem exactly the same to me. The ocean ML is a
> a distinct concept qualitatively; the defined_by_X says precisely how it is
> defined quantitatively, in some cases using a (non-spatiotemporal) coordinate
> value as we are in the present case.
>
> In this case, we are not defining area_fraction. We are specifying an area_
> fraction for a particular value of something else. I think defined_by would
> be just right if the stdname was area_fraction_of_night_defined_by_solar_
> zenith_angle. That would be exactly analogous to the ML case, I feel; the
> night area fraction is a recognisable concept, but it needs to be defined
> precisely. We could include defined_by if we reverted to three stdnames, as
> Randy had proposed, area_fraction_of_X_defined_by_solar_zenith_angle, where
> X is day, night or twilight (if that's the right word), and the defined_by
> phrase is a signal that one shouldn't assume what day or night means without
> checking the bounds provided for the zenith angle.
>
> We already have a generic standard name of area_fraction. This is expected to
> have a (string-valued auxiliary) coordinate of area_type, as it stands. We
> could allow it alternatively to have a coordinate of solar_zenith_angle.
> There would be no indication of what it depended on in the standard name.
>
> If we want to indicate that, what about
> area_fraction_with_given_solar_zenith_angle
> That's another variation on the theme!
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

____________________________________

Randy C. Horne (rhorne at excaliburlabs.com)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
url: http://www.excaliburlabs.com

_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140108/13e547eb/attachment-0001.html>
Received on Wed Jan 08 2014 - 09:51:40 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒