Hi Jonathan,
Thank you for your reply!
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.
>>> However, we could also think about defining a new convention specifically for
>>> this, for example with an attribute that explicitly said what could be added
>>> together e.g.
>>>
>>> float obs(scan,pixel); // data variable
>>> coordinates="pixeltime";
>>> double scan(scan); // time of scan start
>>> scan:units="seconds since 2011-1-31";
>>> scan:standard_name="time";
>>> double pixeltime(scan,pixel);
>>> pixeltime:units="seconds";
>>> pixeltime:standard_name="time_offset";
>>> pixeltime:relative_to="time";
>>>
>>> where the relative_to attribute says that pixeltime can be added to the var
>>> with name time. A scheme like this could support multiple offsets without
>>> confusion. However, we shouldn't add complexity we don't need to the standard.
>>> What do you think?
I think this is very good, and suits other purposes as well... The
"relative_to" attribute seams also clear to me.
I am not sure about the coordinates attribute of obs. In our case this
attribute would contain "pixeltime lat lon"? I am not even sure wether
the other variables need to know about pixeltime. It is just information
we want to store, like other variables.
For MSG-CPP we add 2D latitude(y, x) and longitude(y,x) fields. The
variable pixeltime(y, x) with standard name time_offset is in my opinion
from the same category, because the contents of these variables do not
change in time (they are static). Therefore they are independent of time
and can be stored once in a netcdf file, minimizing file size. Other
fields, like precip(time, y, x) are dependent of time. We would like to
keep pixeltime/time_offset relative to time. When a user wants the
absolute time of measurement for a pixel, he has to add the current time
he is using to the time_offset field, according to the relative_to
attribute.
What do you think? Did I understand you correctly? I made an sample
ncdump (see below).
Best whishes,
Maarten
PS, sample ncdump:
dimensions:
y = 3712 ;
x = 3712 ;
time = 4 ;
variables:
double y(y) ;
y:standard_name = "projection_y_coordinate" ;
y:units = "km" ;
y:long_name = "y coordinate of projection" ;
double x(x) ;
x:standard_name = "projection_x_coordinate" ;
x:units = "km" ;
x:long_name = "x coordinate of projection" ;
short lat(y, x) ;
lat:scale_factor = 0.01f ;
lat:offset = 0.f ;
lat:_FillValue = -9999s ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
lat:long_name = "latitude" ;
short lon(y, x) ;
lon:scale_factor = 0.01f ;
lon:offset = 0.f ;
lon:_FillValue = -9999s ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
lon:long_name = "longitude" ;
float pixeltime(y, x) ;
pixeltime:grid_mapping = "projection" ;
pixeltime:_FillValue = -1.000000f ;
pixeltime:long_name = "time of pixel observation relative to time" ;
pixeltime:units = "s" ;
pixeltime:standard_name = "time_offset" ;
pixeltime:coordinates = "lat lon"
pixeltime:relative_to="time" ;
double time(time) ;
time:units = "seconds since 1970-01-01 00:00:00" ;
time:standard_name = "time" ;
time:long_name = "time" ;
time:calendar = "none" ;
short precip(time, y, x) ;
precip:scale_factor = 2.77778e-09f ;
precip:offset = 0.f ;
precip:_FillValue = -1s ;
precip:standard_name = "lwe_precipitation_rate" ;
precip:units = "m s-1" ;
precip:long_name = "Liquid water equivalent of precipitation" ;
precip:grid_mapping = "projection" ;
precip:coordinates = "pixeltime lat lon"
... etc ...
On 01/31/2011 02:36 PM, Jonathan Gregory wrote:
> Dear Maarten
>
> On Mon, Jan 24, 2011 at 02:58:04PM +0100, plieger wrote:
>> I am wondering whether anyone might know a good name for per pixel time
>> offset in MSG data.
>>
>> A complete meteosat full disk scan takes 25 minutes, because the imager
>> scans the disk line by line. This means that each line of pixels is
>> observed at consecutive times. The first pixels have a time offset of
>> zero, while the last pixels are measured several minutes later.
>>
>> We would like to make this information available in a standard way. We
>> would like to define a 2D (x,y) variable field in which the time of
>> observation is stored for each pixel (relative to the start of the scan,
>> starting at zero).
>
> This kind of issue has come up more than once before and CF doesn't have a
> solution for it explicitly at the moment. The simplest thing to do would be
> what you suggest, to define a standard name for a time offset. You suggest
>
>> - pixel_delta_time (s)
>> - time_offset_of_observation (s)
>
> and I would suggest a more general time_offset (s), which could be used for
> more purposes (not scanned data, not observational). I can imagine that similar
> names might some time be needed for other coordinates e.g. longitude_offset.
> I think offsets are different geophysical quantities, because time and
> longitude have an absolute reference, whereas time_offset and longitude_offset
> do not.
>
> In this simple scheme, it would be assumed that a coordinate or auxiliary
> coordinate variable with standard name of time_offset could be added to a
> coord or aux coord var with standard name of time, I suppose. Would that work
> for you?
>
> However, we could also think about defining a new convention specifically for
> this, for example with an attribute that explicitly said what could be added
> together e.g.
>
> float obs(scan,pixel); // data variable
> coordinates="pixeltime";
> double scan(scan); // time of scan start
> scan:units="seconds since 2011-1-31";
> scan:standard_name="time";
> double pixeltime(scan,pixel);
> pixeltime:units="seconds";
> pixeltime:standard_name="time_offset";
> pixeltime:relative_to="time";
>
> where the relative_to attribute says that pixeltime can be added to the var
> with name time. A scheme like this could support multiple offsets without
> confusion. However, we shouldn't add complexity we don't need to the standard.
> What do you think?
>
> Best wishes
>
> Jonathan
>
--
Maarten Plieger
KNMI, R&D Information and Observation Technology, De Bilt
(t) +31 30 2206330
Received on Wed Feb 02 2011 - 03:44:27 GMT
