No worries. Not taken that way. I'm all in favor of precision.
J.
On 3/16/17 9:56 AM, Jim Biard wrote:
>
> 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>. /
>
>
--
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 --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170316/81e0bff3/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/81e0bff3/attachment.png>
-------------- 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/81e0bff3/attachment-0001.png>
-------------- 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/81e0bff3/attachment.vcf>
Received on Thu Mar 16 2017 - 13:57:05 GMT
