Karl: Here is the first sentence in the definition of area_type:
A variable with the standard name of area_type contains strings which indicate the nature of the surface e.g. land, sea, sea_ice. Assuming we want to be consistent with the examples in the definition and the existing area_types, I am struggling with the notion that day/night/twilight are “the nature of the surface” ? very respectfully, randy On Jan 10, 2014, at 11:30 AM, Karl Taylor <[email protected]> wrote: > Dear Randy, Jonathan, and all, > > I agree that the hybrid choice with "twilight" rather than "terminator, is > clearest. > > Just to cover all the options (or maybe to revisit a suggestion I missed > earlier), could new area_type(s) be defined -- day, night, twilight -- and > then we could just use the standard name area_fraction with, for example, a > cell_methods of "area: sum where day over all_area_types". This would not > explicitly indicate the zenith angle is used to define the region of day, but > perhaps that could be implied by defining "solar_zenith_angle" coordinate > bounds just as we would under the hybrid method. > > Anyway, I agree that the hybrid choice would still be easier for most to > interpret. > > best regards, > Karl > > On 1/10/14 4:52 AM, Randy Horne wrote: >> Dear Jonathan: >> >> good point on “area”. >> >> “twilight” is fine. >> I’m good with your preference of [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_twilight_defined_by_solar_zenith_angle)] >> >> >> very respectfully, >> >> randy >> >> >> >> On Jan 10, 2014, at 6:50 AM, Jonathan Gregory <[email protected]> >> wrote: >> >>> Dear Randy >>> >>> Thanks for this useful summary. >>> >>> You favour >>> >>>> (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 >>>> Later comment: >>>> 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. >>> I don't think so, actually. cell_methods would have "area: mean" in this >>> case, >>> I think, because you can consider the area_fraction to be the mean over the >>> cell of a binary variable (0 or 1). I'm not sure if that's best, but it is >>> definitely not "point", and "sum" isn't appropriate because it's not >>> extensive. >>> The bounds would belong to the coordinate variable of solar_zenith_angle. >>> >>> I would be content with (3) but on the whole I prefer >>> >>>> (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 >>> I like this because it's very clear, as you say. It thus avoids the problem >>> of >>> >>>> (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 >>> which doesn't point out so prominently that "day" and "night" have to be >>> given precise definitions. The discussion shows that (2) causes problems >>> because we can't find a form of words (so far) that everyone considers to >>> convey the right notion. >>> >>>> (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, >>> I'd be interested to know whether you consider "twilight" to be acceptable. >>> Wikipedia also gives "twilight zone" as a synonym for "terminator". I think >>> "twilight" goes better with "day" and "night" than "terminator" does. >>> >>> What do other people think about all the above? >>> >>> 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 ____________________________________ 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
