Dear All,
I'd just like to reinforce John's last point that the semantics of 'instrument'
and 'platform' are becoming blurred in these discussions. From my perspective
as one who has to map to CF datasets I would prefer it if the semantics of
terms used in Standard Names had a universally
On 19.10.2010 16:27, Seth McGinnis wrote:
What about using 'date' for string-valued times? That was my homebrew
solution when I was considering a similar problem.
If I may butt in and contribute here, I usually prefer names like
'datetime' or 'timestamp' in cases like this, because 'date' is
Dear All,
Do we need to include any reference to instrument, platform or
satellite? It seems to me that the complexity arises because the
reference lines from which the angle is defined are different in
different applications. Wouldn't it be better to use zenith_angle and
scan_angle with respect
Dear All,
As others have said, I think this debate is irrelevant as there should be no
need for string timestamps in NetCDF. Providing a Standard Name only encourages
what I consider to be bad practice.
Cheers, Roy.
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
Dear all
I think there are two principles to be kept in mind for CF standard names:
* We should try to use words with consistent meanings, and not use synonyms.
* We should include enough information in each standard name for it to be
self-explanatory. In a given dataset, the standard name
On 10/19/2010 12:55 PM, Mike Grant wrote:
On 19/10/10 14:21, Aleksandar Jelenak wrote:
Actually, I don't think it is possible to use 'time' standard name in
such cases. If I correctly interpret CF rules for using standard names,
'time' data can be only in the physically-equivalent units to
Hi John,
ISO-8601 allows timestamps to any resolution from year to millisecond, so 2010,
2010-10, 2010-10-20 are all valid so the string can be any length from 4 to 27
(e.g. 2010-10-20T14:53:00.000Z-15), unless restricted through an 8601 profile
(as many communities do)
Cheers, Roy.
Dear Ben
I agree it would be very useful if ncdump could translate times into time
strings for readability. In the examples in the CF doc we usually show them
like that. ncdump would need to be able to do this with any of the CF
calendars. This has been proposed before, it maybe it is on
Count me in the group of people who are sorry you lost your bid to include
ISO-8601 time strings, John. I have voted on the ISO 8601 side myself
(although as I recall, more in the spirit of representing multiple times in a
single file).
I understand it raises complexity considerably to allow
Hi all -
One way in which they are different is precision. A value of x seconds
since y has no implied precision - typically in programs we take the
precision to be milliseconds, but there's nothing to suggest this in the
actual metadata (anyone who tries to populate a GUI from CF metadata
Hi Jon,
I prefer handling the precision issue through a format mask attribute. I
usually hit this problem in Oracle with the 'date' data type (in say column X),
whose format I control by also storing an Oracle date/time format string (say
in column Y). Formatted date/time to the appropriate
To summarize:
1) Use instrument_zenith_angle, instrument_azimuth_angle, and
instrument_scan_angle for precise, instrument-specific observation geometry.
2) Use platform_zenith_angle, platform_azimuth_angle, and
platform_view_angle for generic satellite (here generalized to platform)
Hi Jon,
Why do you see this as an issue of date-times as ISO strings in
particular? The same issues of precision are found in longitudes
expressed as a degrees-minutes-seconds string compared to a floating
point. Or indeed to a depth expressed as a decimal string of known
numbers of
Bodas-Salcedo, Alejandro alejandro.bo...@metoffice.gov.uk wrote:
To: Lowry, Roy K r...@bodc.ac.uk, Aleksandar Jelenak
aleksandar.jele...@noaa.gov, cf-metadata@cgd.ucar.edu
Do we need to include any reference to instrument, platform or
satellite? It seems to me that the complexity arises
Hi Jonathon and CF metadata list,
Summarising our discussions thus far we propose:
2 new Cell methods:
root_mean_square
mean_of_upper_decile
and these new standard names:
sea_surface_wave_height (common concept)
sea_surface_wave_mean_crest_period
sea_surface_wave_significant_wave_period
15 matches
Mail list logo
