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

Nan Galbraith ngalbraith at whoi.edu
Fri Mar 17 07:05:56 MDT 2017


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


-- 
*******************************************************
* Nan Galbraith        Information Systems Specialist *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                 (508) 289-2444 *
*******************************************************





More information about the CF-metadata mailing list