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
On 7/28/16 2:29 PM, David Hassell wrote:
> 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
>
> On 28 July 2016 at 18:18, Jim Biard <jbiard at cicsnc.org
> <mailto:jbiard at cicsnc.org>> wrote:
>
> 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
>
> On 7/28/16 7:58 AM, Mitchelson, Joel 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-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
> o: +1 828 271 4900 <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>
> information, and follow us on Twitter at _at_NOAANCEIclimate
> <https://twitter.com/NOAANCEIclimate> and _at_NOAANCEIocngeo
> <https://twitter.com/NOAANCEIocngeo>. /
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at 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: +44 118 378 5613
> 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160728/3a84faa9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160728/3a84faa9/attachment-0001.png>
Received on Thu Jul 28 2016 - 13:50:43 BST
