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-bounces at cgd.ucar.edu] On Behalf Of Seth McGinnis
Sent: 28 July 2016 22:18
To: cf-metadata at 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
On 7/28/16 1:50 PM, Jim Biard wrote:
> 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>. /
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Jul 29 2016 - 04:52:55 BST
