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<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
>>> *************************************************************
>>>
>>>
>>>
>>
>>
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Jun 17 2009 - 11:43:18 BST
