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
>> _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 _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/20170317/2f23924e/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/20170317/2f23924e/attachment.png>
Received on Fri Mar 17 2017 - 08:24:46 GMT
