A few more cents:
1. Its more powerful for the client to know the projection transformation than
to know only the 2D lat/lon values. For that reason I always encourage
providers to include the projection info. When the client doesnt know what to
do with the projection info, having the 2D lat/lon info make the data useable
anyway, and for that reason i think the decision by CF to require the 2D
lat/lon is correct for archival files.
2. The CDM/TDS uses netcdf/CF as a way to transfer binary information in WCS and other web services. Adding two-dim lat/lon fields can triple (worst case) the size of the file. For that reason CDM/TDS allows the user to specify if they want 2D lat/lon fields or not. This makes the files not strictly CF compliant, but we leave it to the client to decide what tradeoff they want.
The point is that web service binary encoding is a use case likely not originally envisioned by the CF committee.
Steve Hankin wrote:
[with a small correction embedded in "**", because I know our community
will point it out if I don't]
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. For that reason **and because GIS clients will likely
require the projection parameters** 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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
