[CF-metadata] Re: projections in CF

From: Brian Eaton <eaton>
Date: Tue, 11 Feb 2003 19:53:28 -0700

Hi Jonathan,

I think John and Russ's proposals would improve the usability of the
projection metadata in CF. I've made arguments in the text below.

On Mon, Feb 10, 2003 at 11:49:48AM +0000, Jonathan Gregory wrote:
> Dear John and Russ
>
> Thank you for your constructive attitude expressed here:
>
> > while we think these would be improvements, the current proposal is also
> > reasonable and we are anxious for a CF Convention that includes projections
> > soon.
>
> Brian and I have also been talking about these points.
>
> (1)
> > It would be better to specify the individual projection parameters as
> > individual attributes, rather than parsing strings. eg instead of
> >
> > float T(lev, y, x) ;
> > T:grid_mapping = "lambert_conformal_conic standard_parallel: 25.0 \n";
> > "longitude_of_central_meridian: -95.0 latitude_of_projection_origin: 25.0";
> >
> > use:
> >
> > float T(lev, y, x) ;
> > T:projectionName = "Lambert_Conformal_Conic";
> > T:Standard_Parallel="25.0";
> > T:Longitude_of_Central_Meridian="-95.0";
> > T:Latitude_of_Projection_Origin="25.0";
>
> I prefer having a single string because
>
> (a) it's the approach that we've adopted for other parts of CF such as the
> cell_methods and formula_terms, so maintains a consistent feel.
>
> (b) I think it is actually easier to use. Using the netCDF library, separate
> calls are needed to get and set each attribute. Manipulating a string to make
> several changes is less work (in many languages). Since we have other strings
> with this kind of syntax, we could/should provide subroutines to parse and
> reassemble them in languages in which it is not a single statement anyway, as
> utilities to support CF.
>

In John and Russ's example the individual parameters are all given as
string values. But that's not necessary. Those attributes could be
declared with real types. I would argue that reading inidividual
attributes directly into variables of the right type is easier than parsing
a string and converting string values to the proper type. But ease of use
is very subjective. It depends on what tools are at your fingertips.

Some advantages of individual attributes are:
1. flexibility -- you are not constrained to "key: value" pairs
2. they are typed -- this allows for some basic consistency checking

Subjectively I think the inidividual attributes are easier to read.

That said, I'm not in favor of individual attributes unless the projection
can be factored out.

> (2)
> > the common case is to replicate the projection specification on all variables;
> > it would be useful to be able to factor the projection out so it is specified
> > in only one place.
> >
> > it seems that software to subset a file already has to know to keep the coordinate variables and
> > other auxiliary information, so having to know to include projection info seems not much different.
>
> You're right, it is like coordinates. Nonetheless I would prefer to copy the
> information to every variable as currently proposed rather than factoring it
> out. Unlike coordinates, the space requirement of duplication is trivial. In
> this case there is no problem with lack of consistency in redundant information.
> If the projection is going to be changed, every variable will have to be
> processed anyway - it can't be done just by changing the factored-out attribute.
> On the other hand, if the projection metadata is wrong, fixing it in the same
> way on every instance of an attribute is not much more difficult to program
> than making a change in a single global attribute.
>
> The reason why I prefer the per-variable approach is that it makes it easier to
> split up files and assemble them from different sources if each variable carries
> its own metadata as far as possible. We've adopted this approach for all other
> attributes, and in general have deprecated global attributes.

The use of global attributes is not what's being proposed. The definition
of a specific projection would be contained in a variable. It would be
copied between files just as coordinate data is. Here is an example of a
factored out projection from John's original posting of 12 Nov 2002 (I
removed the "authority" attribute which we've decided against, changed
parameter values from string to real, reused the "grid_mapping" attribute
from CF, and used lowercase keywords as in CF):


   float T(lev, y, x) ;
     T:grid_mapping = "myProjName";
 
   char myProjName(p_len);
     myProjName:projection_name = "lambert_conformal_conic";
     myProjName:standard_parallel = 25.0 ;
     myProjName:longitude_of_central_meridian = -95.0 ;
     myProjName:latitude_of_projection_origin = 25.0 ;

> When you put together a file from two different sources, you will have to check
> whether their global transformation attributes have the same parameters.
> Identity of name is not sufficient. You might have Lambert_Conformal_Conic
> defined as (Standard_Parallel="25.0", Longitude_of_Central_Meridian="-95.0",
> Latitude_of_Projection_Origin="25.0") in one file and (Standard_Parallel="30.0",
> Longitude_of_Central_Meridian="-90.0", Latitude_of_Projection_Origin="20.0")
> in the other. If they are not the same, you have to rename at least one of them
> and change all the attributes which point to it. Since you need functionality
> to be able to compare two projections explicitly for this situation, why not
> always store per-variable projections and use this comparison function if you
> want to know which ones are the same?

Granted, copying variables between files is not easy. But you have the same
problems with the variable's coordinates.

As you point out comparing projections requires comparing all parameter
values in addition to the generic map name. But by factoring the
projection you give a name to the collection of attributes that defines a
specific projection. This doesn't matter to a machine parsing the
metadata, but I think it's very helpful for a person parsing an ncdump
output.

Brian
Received on Tue Feb 11 2003 - 19:53:28 GMT