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 <j.m.greg...@reading.ac.uk> 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 > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ____________________________________ Randy C. Horne (rho...@excaliburlabs.com) Principal Engineer, Excalibur Laboratories Inc. voice & fax: (321) 952.5100 url: http://www.excaliburlabs.com _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
