Hi all,
At NCAR/RAF we have netCDF files with multiple time frequencies in the
same file:
dimensions:
Time = 18421;
Sps1 = 1; // samples per second
Sps25 = 25; // samples per second
...
variables:
int Time(Time);
float var1(Time, sps1);
float var2(Time, sps25);
...
This is not CF compliant and we are concerned that users will not know
to look
for the subsecond dimension and recognize it as time.
Reading your suggestion below, I can see us implementing another use for
the
attribute "coordinate_offset". I took a stab at the udunits compatible
"units" value.
Not quite sure how that would work...
dimensions:
Time = 18421;
Sps25 = 25;
variables:
int time(Time) ;
:standard_name = "time"
:units = "seconds since 2010-08-15 10:09:00 +0000" ;
...
int sps25(Sps25) ;
:standard_name = "coordinate_offset" ;
:ref_coordinate = "time" ;
:units = "1/25 seconds since time" ;
...
float var2(Time,sps25);
All of Tim's comments about how to implement the :coordinates attribute
apply here as well.
Regards,
Janine
--
Janine Aquino
NCAR/EOL/CDS& RAF
303-497-8691
On 2/3/11 12:18 PM, [email protected] wrote:
Hello All,
I would love to see a time coordinate offset. Another use could be
for rastered data, such as that generated by some scanning satellite
instruments, where the along-track time stamp and the across-track
time offsets can be separated. In these cases the time and time_offset
variables could have completely different indices:
dimensions:
i = 40000; // along-track index
j = 1000; // across-reack index
variables:
double time(i) ;
:standard_name = "time"
...
double delta_t(j) ;
:standard_name = "time_offset" ;
:ref_coordinate = "time" ;
...
double pixel(i,j)
on the assumption that pixel_time(i,j) = time(i) + delta_t(j). This
would be somewhat more efficient than the conventional:
dimensions:
i = 40000; // along-track index
j = 1000; // across-track index
variables:
double time(i,j) ;
:standard_name = "time"
...
double pixel(i,j)
for storage space and would be a natural use for a coordinate offset.
I'm not completely clear how any of the offset schemes should couple
the coordinate/coordinate_offset pair to the :coordinates attribute of
subsequent data variables, as both the data variable and coordinate
offset would refer upwards to the base coordinate. Should we:
a) trust the reading software to identify any associated offsets for
a coordinate variable? (What happens if there's more than one?)
b) add :coordinate_offsets attributes or similar to data variables,
listing all relevant coordinate offsets, in analogy to the
:coordinates attribute? (To avoid possible ambiguity/duplication,
should we then leave out the corresponding :coordinates entry, as
the offset :ref_coordinate attribute identifies this for us?)
c) where appropriate, include the coordinate offset, and not the base
coordinate, in the :coordinates attribute, as the reading software
can then work its way unambiguously up the chain of references?
(You could conceivably also have offsets of offsets of coordinates,
with delta_delta_t:ref_coordinate = "delta_t", and so on!)
d) something else?
Regards,
Tim.
--------------------------------------------------------------------
Tim Nightingale
RAL Space
STFC Rutherford Appleton Laboratory
Harwell Oxford
Didcot Phone: +44/0 1235 445914
OX11 0QX Fax: +44/0 1235 445848
United Kingdom Email: [email protected]
--------------------------------------------------------------------
On 03/02/2011 12:20, "Bentley, Philip"<[email protected]>
wrote:
Hi folks,
I wonder if there isn't a more generic pattern sitting behind these
proposals. On the assumption that people are likely to want to use
similar offsets for other coordinate variables - e.g. x_offset,
y_offset, z_offset, lat_offset, lon_offset, and so on - would there be
any merit in specifying the more general-purpose standard_name of
'coordinate_offset', which would then be used in association with a new
attribute called, say, 'base_coordinate' or 'ref_coordinate' (comparable
to Jonathan's proposed 'relative_to' attribute) which would define the
reference/datum coordinate variable?
Then, in CDL, we'd have something like...
variables:
double time(time) ;
:standard_name = "time" ;
...
double delta_t(time) ;
:standard_name = "coordinate_offset" ; # or just plain "offset" ?
:ref_coordinate = "time" ;
...
(In some cases, of course, the time coordinate might be a scalar
coordinate, in which case the dimensions of the above two variables
would be different).
Adopting an approach along these lines would seem to confer the
advantage of avoiding a proliferation of standard names of the form
'X_offset'. That said, however, there are probably some CF nuances that
I've not thought of :-)
Regards,
Phil
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of plieger
Sent: 03 February 2011 09:14
To: Jonathan Gregory
Cc: CF metadata
Subject: Re: [CF-metadata] MSG CPP standard name for
time_offset_of_observation / pixel_delta_time
Dear Jonathan,
Do you think the standard name alone is sufficient? Proposing a new
attribute is more work than proposing a standard_name,
since it means
amending the CF standard. I can see there could be value in a
relative_to attribute, but it might be an unnecessary
complexity. I wonder what you and others think.
The standard name alone is sufficient for our case. I agree
with you that we should not add unnecessary complexity to the
CF standard. I think we will use the standard name 'time_offset'.
Best regards,
Maarten
On 02/02/2011 05:15 PM, Jonathan Gregory wrote:
Dear Maarten
What you write about pixeltime as an aux coord var (y,x) and your
ncdump look sensible to me. I think that's all fine.
The standard_name time_offset (s) seems good to me. In the
long name
we can add an explanation that this variable deals with the time
offset for each pixel.
OK. So that is a definite proposal for a new standard name.
Do you think the standard name alone is sufficient? Proposing a new
attribute is more work than proposing a standard_name,
since it means
amending the CF standard. I can see there could be value in a
relative_to attribute, but it might be an unnecessary
complexity. I wonder what you and others think.
Best wishes
Jonathan
--
Maarten Plieger
KNMI, R&D Information and Observation Technology, De Bilt
(t) +31 30 2206330
_______________________________________________
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
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
