[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<dmurray at 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
>> dmurray at unidata.ucar.edu P.O. Box 3000
>> (303) 497-8628 Boulder, CO 80307
>> http://www.unidata.ucar.edu/staff/donm
>> *************************************************************
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20090617/ccffd3e0/attachment-0002.html>
Received on Wed Jun 17 2009 - 09:31:57 BST
