Hi Randy,
Yes, I agree it extends the meaning of "area_type" a bit, but I would
think we could legitimately describe the "nature of the surface" as
being sunlit or in darkness ("covered by the darkness of night") or
"enjoying the last vestiges of daylight" (i.e., twilight), so I don't
think we should rule out its use on these grounds (although I'm not
arguing the more specific "hybrid" option isn't superior).
regards,
Karl
On 1/14/14 8:39 AM, Randy Horne wrote:
> 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
> <mailto: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 <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ____________________________________
>
> Randy C. Horne (rhorne at excaliburlabs.com
> <mailto: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/977af272/attachment-0001.html>
Received on Tue Jan 14 2014 - 10:08:58 GMT
