⇐ ⇒

[CF-metadata] Recording "day of year on which something happens"

From: Jim Biard <jbiard>
Date: Thu, 16 Mar 2017 15:56:00 -0400

John,

CF is all about precise, scientific, definitions. In precise terms,
'Julian Day modulo the year' is different than 'Julian Day'. I wasn't
meaning to impugn your knowledge or ability.

Grace and peace,

Jim


On 3/16/17 3:49 PM, John Helly wrote:
>
> In language, definitions are based on usage. Julian date, modulo the
> year, is a convention that I have been using for decades to do what
> you are talking about but I defer to wiser minds.
>
> J.
>
>
> On 3/16/17 9:42 AM, Jim Biard wrote:
>>
>> John,
>>
>> As best as I understand it, Julian day is a term that is grossly
>> misused. Julian Day is defined as the elapsed days since January 1,
>> 4713 BCE. Lots of people use the term to refer to day-in-year, but
>> this doesn't seem to be a proper usage.
>>
>> Grace and peace,
>>
>> Jim
>>
>>
>> On 3/16/17 3:36 PM, John Helly wrote:
>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>> --
>> 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>. /
>>
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --
> 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

-- 
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/324291af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170316/324291af/attachment.png>
-------------- 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/324291af/attachment-0001.png>
Received on Thu Mar 16 2017 - 13:56:00 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒