Hi Jon,
Assuming I've understood your situation ...
First to restate the party line: The philosophy of CF has always been
that the coordinate systems be self-describing without the application
needing to know the specific algorithms used to calculate coordinates
(from the name of the projection and a list of parameters). This
approach has great merit. It shifts the burden of generating
coordinates from clients, who would need to know all projection types
(in a dynamically growing list), to the individual data provider, who
needs to know how to generate just the coordinates for the particular
coordinate system being used. Admittedly, there are some geometric
computations that are only possible through knowledge of the projection
parameters, and for that reason those parameters have been added over
the past 2-3 years to CF. GFDL's proposed "gridspec" additions to CF
actually find a way to include most of that geometry information in the
file without the need to know the projection parameters -- making the
file more self-describing, but again at the expense of effort to the
data provider. (Gridspec tooling can add a whole lot of additional
power, too -- support for generalized regridding, etc.)
It sounds like the situation that you face is that you are the lucky one
to receive files that contain implied coordinates and you have to serve
them as CF with explicit coordinates. That is a pain in the neck for
sure. On the other hand think of the bright side ;-) . The pain in
the neck lands only on you; not on every client who would access this
file. That seems like a good trade-off to promote broad
interoperability. (Would a GIS client understand a rotated pole
projection? It seems like a projection that might be known only by
numerical ocean modelers.)
2 cents - Steve
=======================
Jon Blower wrote:
Thanks for the confirmation Don. This seems very odd indeed - if the
source data don't contain the (real) lon and lat coordinates then it's
quite onerous (and quite pointless) to do so in a convenient fashion
(it would generally involve re-writing the headers, or using some long
and ugly NcML). Presumably there must have been a good reason for
including these coordinates?
Cheers, Jon
On Wed, Jun 17, 2009 at 3:52 PM, Don Murray<dmur...@unidata.ucar.edu> wrote:
John-
I believe for all grid_mappings that lat/lon are required even though the
grid mapping defines the transformations necessary. I think it is redundant
in all cases, not just for the rotated lat/lon.
Don
Jon Blower wrote:
Dear all,
We have some data that use a rotated pole grid. The CF convention for
describing this is here:
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#id2985006.
Are the 2D lon and lat variables in this example really necessary?
They would seem to be redundant as their values can be calculated from
rlon, rlat and the location of the new "north" pole.
Thanks, Jon
--
*************************************************************
Don Murray UCAR Unidata Program
dmur...@unidata.ucar.edu P.O. Box 3000
(303) 497-8628 Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
