Sorry to jump in here but isn't this just the Julian day?
J.
On 3/16/17 8:24 AM, 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
>>>>>
>>>>>
>>>>>
>
>
--
John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / http://www.sdsc.edu/~hellyj
ORCID ID: orcid.org/0000-0002-3779-0603
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hellyj.vcf
Type: text/x-vcard
Size: 158 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170316/e46a82a0/attachment.vcf>
Received on Thu Mar 16 2017 - 13:36:06 GMT
