On 10/22/2010 6:13 PM, John Caron wrote:
On 10/22/2010 9:46 AM, Julia Collins wrote:
Hello,
Benno's comment provides a convenient entry point for me to describe a
recent problem.
On Fri, 22 Oct 2010, Benno Blumenthal wrote:
Note: if the time zone is omitted the default is UTC, and if both t
On 10/22/2010 9:46 AM, Julia Collins wrote:
Hello,
Benno's comment provides a convenient entry point for me to describe a
recent problem.
On Fri, 22 Oct 2010, Benno Blumenthal wrote:
Note: if the time zone is omitted the default is UTC, and if both time
and time zone are omitted the default is
I can't imagine this change having any traction for the coordinate variable of
time, as some of the answers show.
However, if one thinks about non-coordinate variables, standard_names of
local_time and sidereal_time seem arguably useful.
Even allowing for Roy's perfectly valid arguments agai
nates
Cheers, Roy.
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Julia Collins
Sent: 22 October 2010 16:46
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (timeas
Hello,
Benno's comment provides a convenient entry point for me to describe a
recent problem.
On Fri, 22 Oct 2010, Benno Blumenthal wrote:
Note: if the time zone is omitted the default is UTC, and if both time
and time zone are omitted the default is 00:00:00 UTC.
To clarify, this is the time
ly used on its own to indicate Zulu/UTC. Might be wrong
> though.)
>
> Cheers, Jon
>
> -Original Message-
> From: Lowry, Roy K [mailto:r...@bodc.ac.uk]
> Sent: 22 October 2010 09:06
> To: Jon Blower; Benno Blumenthal
> Cc: cf-metadata@cgd.ucar.edu
> Subject: R
y K [mailto:r...@bodc.ac.uk]
Sent: 22 October 2010 09:06
To: Jon Blower; Benno Blumenthal
Cc: cf-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] New standard names for satellite obs data (timeas
ISO strings)
Hi Jon,
Full ISO8601 does carry time zone expressed in hours relative to UT in the
syntax
ers, Roy.
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jon Blower
Sent: 21 October 2010 23:28
To: Benno Blumenthal
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (time as
Of Jon Blower
Sent: 21 October 2010 23:28
To: Benno Blumenthal
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (time as
ISO strings)
Hi Benno,
> No one I know beyond the age of four thinks Sep 2009 is ambiguous
Do you mean "beyond th
--Original Message-
From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf Of
Benno Blumenthal
Sent: 21 October 2010 21:44
To: Jon Blower
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (time as
ISO strings)
Hi Jon,
Sor
For many (most in my world, which is more observational) applications, the
information about the instrument orientations will not be absolute (most
instruments can't measure their orientation that way because they don't know
what the platform orientation is).
So not specifying whether it is abs
e, sorry). So I can see some implementation challenges in NetCDF.
>
> Cheers, Jon
>
>
> -Original Message-
> From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf
> Of Benno Blumenthal
> Sent: 21 October 2010 15:43
> To: Steve Hankin
> Cc:
Hi Jon,
Thanks for the helpful summary :) We have had similar issues with
handling data that represents time periods, and it'd certainly be good
to find some way to address that.
On 21/10/10 15:28, Jon Blower wrote:
> 1. Steve and Roy both asked (I think) why we can't have a more general
> notio
ailto:bennoblument...@gmail.com] On Behalf Of
Benno Blumenthal
Sent: 21 October 2010 15:43
To: Steve Hankin
Cc: Jon Blower; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (time as
ISO strings)
While expressing precision in CF is an interesting issue, in th
Nan Galbraith said the following on 10/20/2010 11:18 AM:
Is it implicit in the proposal that, if there is orientation
information only at the instrument level, it's absolute, but if
there's also platform orientation, they need to be considered
together?
My idea is that both orientations are abs
Evan,
Evan Manning said the following on 10/20/2010 5:40 PM:
I don't see any need for instrument zen& azi. These are angles to
the instrument as seen from the observed location, and they must be
equal to the angles for the platform on which the instrument is
mounted.
When we discussed initia
tCDF, but there is a maximum length for
> ISO8601 strings.)
>
> Hope this helps,
> Jon
>
> -Original Message-
> From: cf-metadata-boun...@cgd.ucar.edu
> [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K
> Sent: 20 October 2010 10:00
> T
John Caron said the following on 10/20/2010 8:35 AM:
I would be interested to hear what your reasons are to use this form vs
udunits (eg "secs since reference")?
Dear John and a few others who asked similar question,
We have a few data users who prefer ASCII format and we would like to
keep ou
endar has the same concepts of fields.)
Jon
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal
Sent: 20 October 2010 20:00
To: John Caron
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names f
Bodas-Salcedo, Alejandro" wrote:
> To: "Lowry, Roy K" , "Aleksandar Jelenak"
> ,
> 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 app
> 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
: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K
Sent: 20 October 2010 10:00
To: Ben Hetland; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
Dear All,
As others have said, I think this debate is
adata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On
Behalf Of Jon Blower [j.d.blo...@reading.ac.uk]
Sent: 20 October 2010 14:41
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
Hi all,
I haven't followed this debate closely, but I'
s, it's a pain to represent
variable length strings in NetCDF, but there is a maximum length for
ISO8601 strings.)
Hope this helps,
Jon
-----Original Message-----
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K
Sent: 20 October 2010 10:0
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 I
Aleksandar's more generic proposal seems very workable, and it
may be useful (or extensible) for in situ data like current meters,
as well as for remote sensing data. This could prevent a proliferation
of new names down the road.
Is it implicit in the proposal that, if there is orientation infor
Ben Hetland wrote:
> One may argue, though, that an option to output time values formatted as
> ISO8601 would be very useful in tools like 'ncdump'. In that case it
> should be optional as I believe the basic idea is to "dump" the internal
> values as directly as possible from how they are actuall
n
Sent: 20 October 2010 13:36
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
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
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 Unidata's
th for
ISO8601 strings.)
Hope this helps,
Jon
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K
Sent: 20 October 2010 10:00
To: Ben Hetland; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for sat
.
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron
Sent: 20 October 2010 13:36
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
On 10/19/2010 12:55 PM, Mike Grant wrote:
>
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 "seco
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 shoul
On 19.10.2010 20:55, Mike Grant wrote:
> Out of curiosity, why do you want to store time as strings?
I believe the motivation was mentioned as human readability?
> It's easy to create those strings from numerical values, and
> numerical values are easier to handle in code (and in netcdf-3,
> as
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland
Sent: 20 October 2010 09:14
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
On 19.10.2010 16:27, Seth McGinnis wrote:
> What about using 'date' for string-valued times? That wa
Jelenak; cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard names for satellite obs data
>
> Dear All,
>
> I'd just like to reinforce John's last point that the
> semantics of 'instrument' and 'platform' are becoming blurred
> in
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
] On Behalf Of Aleksandar Jelenak
Sent: 20 October 2010 01:33
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
Dear Evan,
Thanks for your suggestions.
Evan Manning wrote on 10/18/10 11:30 PM:
> The names below mix "satellite" and "ins
Cameron-smith, Philip wrote on 10/19/10 7:44 PM:
Sometimes these instruments are also flown on aircraft, so do we want
to hardwire 'satellite' into the standard_name?
Yes, that is the reason why I went with "instrument_".
It is a bit of a mouthful, but would 'remote_sensing_instrument_'
work?
-
>
>
>
>> -Original Message-
>> From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-
>> boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
>> Sent: Tuesday, October 19, 2010 6:40 AM
>> To
Dear Evan,
Thanks for your suggestions.
Evan Manning wrote on 10/18/10 11:30 PM:
The names below mix "satellite" and "instrument" differently than I'm
used to.
I started with "satellite_*" names but then wanted to generalize since
remote sensing instruments are not only carried on satellites
On Behalf Of Jonathan Gregory
> Sent: Tuesday, October 19, 2010 6:40 AM
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard names for satellite obs data
>
> Dear Evan et al.
>
> I agree with this:
> > instrument_zenith_angle
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 "seconds".
> Strings, being dimensionless, d
Dear Seth, Aleksandar
> I believe this is correct; a 'time' has to be a numeric value.
In CF, that's right. A quantity with a standard_name of time has to be in time
units according to udunits.
What is the reason for needing to use a string-valued time? Couldn't the
information be represented as
Dear Evan et al.
I agree with this:
> instrument_zenith_angle -> satellite_zenith_angle
> instrument_azimuth_angle -> satellite_azimuth_angle
> satellite_scan_angle -> satellite_view_angle
> And add:
> instrument_scan_angle
> The angle between the line of sight from an instrument and
I believe this is correct; a 'time' has to be a numeric value.
What about using 'date' for string-valued times? That was my homebrew solution
when I was considering a similar problem.
(Note that string data is a big pain to deal with in NetCDF-3, because you're
limited to fixed-length character
Dear Olivier,
Aleksandar Jelenak wrote on 10/19/10 7:58 AM:
Lauret Olivier wrote on 10/18/10 10:51 AM:
· Are you sure you need a standard name such as "time_label_iso8601"?
I mean: isn't it possible to use "time" standard name instead? (And
put somewhere that it is ISO 8601 compliant informatio
Dear Olivier,
Thanks for your comments.
Lauret Olivier wrote on 10/18/10 10:51 AM:
That sounds interesting because you are suggesting to introduce
different quantities whether they are collocated or not.
No, I proposed standard names only for data obtained by calculating mean
or standard devi
The names below mix "satellite" and "instrument" differently than I'm
used to. For AIRS we use satellite zenith & azimuth angles, since
it is the angle to the entire satellite, not just a single instrument.
We also have an instrument scan angle, along its own scan plan and
relative to its nominal
fferent collocation targets?
Thanks Aleksandar!
Best regards,
Olivier.
-Message d'origine-
De : cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu]
De la part de Aleksandar Jelenak
Envoyé : jeudi 7 octobre 2010 16:40
À : cf-metadata@cgd.ucar.edu
Obj
Dear all,
I am submitting 13 new standard names for acceptance in the official
list. I have tried to follow the convention's guidelines and used the
current standard names as examples.
The new names are developed to represent some common types of satellite
obs data. I welcome any suggestion on h
51 matches
Mail list logo
