Charlie,
The way I have come to view coordinate variables vs auxiliary coordinate
variables based on discussions with this group is that "true" coordinate
variables should be considered as quite close to just that - abstract
mathematical axes. Certainly in the majority of cases where
spatio-temporal averaging is done (at least with grids) data producers
are not calculating time, lat, or lon averages to put in their time,
lat, and lon variables. They are selecting the same spatio-temporal
point relative to the origin of each time, lat, and lon cell (usually
the midpoint, but not always) and writing the values to the time, lat,
and lon coordinate variables. I'd say that qualifies as pretty abstract.
It is certainly independent of the data values.
This abstract quality is how I've understood the reason why it is not
OK, for example, to have missing_data or fill values in true coordinate
variables. They are not, strictly speaking, to be understood as
functions of input data.
The same is not true of auxiliary coordinate variables. It is fine for
them to be understood as functions of input data. They may act as
coordinates for other data variables, but they are themselves data
variables, even if it is only that they are the outputs of a coordinate
transformation.
Perhaps this understanding is way off base. I'd appreciate understanding
how the rest of the community understands the distinction between true
and auxiliary coordinates.
Grace and peace,
Jim
On 6/2/15 5:15 PM, Charlie Zender wrote:
> Thank you for your thoughts on this David, Karl, and Jim.
> David, I concur with you.
> Karl, rest assured we are talking about adding cell_methods to _both_
> the variable and its coordinate, not the coordinate instead of the
> variable.
> Jim, you seem to view coordinates as abstract mathematical axes while
> I prefer their geophysical meaning. With respect to this discussion
> I see time similarly to other coordinates like lat, lon, lev.
> For example, when NCO averages a spatiotemporal region I want users to
> know that the scalar (or size 1 array) values of time, lat, and lon
> values in the output represent averages over the original input region
> and cell_methods seems to be the natural way to do this.
> Since CF seems to allow cell_methods on coordinates, NCO will continue
> its current behavior. I hope the NERC CF checker starts to allow
> this behavior (the Decker/Schultz cfchecker always has).
>
> Best,
> Charlie
>
> p.s. thank you! to whomever fixed the archive URL issue
--
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/20150603/b8fcbb06/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/20150603/b8fcbb06/attachment-0001.png>
Received on Wed Jun 03 2015 - 06:44:31 BST
