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 <taylor13 at llnl.gov> 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 <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
>>
>>
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140114/fce5d5e3/attachment-0001.html>
Received on Tue Jan 14 2014 - 09:39:48 GMT
