Hi,
A difficult topic - I have some comments, only on the issue of
climatologies.
The CF standard does have a definition for climatology.
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#climatological-statistics
It uses the "climatology" attribute on a time coordinate variable to
state that the dimension is a climatology. It defines a means for
representing not only the coordinates i.e. the day, month, or season
where there is an average over a range of years (or other intervals). It
also has a method for saying what time range of original data that mean
represents. The examples there show the coordinate data defined as dates
within one year, and coordinate bounds saying that the climatological
average or other statistic was computed from data over a specified range
of dates. The "cell_methods" attribute on the data field gives even
more information about how the climatology was computed. The standard
allows for a way to represent other kinds of climatologies than yearly
ones: decadal averages, average in each hour of the day, etc.
I agree that unless the software implements this whole set of
attributes, it seems confusing to have these years on the coordinate
data, and Ferret software doesn't implement this part of the standard.
It seems to me that the standard as it's in the CF document could be
implemented in software without confusing the non-scientific end users,
but it would need some translation from what's in the datasets to
something that would be helpful to the casual user.
What Ferret does is to expand a bit on what the COARDS standard did (the
COARDS treatment of climatological time is outlined in the CF document
section I linked above). We recognize as a climatological axis any axis
whose coordinate data starts in year 0 or year 1 and has an extent of a
year or less. When data is visualized or listed, we do not list a year,
but show data only as "January", for instance, so our treatment of
climatologie is much the same as what Cathy is describing.
-Ansley
-------- Original Message --------
Subject: Re: [CF-metadata] CF calendars (was: problem with times in
PSD dataset)
Date: Mon, 10 Dec 2012 08:27:20 -0700
From: Cathy Smith (NOAA Affiliate) <[email protected]>
To: [email protected]
Jonathon
We have the issue that we store many long terms means (subdaily,daily,
monthly...). These long terms means have no "years" per se though the
rest of the date is an actual 'date'. We have been storing them as year
1 generally speaking (usually base 1-1-1) as we want to avoid using a
date within the date range of the dataset as we feel it confuses people.
So, in your proposal below, we couldn't use year 1 as the date because
we couldn't use 1-1-1., We also couldn't use 1800-1-1- and year 1
(negative dates). So, we would have to use some other year that didn't
look like a real year but was >1800. We could use something like 9999
would work but would lead to large values of the time variable and would
be hard to read. We could switch the base date for the LTM's (instead of
1800-1-1 use 9999-1-1) but I'm not sure that is a good idea to switch
base dates within a dataset. For us, the best thing for LTM's is to use
1-1-1 and year 1 as that is fairly easy to read and won't tend to
confuse people. CF doesn't have a standard and looking at the doc page,
the examples all show values that use a year from the range (something
that really does confuse some users in our experience). We could also
switch the default calendar and maybe that is sufficient but in my
experience only people who care about calendars would notice any
calendar attribute (e.g. not scientific users) so potentially that could
prove an issue. If we did switch, I could see that possibly being a
problem with applications as well, unless coded well.
I'm really not sure the best solution to this problem but I do think any
calender solution needs to take into account how to store climatological
dates.
Cathy
On 12/9/12 8:45 AM, Jonathan Gregory wrote:
> Dear Cecilia
>
> Thanks for your posting. Are we in agreement? I think that we are.
>
>> However, the current default is also problematic - reasons I see are:
>> 1) it does send a message to modelers who find the default unusable,
>> 2) because different calendar defaults are used on the modeling and
>> data side, current tools are limited to particular calendars,
>> affecting users,
>> and 3) the mixed Julian-Gregorian calendar is an ugly beast to peg as the
>> standard forevermore.
> I agree with these drawbacks. If CF only dealt with the real world, obviously
> the real-world calendar (mixed Julian-Gregorian) would be the default and only
> calendar it had to deal with. However, at its outset CF was for models, many
of
> which do not use this calendar, which was nonetheless chosen as the default
> because of udunits. I agree with you and others that providing such an
> inconvenient default is unsatisfactory in retrospect. But here we are!
>
>> it is a good idea to add another, strict Gregorian (error before 1582).
> Thanks for seeing it like that. Yes, perhaps we should define what I suggested
> as a new calendar: strict_gregorian, which is not allowed to have a ref date
> before 1582, or to use negative time coordinates, or to describe dates before
> 1582 (which would be impossible given the first two conditions). (Note, I am
> not personally the eponymous strict Gregory.)
>
> In that case, we could change the default in the next release from gregorian
> or standard to strict_gregorian. For software which is careful about versions,
> this would mean that dates in the default calendar before 1582 would give an
> error. This would be a safe failure, rather than a wrong answer.
>
>> Some data sets would be CF compliant only under particular versions of CF.
>> Is this the first time that a change to CF would have such an impact?
> In the sense of old data becoming invalid in a *later* version, yes I think
> it is. Of course new features always allow datasets which are invalid in an
> *earlier* version.
>
> In the failing cases, I think we agree that tools might offer the facility
>> to provide the calendar if none was found.
>> However, I imagine most tools would continue to assume the current default.
> Yes, I expect so. They would still be unsafe, if datasets have been wrongly
> coded with the default, but it would be no worse than now.
>
>> This does not seem so bad to me. The removal of the default solution should
>> not produce the nastier kinds of errors that you would get if you
>> changed the default.
> That's what I think, except that formally the above suggestion is a change to
> to the default - one which installs a fail-safe mechanism.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
>[email protected]
>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
----------------------------------------------
NOAA/ESRL PSD and CIRES CDC
303-497-6263
http://www.esrl.noaa.gov/psd/people/cathy.smith/
Emails about data/webpages may get quicker responses from emailing
[email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
