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

Jim Biard jbiard at cicsnc.org
Fri Mar 17 08:24:46 MDT 2017


Nan,

That's another good point to keep in mind. Most DOY (Day Of Year) 
representations that I have seen are 1-based. Everything to do with 
calendars and/or time always seems to get complicated!

Jim


On 3/17/17 9:05 AM, Nan Galbraith wrote:
> We use the term yearday; even this is imprecise, because it can be 
> calculated
> at least 2 different ways.
>
> We always include a reference to (and definition of) the Naval yearday 
> convention,
> which defines noon on January 1 as yearday 1.5, not 0.5.
>
> For time series data that we publish (to OceanSITES, mainly) we use 
> the 'normal'
> CF "days since 1950-01-01 00:00:00", but for climatology data and 
> other internal
> data, we use whatever is convenient.
>
> Cheers - Nan
>
>
> On 3/16/17 4:48 PM, Dave Allured - NOAA Affiliate wrote:
>> Here is a credible appeal to avoid the terms Julian Date and Julian 
>> Day in any scientific usage, to mean Day of Year. Citing document 
>> MODIFIED JULIAN DATE, M. R. Winkler, formerly with U.S. Naval 
>> Observatory:
>>
>> http://tycho.usno.navy.mil/mjd.html
>>
>> """ The MJD (and even more so the JD) has to be well distinguished 
>> from this day of the year (DOY). This is also often but erroneously 
>> called Julian Date, when in fact it is a Gregorian Date expressed as 
>> number of days in the year. This is a grossly misleading practice 
>> that was introduced by some who were simply ignorant and too careless 
>> to learn the proper terminology. It creates a confusion which should 
>> not be taken lightly. Moreover, a continuation of the use of 
>> expressions "Julian" or "J" day in the sense of a Gregorian Date will 
>> make matters even worse. It will inevitably lead to dangerous 
>> mistakes, increased confusion, and it will eventually destroy 
>> whatever standard practices exist. """
>>
>> Though I also have used these terms in the past, I now agree with 
>> this opinion.  I would suggest that CF Conventions should use only 
>> Day of Year (DOY) or some similar term for this purpose.
>>
>> --Dave
>>
>>
>> On Thu, Mar 16, 2017 at 1:56 PM, Roy Mendelssohn - NOAA Federal 
>> <roy.mendelssohn at noaa.gov <mailto:roy.mendelssohn at noaa.gov>> wrote:
>>
>>     Julian day is used in several different ways,  as John says:
>>
>>     https://landweb.modaps.eosdis.nasa.gov/browse/calendar.html
>> <https://landweb.modaps.eosdis.nasa.gov/browse/calendar.html>
>>
>>     -Roy
>>
>>     > On Mar 16, 2017, at 12:49 PM, John Helly <hellyj at ucsd.edu
>>     <mailto:hellyj at ucsd.edu>> 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
>> <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
>> <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
>> <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
>>     <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
>>     <mailto: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>>
>>     >>>>>>>> <mailto: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>>
>>     <mailto: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>"
>>     >>>>>>>> <mailto: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>>
>>     >>>>>>>> <mailto: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 <mailto:CF-metadata at cgd.ucar.edu>
>>     >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
>>     >>
>>     >> --
>>     >> <Mail Attachment.png>             Visit us on
>>     >> Facebook     Jim Biard
>>     >> Research Scholar
>>     >> Cooperative Institute for Climate and Satellites NC
>>     >> North Carolina State University
>>     >> NOAA National Centers for Environmental Information
>>     >> 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 and ocean and
>>     geophysics information, and follow us on Twitter at
>>     @NOAANCEIclimate and @NOAANCEIocngeo.
>>     >>
>>     >>
>>     >> _______________________________________________
>>     >> CF-metadata mailing list
>>     >>
>>     >> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>     >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> <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 <http://www.sdsc.edu/%7Ehellyj>
>>     >
>>     > ORCID ID: orcid.org/0000-0002-3779-0603
>>     <http://orcid.org/0000-0002-3779-0603>
>>     >
>>     > <hellyj.vcf>_______________________________________________
>>     > CF-metadata mailing list
>>     > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>     > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
>>
>>     **********************
>>     "The contents of this message do not reflect any position of the
>>     U.S. Government or NOAA."
>>     **********************
>>     Roy Mendelssohn
>>     Supervisory Operations Research Analyst
>>     NOAA/NMFS
>>     Environmental Research Division
>>     Southwest Fisheries Science Center
>>     ***Note new street address***
>>     110 McAllister Way
>>     Santa Cruz, CA 95060
>>     Phone: (831)-420-3666
>>     Fax: (831) 420-3980
>>     e-mail: Roy.Mendelssohn at noaa.gov <mailto:Roy.Mendelssohn at noaa.gov>
>>     www: http://www.pfeg.noaa.gov/
>>
>>     "Old age and treachery will overcome youth and skill."
>>     "From those who have been given much, much will be expected"
>>     "the arc of the moral universe is long, but it bends toward
>>     justice" -MLK Jr.
>>
>>     _______________________________________________
>>     CF-metadata mailing list
>>     CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>     http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> <http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
>>
>>
>>
>>
>> _______________________________________________
>> 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 @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170317/2f23924e/attachment-0001.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/20170317/2f23924e/attachment-0001.png>


More information about the CF-metadata mailing list