NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The cf-satellite
mailing list is no longer active. The list archives are made available for historical reasons.
Hi All - on this topic alone, I would add that every data producer in the GHRSST family does exactly this… all GHRSST-compliant data sets use three dimensions, with time=1. As a server of the data, I can say that not once has a user complained either. As a producer of GHRSST compliant data, I can't fathom why anyone would have heartache about it. GHRSST still has a time variable of course, and we have found that including the time dimension in the specification has allowed for the production of some higher-level products that would not otherwise be possible. For example, if someone wanted to put a whole year of daily data into a single file, they could and still remain GHRSST-compliant. None of the operational data producers in GHRSST do this, but we've done it for some of the retrospective inter-comparison work. GHRSST uses the time dimension in its L2, L3, and L4 specification. Ken p.s. - GHRSST is Group for High Resolution SST, http://www.ghrsst.org. GHRSST Data Specification Version 2.0 is at: https://www.ghrsst.org/files/download.php?m=documents&f=110930142648-GDS20TechnicalSpecificationsv20.pdf On Oct 26, 2011, at 11:44 AM, Tom Rink wrote: > Another issue relates to defining a mechanism to provide a time-stamp for > a file, ie. time dimension length = 1. Many data providers will not subscribe > to the notion of a 3D variable (time,x,y) with time=1. I'm not agreeing or > disagreeing, but engineers associated with the GOES-R project said they > would not do this. So we have a Time(time) variable to hold the nominal > time of the image. [NOTE: The opinions expressed in this email are those of the author alone and do not necessarily reflect official NOAA, Department of Commerce, or US government policy.] Kenneth S. Casey, Ph.D. Technical Director NOAA National Oceanographic Data Center 1315 East-West HighWay Silver Spring MD 20190 USA +1 301-713-3272 x133 http://www.nodc.noaa.gov
cf-satellite
archives: