Yes, I read the conventions section 4.4, including a few times while
preparing the question. Not too complicated, and helpful; it just
didn't address my problem, that I could see.
A point I found useful to consider is the idea that these are
secondary time parameters. When the netCDF file gets created, I
appreciate that it has a coordinate called time, which is presumably
the primary parameter. But in the original data (from which the netCDF
file is generated), it may or may not be the case that the 'primary
time' exists. (Maybe the system time becomes the primary time; maybe
some GPS sensor produces a timestamp that becomes primary time; maybe
something else will provide the key information from which time can be
established.) So is it the case that the Standard Name 'time' is
always assigned to the primary time? Or can 'time' be assigned to any
and all time parameters?
The two cases you outline seem pretty similar to me, but maybe I'm
missing something. As a general observation, the question 'how are you
going to use this' reflects an assumption that the only (or primary)
use of the netCDF files and the standard names is purposeful and
anticipatory. In fact, especially if you are dealing with observation
data, both can be strictly documentary; and of course the data can be
used in unintended ways. So it shouldn't matter how the data will be
used; I just want to know how to document what I have. (There are
reasons the different time parameters are not duplicates, which I
won't go into here; I just wanted to know how to label them, such that
generating a netCDF COARDS/CF file using those names won't bring the
wrath of CF down upon me.)
John
On Oct 23, 2008, at 5:32 PM, Nan Galbraith wrote:
>
>>> DateTime (ISO8601), Elapsed Mission Time (seconds), Sensor Time
>>> (ISO8601), Sensor Date (ISO8601), Day-of-Year
>>> Data Record:
>>> 2008-08-18T18:57:55.79, 8403.33, 12:12:11,2008-08-18,262
>>>
>
> There's a fairly complete (maybe too complete) discussion of CF time
> at http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.3/cf-conventions.html
> .
>
> John's raised a couple of separate questions, one on time storage and
> one or more on names for secondary time parameters.
>
> ISO8601 times/dates are not numeric fields, and would have to be
> stored as strings in NetCDF. It's easy enough to translate them into
> and out of the ISO format if you want to display them, plus you can
> actually *use* them if they've been converted to numbers in your
> NetCDF file.
>
> We're using ISO8601dates/times for global attributes in the oceansites
> project, the idea being that we can easily generate a catalog using
> the
> header fields. If you're talking about something like that, a
> metadata
> field rather than a variable that has time as one of its
> dimensions, that's
> a bit different. Maybe those attributes should have standard names,
> in
> the long run - there are not too many standard names for global
> attributes
> in CF yet.
>
> The 'elapsed mission time' and 'day of year' fields look like
> redundant
> parameters, since they can easily be gotten from the time word,
> although
> you'd need a 'mission start time' as a global parameter to get the
> elapsed
> time. The need for 'day of year' disappears as soon as you store
> your dates
> and times as CF time - it's so easily extracted.
>
> I agree that it would be useful to have a standard name to indicate a
> sensor time, but it would be a good idea to discuss the purpose a
> little
> more. Is it going to be used to indicate a clock drift, i.e. that
> the time
> in 'DateTime' (or, in CF, time) is an absolute, or at least a
> 'corrected'
> time, and this sensor_time is an indication of clock drift in an
> instrument?
> Or would it be used for data where there's a nominal time base and
> multiple
> sensors that actually have a separate, valid sample time? Does one
> standard
> name cover both of those cases?
> Cheers -
> Nan
>
>
>
>> ...
>>
>> Could the third and fourth fields (sensor date and time) be
>> combined and
>> encoded as a single time-since-ref variable? We could give it a new
>> standard
>> name e.g. sensor_time. I'd prefer that to adopting ISO8601 as a
>> completely
>> different way of encoding time in CF.
>>
>>
>>> The fifth field is at least a 'days since' format, though the
>>> reference point will have discontinuities every new year. I'm a
>>> little at sea as to whether this can be called 'time' or not.
>>>
>>
>> Yes, I think it would be a time - but what is it? Is just repeating
>> the
>> sensor date, in effect?
>>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Thu Oct 23 2008 - 22:04:24 BST
