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" <[email protected]> Sent: Wednesday, January 08, 2014 8:11 AM To: "Jonathan Gregory" <[email protected]> Cc: "CF Metadata List" <[email protected]> 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 <[email protected]> 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 > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ____________________________________ Randy C. Horne ([email protected]) Principal Engineer, Excalibur Laboratories Inc. voice & fax: (321) 952.5100 url: http://www.excaliburlabs.com _______________________________________________ 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
