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.gregory at 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 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
Received on Fri Jan 10 2014 - 05:52:11 GMT
