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
--
Scanned by iCritical.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
