Nan,
In my case, I am using my first and last freeze date values to calculate
growing season lengths. When all the values are on a consistent time
base, I can do simple subtraction to get the season length (first freeze
date - last freeze date). The ease of use for time since epoch vs time
since 'time coordinate variable value' varies by application. Each can
be derived from the other with relative ease. If you use days-in-year,
it seems that it might be worthwhile to add that as a standard name as well.
I can see the utility of a temperature threshold coordinate for freeze
date if you require the temperature to drop below, for example, -2 C
before you count that day as having a freeze.
Grace and peace,
Jim
On 3/16/17 2:24 PM, Nan Galbraith wrote:
> I agree that there's a lot of interest, and I have 2 questions.
>
> To make the data most useful, shouldn't the time coordinate variable be
> Jan 1, and shouldn't the 'days since' (data) variable represent the
> yearday
> within that year?
>
> My specific concerns with Jim's approach:
>
> first_freeze_date:units = "days since 1900-01-01 00:00:00" - This
> doesn't seem
> to me to provide the most easily used data point, wouldn't the
> year-day be more
> convenient, for seeing how this value varies over the years?
>
> And with Antoio's:
>
> first_freeze_date:coordinates="threshold time"; - I don't see how
> threshold,
> which is a temperature, can be a coordinate of this variable. Also,
> I'd like to know
> why setting time:units="days since 2000-6-1"; is preferable to using
> 2000-1-1;
> doesn't this invite errors in using the time in applications like
> matlab and python?
>
> Actually, the metadata doesn't tell me how to interpret the values in
> first_freeze_date -
> the short name implies that they're dates, the units implies they're
> elapsed days, but
> without a reference date to enable decoding.
>
> Cheers - Nan
>
>
> On 3/16/17 8:45 AM, Jim Biard wrote:
>>
>> Hi.
>>
>> There is clearly interest here! I agree that day_in_year is rather
>> generic, and there should probably be a more precise term. I'm not so
>> sure about the cell_methods that were suggested below. In my
>> particular case the values are derived from a daily Tmin product.
>> Each value is the date of the first Tmin < 0 C within the time
>> bounds. If it was a spell length, such as growing season length, then
>> I can see the need for a more climatological cell_method.
>>
>> We can keep this up and work up some standard_name definitions to
>> propose. I'm sure the results will be better if we collaborate
>> compared to what I'd do on my own.
>>
>> Grace and peace,
>>
>> Jim
>>
>>
>> On 3/16/17 7:23 AM, Antonio S. Cofi?o wrote:
>>> Dear all,
>>> There is no standard_name for the concept but there are 2 different
>>> ones which delimit the approach that it could be used as templates
>>> for the new one:
>>> *time_when_flood_water_falls_below_threshold
>>> *(time_when_flood_water_rises_above_threshold and
>>> time_of_maximum_flood_depth are also good examples )
>>> http://cfconventions.org/Data/cf-standard-names/41/build/cf-standard-name-table.html#time_when_flood_water_falls_below_threshold_tr
>>>
>>>> The quantity with standard name
>>>> *time_when_flood_water_falls_below_threshold*: is the time elapsed
>>>> between the breaking of a levee (origin of flood water simulation)
>>>> and the instant when the depth falls below a given threshold for
>>>> the last time, having already risen to its maximum depth, at a
>>>> given point in space. If a threshold is supplied, it should be
>>>> specified by associating a coordinate variable or scalar coordinate
>>>> variable with the data variable and giving the coordinate variable
>>>> a standard name of flood_water_thickness. The values of the
>>>> coordinate variable are the threshold values for the corresponding
>>>> subarrays of the data variable. If no threshold is specified, its
>>>> value is taken to be zero. Flood water is water that covers land
>>>> which is normally not covered by water.
>>> the problem is the event definition, which is quite different to the
>>> one it's been considered here which is more like a climatological
>>> statistics. The good thing is the CF already has some good
>>> definitions for those climatological statistics, like Example 7.11
>>> on CF1.6 document:
>>> http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#extreme-statistics-and-spell-lengths-ex
>>>
>>>
>>> And more convenient definition of this climatological statistics
>>> could be:
>>> http://cfconventions.org/Data/cf-standard-names/41/build/cf-standard-name-table.html#spell_length_of_days_with_air_temperature_above_threshold_tr
>>>
>>>> Air temperature is the bulk temperature of the air, not the surface
>>>> (skin) temperature. A spell is the number of consecutive days on
>>>> which the condition X_below|above_threshold is satisified. A
>>>> variable whose standard name has the form
>>>> spell_length_of_days_with_X_below|above_threshold *must have a
>>>> coordinate variable or scalar coordinate variable with the a
>>>> standard name of X to supply the threshold*(s).*It must have a
>>>> climatological time variable, and a cell_method entry* for within
>>>> days which describes the processing of quantity X before the
>>>> threshold is applied. A spell_length_of_days is an intensive
>>>> quantity in time, and the cell_methods entry for over days can be
>>>> any of the methods listed in Appendix E appropriate for intensive
>>>> quantities e.g. "maximum", "minimum" or "mean".
>>>
>>> And this definition gives a more appropriate way to encode the date
>>> of freezing days using a auxiliary coordinate to specify the
>>> threshold and use a cell_methods attribute along with the
>>> climatology_bounds attribute on time coordinate to specify an
>>> statistics over a period.
>>>
>>> The standard_name should be more like the definition for
>>> spell_length_of_days, but removing using 'time' as general instead
>>> of days. This what I would suggest with respect to the encoding:
>>>
>>> variables:
>>> float first_freeze_date(lat,lon);
>>> first_freeze_date:standard_name="time_when_air_temperature_below_threshold";
>>>
>>> first_freeze_date:coordinates="threshold time";
>>> first_freeze_date:cell_methods="time: minimum within days time:
>>> minimum over days";
>>> first_freeze_date:units="days";
>>> float last_freeze_date(lat,lon);
>>> last_freeze_date:standard_name="time_when_air_temperature_below_threshold";
>>>
>>> last_freeze_date:coordinates="threshold time";
>>> last_freeze_date:cell_methods="time: minimum within days time:
>>> maximum over days";
>>> last_freeze_date:units="days";
>>> float threshold;
>>> threshold:standard_name="air_temperature";
>>> threshold:units="degC";
>>> double time;
>>> time:climatology="climatology_bounds";
>>> time:units="days since 2000-6-1";
>>> double climatology_bounds(time,nv);
>>> data: // time coordinates translated to date/time string type format
>>> time="2008-01-16T00:00";
>>> climatology_bounds="2007-08-01T00:00", "2008-05-31T00:00";
>>> threshold=0.;
>>>
>>> The time: minimum over days, on first_freeze_date cell_methods
>>> attribute represents the shortest time minimum daily temperature
>>> (time: minimum within days) is below threshold.
>>> Equivalent for the last_freeze_date, but in this cas represents the
>>> longest time (time: maximum over days).
>>>
>>> Regards
>>>
>>> Antonio
>>>
>>>
>>>
>>>
>>> --
>>> Antonio S. Cofi?o
>>> Associate Professor and Researcher
>>> Grupo de Meteorolog?a de Santander
>>> Dep. of Applied Mathematics and Computer Sciences
>>> Universidad de Cantabria (Spain)
>>>
>>> Academic Visitor
>>> National Centre for Atmospheric Science
>>> Department of Meteorology
>>> School of Mathematical, Physical and Computational Sciences
>>> University of Reading (UK)
>>>
>>> http://antonio.cofino.es
>>> On 15/03/17 18:16, Jim Biard wrote:
>>>>
>>>> Dan,
>>>>
>>>> How about that? I'm working on similar products. We haven't even
>>>> considered standard names for them.
>>>>
>>>> I went ahead and used 'days since YYYY-MM-DD 00:00:00' for my first
>>>> and last frost dates, since they are valid dates. My files are
>>>> structured as (example for first frost date):
>>>>
>>>> dimensions:
>>>> time = UNLIMITED ; // (56 currently)
>>>> lon = 960 ;
>>>> lat = 490 ;
>>>> bnds = 2 ;
>>>> variables:
>>>> double time(time) ;
>>>> time:standard_name = "time" ;
>>>> time:long_name = "time" ;
>>>> time:axis = "T" ;
>>>> time:units = "days since 1900-01-01 00:00:00" ;
>>>> time:calendar = "gregorian" ;
>>>> time:bounds = "time_bounds" ;
>>>> double time_bounds(time, bnds) ;
>>>> double lon(lon) ;
>>>> lon:standard_name = "longitude" ;
>>>> lon:long_name = "longitude" ;
>>>> lon:units = "degrees_east" ;
>>>> lon:modulo = 360. ;
>>>> lon:axis = "X" ;
>>>> lon:bounds = "lon_bounds" ;
>>>> double lon_bounds(lon, bnds) ;
>>>> double lat(lat) ;
>>>> lat:standard_name = "latitude" ;
>>>> lat:long_name = "latitude" ;
>>>> lat:units = "degrees_north" ;
>>>> lat:axis = "Y" ;
>>>> lat:bounds = "lat_bounds" ;
>>>> double lat_bounds(lat, bnds) ;
>>>> float first_freeze_date(time, lat, lon) ;
>>>> first_freeze_date:_FillValue = 1.e+20f ;
>>>> first_freeze_date:missing_value = 1.e+20f ;
>>>> first_freeze_date:comment = "Date of the first
>>>> day with a minimum temperature at or below 0 degrees C over the
>>>> 9 month period starting Aug 1 of each year." ;
>>>> first_freeze_date:flag_meanings =
>>>> "No_Freeze_Following" ;
>>>> first_freeze_date:long_name = "First freeze
>>>> date" ;
>>>> first_freeze_date:valid_min = 0. ;
>>>> first_freeze_date:flag_values = -2. ;
>>>> first_freeze_date:units = "days since 1900-01-01
>>>> 00:00:00" ;
>>>> first_freeze_date:calendar = "standard" ;
>>>>
>>>> with the time bounds reflecting 1 Aug to 1 May for each year.
>>>>
>>>> On 3/15/17 1:50 PM, Hollis, Dan wrote:
>>>>>
>>>>> Hi Jon,
>>>>>
>>>>> I?d be interested to know how to tackle this problem too. I?ve
>>>>> recently been generating some datasets of ?date of first frost?
>>>>> and ?date of last frost? and have no idea how to describe them in
>>>>> a CF-compliant way.
>>>>>
>>>>> Jim?s suggestion of ?day_of_year? is better than just ?days?,
>>>>> however this doesn?t capture what the ?something? is that has
>>>>> happened, nor that is the first/last/Nth occurrence of that event.
>>>>> What sort of events are you looking at?
>>>>>
>>>>> In my application I?m just looking at UK data, hence my ?year?
>>>>> runs from 1^st July to 30^th June (to span the N Hemisphere
>>>>> winter). It?s easy enough to use the bounds to indicate this, but
>>>>> I?m then not sure what values to store in the data array. Number
>>>>> of days since 1^st July maybe? Or ordinal date (1^st Jan = 1,
>>>>> 31^st Dec = 365)?
>>>>>
>>>>> Dan
>>>>>
>>>>> PS I have a whole bunch of other metrics that I?m looking at e.g.
>>>>> length of the longest spell, number of spells greater then N days
>>>>> etc. These seem even more complicated to describe using CF.
>>>>> Something for another post I think...
>>>>>
>>>>> *From:*CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] *On
>>>>> Behalf Of *Jim Biard
>>>>> *Sent:* 15 March 2017 16:28
>>>>> *To:* cf-metadata at cgd.ucar.edu
>>>>> *Subject:* Re: [CF-metadata] Recording "day of year on which
>>>>> something happens"
>>>>>
>>>>> Jon,
>>>>>
>>>>> I agree that a cell_methods attribute doesn't seem to be
>>>>> necessary. A new standard_name like 'day_in_year' or 'day_of_year'
>>>>> would likely make things clearer.
>>>>>
>>>>> Jim
>>>>>
>>>>> On 3/15/17 11:22 AM, Jon Blower wrote:
>>>>>
>>>>> Thanks Jim, that?s very helpful. Is cell_methods necessary in
>>>>> this case (for the time axis bounds) ? probably not since this
>>>>> isn?t a statistical quantity like an average, but a value
>>>>> that?s ?representative? of the year.
>>>>>
>>>>> I seem to remember from a while back that there was a proposal
>>>>> to allow time axes to use ?calendar years since X? (as opposed
>>>>> to ?years since X?, which uses a fixed-length UDUNITS year),
>>>>> which might handle this use case. I have been out of the loop
>>>>> for a while, but I can?t find mention of that in the CF spec,
>>>>> so maybe that didn?t go through.
>>>>>
>>>>> I might consider requesting a new standard name ? ?days? is
>>>>> good, but I wonder if a more specific one would be helpful.
>>>>>
>>>>> Best wishes,
>>>>> Jon
>>>>>
>>>>> *From: *CF-metadata <cf-metadata-bounces at cgd.ucar.edu>
>>>>> <mailto:cf-metadata-bounces at cgd.ucar.edu> on behalf of Jim
>>>>> Biard <jbiard at cicsnc.org> <mailto:jbiard at cicsnc.org>
>>>>> *Date: *Tuesday, 14 March 2017 15:12
>>>>> *To: *"cf-metadata at cgd.ucar.edu"
>>>>> <mailto:cf-metadata at cgd.ucar.edu> <cf-metadata at cgd.ucar.edu>
>>>>> <mailto:cf-metadata at cgd.ucar.edu>
>>>>> *Subject: *Re: [CF-metadata] Recording "day of year on which
>>>>> something happens"
>>>>>
>>>>> Jon,
>>>>>
>>>>> 1) I'd use 'days'. It is a valid standard name apart from the
>>>>> 'days since date' formalism. It's not perfect, but it's legal.
>>>>> You could, alternatively, request a new standard name.
>>>>>
>>>>> 2) Use a time_bounds variable. I would tend to set the time to
>>>>> be July 1 at midnight for each year, and set the bounds for
>>>>> each year to Jan 1 of that year and Jan 1 of the next year.
>>>>>
>>>>> Grace and peace,
>>>>>
>>>>> Jim
>>>>>
>>>>> On 3/14/17 10:43 AM, Jon Blower wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>> We need to structure a NetCDF file that will hold a
>>>>> variable that represents the day of the year on which an event
>>>>> happened (integers from 0 to 366). This value is recorded every
>>>>> year for a number of years. I have a couple of questions about how
>>>>> best to do this:
>>>>>
>>>>>
>>>>> 1. What is the best standard name to use for the day of
>>>>> the year? I didn?t find anything in the standard name table,
>>>>> although I might have missed it.
>>>>>
>>>>>
>>>>> 2. What would be the best way to define the time axis?
>>>>> Each point along the axis would represent a whole year, rather
>>>>> than an instant in time. I could simply pick an arbitrary instant
>>>>> (e.g. midnight on 1st Jan) to represent the year, but is there a
>>>>> better way?
>>>>>
>>>>>
>>>>> Thanks in advance for any help!
>>>>>
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>>
>
>
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA?s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170316/1e2095ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170316/1e2095ab/attachment.png>
Received on Thu Mar 16 2017 - 12:38:41 GMT
