Dear Nan
I agree, the mid-point of time for climatological statistics is ill-defined.
It can be expressed in months only if months are interpreted as calendar
months. We have previously discussed allowing calendar_month (or something like
that) as a non-udunits unit of time to allow this. That would require a change
to the convention. Using months is not right, because of their precise
definition as a fixed (and inappropriate) length of time. udunits could not
be used to interpret calendar_months, since all udunits have a fixed length,
whereas a calendar_month is a variable interval of time.
However, I'm not sure that this is so important as to require a change to
the convention. Is the precise choice of the mid-point of time critical in
this use-case? It's the bounds which really matter usually for such stats,
and the time coord value is rather nominal. If that is so, it doesn't matter
much whether it's 15 or 15.5 days through the month, so long as it's the
right month e.g. for plotting it, or selecting the right value.
Best wishes
Jonathan
----- Forwarded message from Nan Galbraith <ngalbraith at whoi.edu> -----
> Date: Thu, 17 Sep 2015 09:54:49 -0400
> From: Nan Galbraith <ngalbraith at whoi.edu>
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Climatological Stats
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:38.0)
> Gecko/20100101 Thunderbird/38.2.0
>
> Hi Jim -
>
> The problem isn't human-readability, though. The problem is that when you
> generate a file that has, say, the mean temperature for each month,
> sometimes
> over a period of years, there are no 'days' in the process. Any data
> that represents
> February goes into the February bin, whether 28 or 29 days; although
> March is always
> 31 days long, its mid-point is a different number of 'days since'
> the beginning of
> the year.
>
> In the case of the file Ajay presented, time is a singleton, and its
> value represents
> the center point of the first 3 months of the years 1955-2012. That
> can't be accurately
> expressed as a number of days, only as months.
>
> Is there a trac ticket for climatology data? If not, do we need one?
>
> Cheers - Nan
>
> On 9/17/15 9:32 AM, Jim Biard wrote:
> >Nan,
> >
> >The problem is, udunits defines a month as having a specific
> >length of year/12 = 30.44 days, so if you use udunits to convert
> >to anything else, you won't end up where you think you will. The
> >better practice is to use days. It's not as "human readable", but
> >it's the only way to do proper conversions between time bases.
> >
> >Grace and peace,
> >
> >Jim
> >
> >On 9/17/15 9:06 AM, Nan Galbraith wrote:
> >>While it's true that 'month is not a proper unit of measure',
> >>climatologies do in fact use months, not days, in calculating
> >>mean values. Adhering to udunits/CF in this regard could make
> >>the dates less easily understood.
> >>
> >>Regards - Nan
> >>
> >>On 9/11/15 1:34 PM, Karl Taylor wrote:
> >>>Dear Ajay,
> >>>
> >>>Since "month" is not a proper unit of measure, convert your
> >>>times to days and use a unit "days since ...".
> >>>
> >>>Also, it is normally a bad idea to have your base time set to
> >>>a date before the switch from Julian to Gregorian calendar. I
> >>>suggest using a base time of "1955-01-01" (i.e., the beginning
> >>>of your climatological period).
> >>>
> >>>I think the cell_methods should be:
> >>>cell_methods="area: mean depth: mean time: mean within years
> >>>time: mean over years";
> >>>
> >>>The time bounds should be (expressed in date/time format):
> >>>
> >>>climatology_bounds = "1955-01-01", "2012-04-01"
> >>>
> >>>and you can choose your time coordinate value as you think
> >>>most appropriate, e.g.,
> >>>the middle of the season of the first year of the climatology, or
> >>>the beginning of the first month of the first year of the
> >>>climatology, or
> >>>the middle of the season of the middle year of the climatology, or
> >>>
> >>>???
> >>>
> >>>
> >>>Hope someone confirms this, as sometimes I make a mistakes.
> >>>
> >>>Karl
> >>>
> >>>
> >>>
> >>>
> >>>On 9/11/15 9:54 AM, Ajay Krishnan - NOAA Affiliate wrote:
> >>>>Dear CF members,
> >>>>
> >>>>I would like your input on the way climatological stats are
> >>>>being represented in a file that I am working on. I believe
> >>>>that I am not using the time and the climatological_bounds
> >>>>properly:
> >>>>
> >>>>Seasonal SST
> >>>>
> >>>>Average seasonal temperature (Jan-Mar) for 6 decades (1955-2012)
> >>>>
> >>>>dimensions:
> >>>>time=1;
> >>>>nv=2;
> >>>>variables:
> >>>>
> >>>>
> >>>>double time(time);
> >>>>time:climatology="climatology_bounds";
> >>>>time:units="months since 0000-01-01";
> >>>>double climatology_bounds(time,nv);
> >>>>
> >>>>
> >>>>double climatology_bounds(time,nv);
> >>>>
> >>>>climatology_bounds:comment=? This variable defines the
> >>>>bounds of the climatological time period for each time? ;
> >>>>
> >>>>float t_mn(time,lat,lon,depth);
> >>>>t_mn:standard_name: ?sea_water_temperature? ;
> >>>>
> >>>>t_mn:long_name: ?Average of all unflagged interpolated
> >>>>values at each standard depth level for
> >>>>sea_water_temperature in each grid-square which contain at
> >>>>least one measurement.? ;
> >>>>
> >>>>t_mn:cell_methods: ?area: mean depth: mean time: mean? ;
> >>>>
> >>>>
> >>>>data: // time coordinates translated to date/time format
> >>>>time= ?1.5? ;
> >>>>
> >>>>climatology_bounds=?0.0?, ?3.0? ;
> >>>>
> >>>>
> >>>>The CF examples are helpful but my case is different where
> >>>>in I have just 1-time co-ordinate in my file. In the above
> >>>>case, what is the best way to record time and climatology
> >>>>bounds?
> >>>>
> >>>>
> >>>>Thanks,
> >>>>
> >>>>Ajay
> >>>>
> >>>>
> >>
>
> --
> *******************************************************
> * Nan Galbraith Information Systems Specialist *
> * Upper Ocean Processes Group Mail Stop 29 *
> * Woods Hole Oceanographic Institution *
> * Woods Hole, MA 02543 (508) 289-2444 *
> *******************************************************
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Thu Sep 17 2015 - 09:43:40 BST
