Thanks all - I can certainly see the convenience value in including
the lat/lon arrays, but it is frustrating that some tools will reject
a dataset because of the absence of mandatory fields that they don't
need! Still, you have provided many valid arguments for retaining the
arrays and it's good to have confirmation that this information is
indeed redundant.
Just a word about GIS clients, picking up on one of Steve's comments -
many GIS clients would prefer to have the coordinate system properly
specified (as a CRS code or Well-Known Text) rather than by listing
the lat-lons exhaustively. (Another conversation could be started to
discuss the value of including these as optional attributes, since
most of the CF projections are commonly used in GIS.)
Cheers, Jon
On Wed, Jun 17, 2009 at 6:43 PM, John Caron<caron at unidata.ucar.edu> wrote:
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower at reading.ac.uk
http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm
Received on Wed Jun 17 2009 - 12:49:30 BST
