Dear All:
It would seem we have settled on area_fraction_of_day_defined_by_solar_zenith_angle, area_fraction_of_night_defined_by_solar_zenith_angle, and area_fraction_of_twilight_defined_by_solar_zenith_angle.
Definitions and canonical units are included here to complete the proposal:
(1) area_fraction_of_day_defined_by_solar_zenith_angle
defn:
"X_area_fraction" means the fraction of horizontal area occupied by X. "X_area" means the horizontal area occupied by X within the grid cell. A coordinate variable of solar_zenith_angle indicating the day extent should be specified.
canonical units:
1
(2) area_fraction_of_night_defined_by_solar_zenith_angle
defn:
"X_area_fraction" means the fraction of horizontal area occupied by X. "X_area" means the horizontal area occupied by X within the grid cell. A coordinate variable of solar_zenith_angle indicating the night extent should be specified.
canonical units:
1
(3) area_fraction_of_twilight_defined_by_solar_zenith_angle
defn:
"X_area_fraction" means the fraction of horizontal area occupied by X. "X_area" means the horizontal area occupied by X within the grid cell. A coordinate variable of solar_zenith_angle indicating the twilight extent should be specified.
canonical units:
1
very respectfully,
randy
On Jan 29, 2014, at 8:58 AM, rhorne at excaliburlabs.com wrote:
> Karl:
>
> sorry about the delay in moving this discussion forward.
>
> Thinking through your counter-proposal of making use of the existing standard_name "area_fraction", and adding area_types for day, night, and twilight....
>
> In our application these area_fractions are defined in terms of solar zenith angle. The units are degrees. The area_fraction standard_name is a dimensionless quantity.
>
> Also note that what day, night and twilight mean in terms of the solar zenith angle may vary as a function of the application. Thus, hard-coding the precise meaning of day, night, and twilight in a definition does not provide sufficient flexibility,
>
> As a result, using area_fraction with day/night/twilight area_types doesn't satisfy our need (while it could satisfy the needs of others.)
>
>
> very respectfully,
>
> randy
>
>
> ++++++
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140207/dd0f3129/attachment-0001.html>
Received on Fri Feb 07 2014 - 05:49:36 GMT
