David,
The simplest units example is not entirely analogous, true. The data
consumer does need to be aware of possible pitfalls like the one you
mention, but if the data producer had a time bounds variable for his
annual averages, then it would be apparent to the data consumer that the
time spans for the producer's average and her average were different,
and she could produce an equivalent average by using the producer's time
span expressed in her calendar.
This sort of problem can arise any time there is a reference point
involved in the expression of a measurement and there is not a single
agreed-upon reference point. It could show up with temperature readings
in degrees Celsius if two different definitions of 0 deg C are used.
(Which can happen with historical data, since 0 deg C was once defined
as the melting point of water, and is now defined as 273.15 K, which
puts the melting point of water at -0.0001 deg C). If you have old
Celsius temperatures and want to compare them with new Celsius
temperatures, and if you are concerned about accuracy to better than
0.0001 deg C, then you have to convert one set into the basis of the
other set.
In every case, I think our job as data producers is to accurately tell
data consumers what we are giving them. What the data consumers do from
there is up to them. Some may do things right, some may do things wrong.
It's not possible to stop them from converting data if they want to or
need to. I think the point of the CF conventions is to help data
producers do their jobs, so that data consumers can better do theirs.
Grace and peace,
Jim
On 6/10/15 10:13 AM, David Hassell wrote:
Hello Jim,
I'm not entirely convinced by this argument. Here is a counter example
that I have in mind:
A conversion from kilograms to carats does not alter anything,
fundamentally, in the data values. However, a change of calendar by
the user could, for example, place a value in a different year than
intended by the producer, in which case annual averages computed by
the producer and the user would be different.
What do you think?
All the best,
David
---- Original message from Jim Biard (09AM 10 Jun 15)
Date: Wed, 10 Jun 2015 09:51:21 -0400
From: Jim Biard <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
Gecko/20100101 Thunderbird/31.7.0
Jonathan,
I didn't see your initial statement that you reference as enforcing
anything on data consumers, or I would have raised this earlier.
Let's think about this in a simpler context. If I, as a data
producer, store values in a data variable in units of kilograms and
designate it as such with the units attribute, that doesn't mean
every data consumer should feel like they must display the values as
kilograms. They are free to select the units they prefer and, as
long as they do the conversion correctly, that is completely fine.
In a more complex and somewhat analogous case, if I as a data
producer store my geographic coordinates in latitudes and
longitudes, and properly designate the units and the reference datum
that I used, data consumers can display my data using those
latitudes and longitudes, or they can display my data using a
projected coordinate system where they have converted my latitudes
and longitudes into X and Y values, or whatever else they choose
(and I hope that whatever else they might do is valid!). What I must
do as a data producer is accurately identify the geographic
Coordinate Reference System that is the basis for my geographic
coordinate values (and then make sure that my coordinate values are
correct if I started in some different CRS).
A properly formed time variable needs to have contents that are
metric (by that I mean that you can do differencing math with the
values), and if it contains real-world time observations it needs to
be anchored to a recognizable point in history. The system we have
in place using elapsed time values with a reference epoch does just
that.
The decision about how to represent the time values as timestamps
for display purposes should be left up to the data consumer. You may
have used a reference epoch expressed using the Proleptic Gregorian
calendar, but if I would rather express timestamps on my plots using
the Julian calendar, that's my business. Perhaps the discipline I am
working in has a convention of using Modified Julian Days, so I am
going to convert everything to days since 1858-11-17 00:00:00.
Whatever my choice of output form for times, it is crucial that I
know where the elapsed time values stored in my time variable are
anchored in history, and that is what we should be trying to make
clear with the units and calendar attributes (and any other
time-related attributes that might arise).
Grace and peace,
Jim
On 6/9/15 1:21 PM, Jonathan Gregory wrote:
Dear Jim
You wrote
The calendar only specifies how the reference date and time
are to be interpreted. It says nothing about either the time
variable values or the decoding that should be used to turn those
elapsed time values into dates and times. That choice is entirely up
to the data consumer. If a data producer started with a set of
Julian calendar dates and created a time variable, and a data user
prefers to use Proleptic Gregorian dates, there is no problem. One
is not more correct than the other.
You are right to point to this as a point of disagreement. I thought we had
discussed this earlier e.g. in
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2015/058224.html
I wrote
Clarify that in the CF convention the choice of "calendar" implies the
particular set of rules that is used to convert between date-times (YYYY-MM-DD
hh:mm:ss i.e. sets of six numbers) and time coordinates in units of elapsed
time since a reference time.
and I believe that this arose from an earlier discussion about this being a
CF-specific use of the term "calendar". Maybe I have misunderstood you now.
I think the data producer is the person who decides what the data means. If
the producer has Julian calendar timestamps and encodes with Julian rules
as a time coordinate variable, the data-user is wrong to decode them with
any other rules into timestamps or interpret them as being in any other
calendar. Why would that be a useful thing to do? I agree with your earlier
posting and email that there is a range of timestamps which refer to the same
points in time in the Gregorian and Julian calendars (long ago, before they
drifted apart) so for that range of dates it would not matter if the data-
user changed the calendar, since they're indistinguishable. But that is a
special case. If you come up to present, a given time-stamp refers to a
different instance in time in the Gregorian and Julian calendars, just like
it does between UTC and GPS calendars. For model calendars, it would be
nonsense for time coordinates encoded in the 360-day calendar to be decoded
in the proleptic Gregorian calendar, for example.
Perhaps we view time coordinates in different ways? I think the timestamps
are the primary information, and the time coordinates are an encoded version.
We do it like that for efficiency of storage, and convenience and robustness
of processing, since string-valued timestamps are relatively awkward. It has
also the great advantage that the encoded time coordinate is also an elapsed
time variable, so it can be used to check monotonicity and for calculations.
This is a common need, since time is a continuous coordinate.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
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: [email protected] <mailto:[email protected]>
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>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
David Hassell
National Centre for Atmospheric Science (NCAS)
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243,
Reading RG6 6BB, U.K.
Tel : +44 118 3785613
E-mail: [email protected]
--
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: [email protected] <mailto:[email protected]>
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>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
