[CF-metadata] Conventions for use of local solar time in gridded climate data

[Mitchelson, Joel]

Dear cf-metadata community,

We are working on new high resolution daily data sets of climate observations as part of the EUSTACE project ( http://www.eustaceproject.eu/ ), where fields such as surface air temperature are presented on global grids, and the sampling period for each grid box is from midnight to midnight in local solar time. In other words, the UTC time period of each grid box depends on longitude.

It seems that within CF conventions there might be several possible approaches to expressing this, though no specific example appears to be given in the conventions documents (versions 1.6 or 1.7). It would be desirable if our chosen method works nicely with as many existing software tools as possible; and uses established conventions if they exist.

Do conventions for this already exist?

If not, is the example CDL fragment below likely to be easy to use within many existing software tools for working with gridded fields of climate data, or might there be a more widely compatible method?

Many thanks in advance for your kind attention.

Joel.
--
Dr. Joel R. Mitchelson Observational Climate Data Software Specialist
Met Office Hadley Centre FitzRoy Road Exeter Devon EX1 3PB United Kingdom


--
// Example CDL fragment representing a single day of data in one NetCDF file.
// To represent more than one day multiple files could be used,
// or else a single file with the localtime dimension set to equal the number of days.

dimensions:
localtime = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;

variables:

float time(localtime, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;

float timebounds(localtime, longitude, bounds)

float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;

float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;

short tas(localtime, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "time" ;
tas:cell_methods = "time: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;

[Mitchelson, Joel]

Hi David,

Many thanks for the reply and for the positive feedback.

Yes the localtime dimension in the example CDL fragment is indeed an index into a sequence of lat-lon fields, with one field per solar day. Perhaps we could call this dimension solarday or something like that, if you think that would aid understanding?

Kind regards,
Joel.
--
From: David Hassell [mailto:***@ncas.ac.uk]
Sent: 28 July 2016 14:02
To: Mitchelson, Joel
Cc: cf-***@cgd.ucar.edu
Subject: Re: [CF-metadata] Conventions for use of local solar time in gridded climate data

Hello Joel,
This approach looks reasonable and CF-compliant to me, with "time" acting as a standard name in the cell method. I'm not sure what the 'localtime' dimension physically represents in this case, but I presume that it is there with size 1 because this is the first element of what will eventually be a time series of lat-lon fields?
All the best,
David
--
On 28 July 2016 at 12:58, Mitchelson, Joel <***@metoffice.gov.uk> wrote:
Dear cf-metadata community,

We are working on new high resolution daily data sets of climate observations as part of the EUSTACE project ( http://www.eustaceproject.eu/ ), where fields such as surface air temperature are presented on global grids, and the sampling period for each grid box is from midnight to midnight in local solar time. In other words, the UTC time period of each grid box depends on longitude.

It seems that within CF conventions there might be several possible approaches to expressing this, though no specific example appears to be given in the conventions documents (versions 1.6 or 1.7). It would be desirable if our chosen method works nicely with as many existing software tools as possible; and uses established conventions if they exist.

Do conventions for this already exist?

If not, is the example CDL fragment below likely to be easy to use within many existing software tools for working with gridded fields of climate data, or might there be a more widely compatible method?

Many thanks in advance for your kind attention.

Joel.
--
Dr. Joel R. Mitchelson  Observational Climate Data Software Specialist
Met Office Hadley Centre  FitzRoy Road  Exeter  Devon  EX1 3PB  United Kingdom
--
// Example CDL fragment representing a single day of data in one NetCDF file.
// To represent more than one day multiple files could be used,
// or else a single file with the localtime dimension set to equal the number of days.

dimensions:
    localtime = UNLIMITED ; // (1 currently)
    latitude = 720 ;
    longitude = 1440 ;
    bounds = 2 ;

variables:

    float time(localtime, longitude) ;
        time:units = "days since 1850-1-1 0:0:0" ;
        time:long_name = "Time (days)" ;
        time:standard_name = "time" ;
        time:bounds = "timebounds" ;
        time:calendar = "gregorian" ;

    float timebounds(localtime, longitude, bounds)

    float latitude(latitude) ;
        latitude:units = "degrees_north" ;
        latitude:long_name = "Latitude (deg)" ;
        latitude:standard_name = "latitude" ;

    float longitude(longitude) ;
        longitude:units = "degrees_east" ;
        longitude:long_name = "Longitude (deg)" ;
        longitude:standard_name = "longitude" ;

    short tas(localtime, latitude, longitude) ;
        tas:units = "K" ;
        tas:long_name = "Mean daily surface air temperature (K)" ;
        tas:standard_name = "air_temperature" ;
        tas:coordinates = "time" ;
        tas:cell_methods = "time: mean" ;
        tas:_FillValue = -32768s ;
        tas:scale_factor = 0.002 ;
        tas:add_offset = 273.15 ;

_______________________________________________
CF-metadata mailing list
CF-***@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
David Hassell
National Centre for Atmospheric Science
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243, Reading RG6 6BB
Tel: [phone]
http://www.met.reading.ac.uk/

[Jim Biard]

Joel,

There is no current standard for dealing with Local Solar Time (LST). I
assume that the time and timebounds values would be elapsed times
represented as fractions of days in quasi-UTC (the time at longitude 0).
This is valid netCDF, but I'm not at all sure what existing software
packages would do with it. Time is the one dimension that most software
packages assume to be 1-dimensional. Another possible approach would be
to have a notional 1-D time variable that would be set to noon UTC of
each day and rename your time variable in your example to localtime. It
would look something like this:

dimensions:
time = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;

variables:

float time(time) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;

float localtime(time, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;

float timebounds(time, longitude, bounds)

float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;

float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;

short tas(time, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "localtime" ;
tas:cell_methods = "localtime: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;

This provides an unambiguous, if notional, time dimension, and still
associates the local time values with the data values.

Grace and peace,

Jim

Post by Mitchelson, Joel
Dear cf-metadata community,
We are working on new high resolution daily data sets of climate observations as part of the EUSTACE project ( http://www.eustaceproject.eu/ ), where fields such as surface air temperature are presented on global grids, and the sampling period for each grid box is from midnight to midnight in local solar time. In other words, the UTC time period of each grid box depends on longitude.
It seems that within CF conventions there might be several possible approaches to expressing this, though no specific example appears to be given in the conventions documents (versions 1.6 or 1.7). It would be desirable if our chosen method works nicely with as many existing software tools as possible; and uses established conventions if they exist.
Do conventions for this already exist?
If not, is the example CDL fragment below likely to be easy to use within many existing software tools for working with gridded fields of climate data, or might there be a more widely compatible method?
Many thanks in advance for your kind attention.
Joel.
--
Dr. Joel R. Mitchelson Observational Climate Data Software Specialist
Met Office Hadley Centre FitzRoy Road Exeter Devon EX1 3PB United Kingdom
--
// Example CDL fragment representing a single day of data in one NetCDF file.
// To represent more than one day multiple files could be used,
// or else a single file with the localtime dimension set to equal the number of days.
localtime = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;
float time(localtime, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;
float timebounds(localtime, longitude, bounds)
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;
short tas(localtime, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "time" ;
tas:cell_methods = "time: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: ***@cicsnc.org <mailto:***@cicsnc.org>
o: [phone]

/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

[Jim Biard]

David,

That's a good point about the cell_methods. Perhaps an addition to the
cell_methods convention is in order.

In order to use the word time in a generic sense (as a standard name,
not a coordinate) the time dimension and coordinate names would have to
be named something else, perhaps 'notional_time' or 't'. We could then
use the comment option to write

cell_methods = "time: mean (over localtime bounds)" ;

but that is somewhat ambiguous.

We could propose an extension of the cell_methods attribute. What we
would like to formalize is the way in which the dimensions of localtime
are to be handled. We want to indicate that a mean over the time
boundaries of localtime was applied at each latitude and longitude, with
the longitude of localtime changing with the longitude of the data
variable. Ways we could write this that come to my mind are:

* localtime: mean
* localtime(time): mean
* time(localtime): mean
* localtime: mean over time at longitude
* localtime: mean (over time at longitude)

In every case, it's assumed that such a construction is only allowed
because localtime has a standard_name of 'time'. In the first case,
variation over the axes is assumed. In the second case and third cases,
the time aspect is explicitly declared, with the word 'time' interpreted
as a standard name, not as a dimension. The fourth and fifth cases
explicitly indicate the dimensional relationship, making it clear that
the mean is in the time dimension. Putting the parentheses around the
expression in the fifth case is to keep people from confusing this with
a climatology cell_methods.

I personally like the first, second, and third options the best.

Further thoughts, anyone?

Grace and peace,

Jim

Hello Joel, Jim,
I quite like the "float localtime(time, longitude)" construction.
There is an issue with the cell method, though - we can't have
'tas:cell_methods = "localtime: mean"' because localtime is a 2-d
auxiliary coordinate variable. Would 'tas:cell_methods = "time: mean"'
give the correct meaning? In this case "time" is acting as the name of
a coordinate variable (and therefore dimension).
All the best,
David
Joel,
There is no current standard for dealing with Local Solar Time
(LST). I assume that the time and timebounds values would be
elapsed times represented as fractions of days in quasi-UTC (the
time at longitude 0). This is valid netCDF, but I'm not at all
sure what existing software packages would do with it. Time is the
one dimension that most software packages assume to be
1-dimensional. Another possible approach would be to have a
notional 1-D time variable that would be set to noon UTC of each
day and rename your time variable in your example to localtime. It
time = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;
float time(time) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
float localtime(time, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;
float timebounds(time, longitude, bounds)
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;
short tas(time, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "localtime" ;
tas:cell_methods = "localtime: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;
This provides an unambiguous, if notional, time dimension, and
still associates the local time values with the data values.
Grace and peace,
Jim

Post by Mitchelson, Joel
Dear cf-metadata community,
We are working on new high resolution daily data sets of climate observations as part of the EUSTACE project (http://www.eustaceproject.eu/ ), where fields such as surface air temperature are presented on global grids, and the sampling period for each grid box is from midnight to midnight in local solar time. In other words, the UTC time period of each grid box depends on longitude.
It seems that within CF conventions there might be several possible approaches to expressing this, though no specific example appears to be given in the conventions documents (versions 1.6 or 1.7). It would be desirable if our chosen method works nicely with as many existing software tools as possible; and uses established conventions if they exist.
Do conventions for this already exist?
If not, is the example CDL fragment below likely to be easy to use within many existing software tools for working with gridded fields of climate data, or might there be a more widely compatible method?
Many thanks in advance for your kind attention.
Joel.
--
Dr. Joel R. Mitchelson Observational Climate Data Software Specialist
Met Office Hadley Centre FitzRoy Road Exeter Devon EX1 3PB United Kingdom
--
// Example CDL fragment representing a single day of data in one NetCDF file.
// To represent more than one day multiple files could be used,
// or else a single file with the localtime dimension set to equal the number of days.
localtime = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;
float time(localtime, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;
float timebounds(localtime, longitude, bounds)
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;
short tas(localtime, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "time" ;
tas:cell_methods = "time: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC
<http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information
<http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
o: [phone] <tel:%2B1%20828%20271%204900>
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and
geophysics <https://www.facebook.com/NOAANCEIoceangeo>
<https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
David Hassell
National Centre for Atmospheric Science
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243, Reading RG6 6BB
Tel: [phone]
http://www.met.reading.ac.uk/

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: ***@cicsnc.org <mailto:***@cicsnc.org>
o: [phone]

/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

[Seth McGinnis]

Hi David,

I have argued myself back and forth into a couple different positions,
but I have two major thoughts to contribute:

1) I think using the axis attribute may help.

2) Much of the observational data that's out there already is probably
actually doing the thing that you're describing and using local time
instead of UTC, and just not mentioning it. In particular, for datasets
based on station data, observations are typically taken during the local
day and are not synchronized to UTC. So if you took Jim's example and
left out the localtime variable, that's what a lot of the data out there
looks like. I find myself therefore inclined towards a solution of
that general form simply on the grounds that it's in line with end-user
expectations. You're doing what everyone is used to, just adding a
little extra information to be more explicit about what's happening with
time.

I agree with you that you can't re-use the units and standard_name for
time in the localtime variable, though. What if instead of localtime,
you just recorded the offset from UTC? Then you it's a pure function of
longitude and you can link the two through an ancillary_variables
attribute. We'd also need a new standard_name for the offset, of course.


So:

float time(time) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
time:bounds = "time_bnds" ;
time:axis = "T" ;
time:ancillary_variables = "local_offset" ;

float time_bnds(time, bounds) ;

float local_offset(longitude) ;
local_offset:units = "hours" ;
local_offset:long_name = "Local offset from UTC" ;
local_offset:standard_name = "local_time_offset" ;

Cheers,

--Seth

Post by Mitchelson, Joel
David,
That's a good point about the cell_methods. Perhaps an addition to the
cell_methods convention is in order.
In order to use the word time in a generic sense (as a standard name,
not a coordinate) the time dimension and coordinate names would have to
be named something else, perhaps 'notional_time' or 't'. We could then
use the comment option to write
cell_methods = "time: mean (over localtime bounds)" ;
but that is somewhat ambiguous.
We could propose an extension of the cell_methods attribute. What we
would like to formalize is the way in which the dimensions of localtime
are to be handled. We want to indicate that a mean over the time
boundaries of localtime was applied at each latitude and longitude, with
the longitude of localtime changing with the longitude of the data
* localtime: mean
* localtime(time): mean
* time(localtime): mean
* localtime: mean over time at longitude
* localtime: mean (over time at longitude)
In every case, it's assumed that such a construction is only allowed
because localtime has a standard_name of 'time'. In the first case,
variation over the axes is assumed. In the second case and third cases,
the time aspect is explicitly declared, with the word 'time' interpreted
as a standard name, not as a dimension. The fourth and fifth cases
explicitly indicate the dimensional relationship, making it clear that
the mean is in the time dimension. Putting the parentheses around the
expression in the fifth case is to keep people from confusing this with
a climatology cell_methods.
I personally like the first, second, and third options the best.
Further thoughts, anyone?
Grace and peace,
Jim

Hello Joel, Jim,
I quite like the "float localtime(time, longitude)" construction.
There is an issue with the cell method, though - we can't have
'tas:cell_methods = "localtime: mean"' because localtime is a 2-d
auxiliary coordinate variable. Would 'tas:cell_methods = "time: mean"'
give the correct meaning? In this case "time" is acting as the name of
a coordinate variable (and therefore dimension).
All the best,
David
Joel,
There is no current standard for dealing with Local Solar Time
(LST). I assume that the time and timebounds values would be
elapsed times represented as fractions of days in quasi-UTC (the
time at longitude 0). This is valid netCDF, but I'm not at all
sure what existing software packages would do with it. Time is the
one dimension that most software packages assume to be
1-dimensional. Another possible approach would be to have a
notional 1-D time variable that would be set to noon UTC of each
day and rename your time variable in your example to localtime. It
time = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;
float time(time) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
float localtime(time, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;
float timebounds(time, longitude, bounds)
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;
short tas(time, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "localtime" ;
tas:cell_methods = "localtime: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;
This provides an unambiguous, if notional, time dimension, and
still associates the local time values with the data values.
Grace and peace,
Jim

Post by Mitchelson, Joel
Dear cf-metadata community,
We are working on new high resolution daily data sets of climate observations as part of the EUSTACE project ( http://www.eustaceproject.eu/ ), where fields such as surface air temperature are presented on global grids, and the sampling period for each grid box is from midnight to midnight in local solar time. In other words, the UTC time period of each grid box depends on longitude.
It seems that within CF conventions there might be several possible approaches to expressing this, though no specific example appears to be given in the conventions documents (versions 1.6 or 1.7). It would be desirable if our chosen method works nicely with as many existing software tools as possible; and uses established conventions if they exist.
Do conventions for this already exist?
If not, is the example CDL fragment below likely to be easy to use within many existing software tools for working with gridded fields of climate data, or might there be a more widely compatible method?
Many thanks in advance for your kind attention.
Joel.
--
Dr. Joel R. Mitchelson Observational Climate Data Software Specialist
Met Office Hadley Centre FitzRoy Road Exeter Devon EX1 3PB United Kingdom
--
// Example CDL fragment representing a single day of data in one NetCDF file.
// To represent more than one day multiple files could be used,
// or else a single file with the localtime dimension set to equal the number of days.
localtime = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;
float time(localtime, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;
float timebounds(localtime, longitude, bounds)
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;
short tas(localtime, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "time" ;
tas:cell_methods = "time: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC
<http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information
<http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
o: [phone] <tel:%2B1%20828%20271%204900>
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and
geophysics <https://www.facebook.com/NOAANCEIoceangeo>
<https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
David Hassell
National Centre for Atmospheric Science
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243, Reading RG6 6BB
Tel: [phone]
http://www.met.reading.ac.uk/

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
o: [phone]
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[Mitchelson, Joel]

Hi Jim, David, Seth,

Many thanks indeed for all of the kind thought that's gone into this.

It seems the balance we are looking for is a solution that is close to end-user expectations (including working nicely with lots of existing software packages) whilst minimising the risk that the information can be misinterpreted.

The localtime(time, longitude) construct looks like a good fit to that, except for the issue that was raised regarding cell_methods.

If we used this construct together with the latest suggestion of:

short tas(time, latitude, longitude) ;
...
tas:coordinates = "localtime" ;
tas:cell_methods = "time: mean (over localtime bounds)" ;
...

Can we say if this use of cell_methods is:
A. Non-compliant with CF?
B. Compliant with CF but conveys the wrong meaning?
C. Compliant with CF but ambiguous in meaning?

If the answer is C then this is actually not a bad place to begin, as we could clarify the meaning both in our documentation and later (if CF convention authors were willing) in the CF convention document.

Seth would you still have a concern that users would find the above difficult to use and/or that it would break lots of software tools? As an alternative I can see that the use of time:ancillary_variables = "local_offset" is even closer to some established examples, but until the CF convention is updated I wonder if the interpretation of the time bounds for each grid box would actually be wrong as opposed to just ambiguous.

Further thoughts/advice much appreciated. Thanks for all the effort so far!

Kind regards,
Joel.

-----Original Message-----
From: CF-metadata [mailto:cf-metadata-***@cgd.ucar.edu] On Behalf Of Seth McGinnis
Sent: 28 July 2016 22:18
To: cf-***@cgd.ucar.edu
Subject: Re: [CF-metadata] Conventions for use of local solar time in gridded climate data

Hi David,

I have argued myself back and forth into a couple different positions, but I have two major thoughts to contribute:

1) I think using the axis attribute may help.

2) Much of the observational data that's out there already is probably actually doing the thing that you're describing and using local time instead of UTC, and just not mentioning it. In particular, for datasets based on station data, observations are typically taken during the local day and are not synchronized to UTC. So if you took Jim's example and left out the localtime variable, that's what a lot of the data out there looks like. I find myself therefore inclined towards a solution of that general form simply on the grounds that it's in line with end-user expectations. You're doing what everyone is used to, just adding a little extra information to be more explicit about what's happening with time.

I agree with you that you can't re-use the units and standard_name for time in the localtime variable, though. What if instead of localtime, you just recorded the offset from UTC? Then you it's a pure function of longitude and you can link the two through an ancillary_variables attribute. We'd also need a new standard_name for the offset, of course.


So:

float time(time) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
time:bounds = "time_bnds" ;
time:axis = "T" ;
time:ancillary_variables = "local_offset" ;

float time_bnds(time, bounds) ;

float local_offset(longitude) ;
local_offset:units = "hours" ;
local_offset:long_name = "Local offset from UTC" ;
local_offset:standard_name = "local_time_offset" ;

Cheers,

--Seth

Post by Mitchelson, Joel
David,
That's a good point about the cell_methods. Perhaps an addition to the
cell_methods convention is in order.
In order to use the word time in a generic sense (as a standard name,
not a coordinate) the time dimension and coordinate names would have
to be named something else, perhaps 'notional_time' or 't'. We could
then use the comment option to write
cell_methods = "time: mean (over localtime bounds)" ;
but that is somewhat ambiguous.
We could propose an extension of the cell_methods attribute. What we
would like to formalize is the way in which the dimensions of
localtime are to be handled. We want to indicate that a mean over the
time boundaries of localtime was applied at each latitude and
longitude, with the longitude of localtime changing with the longitude
* localtime: mean
* localtime(time): mean
* time(localtime): mean
* localtime: mean over time at longitude
* localtime: mean (over time at longitude)
In every case, it's assumed that such a construction is only allowed
because localtime has a standard_name of 'time'. In the first case,
variation over the axes is assumed. In the second case and third
cases, the time aspect is explicitly declared, with the word 'time'
interpreted as a standard name, not as a dimension. The fourth and
fifth cases explicitly indicate the dimensional relationship, making
it clear that the mean is in the time dimension. Putting the
parentheses around the expression in the fifth case is to keep people
from confusing this with a climatology cell_methods.
I personally like the first, second, and third options the best.
Further thoughts, anyone?
Grace and peace,
Jim

Hello Joel, Jim,
I quite like the "float localtime(time, longitude)" construction.
There is an issue with the cell method, though - we can't have
'tas:cell_methods = "localtime: mean"' because localtime is a 2-d
auxiliary coordinate variable. Would 'tas:cell_methods = "time: mean"'
give the correct meaning? In this case "time" is acting as the name
of a coordinate variable (and therefore dimension).
All the best,
David
Joel,
There is no current standard for dealing with Local Solar Time
(LST). I assume that the time and timebounds values would be
elapsed times represented as fractions of days in quasi-UTC (the
time at longitude 0). This is valid netCDF, but I'm not at all
sure what existing software packages would do with it. Time is the
one dimension that most software packages assume to be
1-dimensional. Another possible approach would be to have a
notional 1-D time variable that would be set to noon UTC of each
day and rename your time variable in your example to localtime. It
time = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;
float time(time) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
float localtime(time, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;
float timebounds(time, longitude, bounds)
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;
short tas(time, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "localtime" ;
tas:cell_methods = "localtime: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;
This provides an unambiguous, if notional, time dimension, and
still associates the local time values with the data values.
Grace and peace,
Jim

Post by Mitchelson, Joel
Dear cf-metadata community,
We are working on new high resolution daily data sets of climate observations as part of the EUSTACE project ( http://www.eustaceproject.eu/ ), where fields such as surface air temperature are presented on global grids, and the sampling period for each grid box is from midnight to midnight in local solar time. In other words, the UTC time period of each grid box depends on longitude.
It seems that within CF conventions there might be several possible approaches to expressing this, though no specific example appears to be given in the conventions documents (versions 1.6 or 1.7). It would be desirable if our chosen method works nicely with as many existing software tools as possible; and uses established conventions if they exist.
Do conventions for this already exist?
If not, is the example CDL fragment below likely to be easy to use within many existing software tools for working with gridded fields of climate data, or might there be a more widely compatible method?
Many thanks in advance for your kind attention.
Joel.
--
Dr. Joel R. Mitchelson Observational Climate Data Software Specialist
Met Office Hadley Centre FitzRoy Road Exeter Devon EX1 3PB
United Kingdom
--
// Example CDL fragment representing a single day of data in one NetCDF file.
// To represent more than one day multiple files could be used,
// or else a single file with the localtime dimension set to equal the number of days.
localtime = UNLIMITED ; // (1 currently)
latitude = 720 ;
longitude = 1440 ;
bounds = 2 ;
float time(localtime, longitude) ;
time:units = "days since 1850-1-1 0:0:0" ;
time:long_name = "Time (days)" ;
time:standard_name = "time" ;
time:bounds = "timebounds" ;
time:calendar = "gregorian" ;
float timebounds(localtime, longitude, bounds)
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:long_name = "Latitude (deg)" ;
latitude:standard_name = "latitude" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:long_name = "Longitude (deg)" ;
longitude:standard_name = "longitude" ;
short tas(localtime, latitude, longitude) ;
tas:units = "K" ;
tas:long_name = "Mean daily surface air temperature (K)" ;
tas:standard_name = "air_temperature" ;
tas:coordinates = "time" ;
tas:cell_methods = "time: mean" ;
tas:_FillValue = -32768s ;
tas:scale_factor = 0.002 ;
tas:add_offset = 273.15 ;
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC
<http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information
<http://ncdc.noaa.gov/>
/formerly NOAA's National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
o: [phone] <tel:%2B1%20828%20271%204900>
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and
geophysics <https://www.facebook.com/NOAANCEIoceangeo>
<https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
David Hassell
National Centre for Atmospheric Science Department of Meteorology,
University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB
Tel: [phone]
http://www.met.reading.ac.uk/

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC
<http://cicsnc.org/> North Carolina State University
<http://ncsu.edu/> NOAA National Centers for Environmental Information
<http://ncdc.noaa.gov/> /formerly NOAA's National Climatic Data
Center/
151 Patton Ave, Asheville, NC 28801
o: [phone]
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata