[CF-metadata] Re: projections in CF

From: Jonathan Gregory <jonathan.gregory>
Date: Mon, 10 Feb 2003 11:49:48 +0000

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.

(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.

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?

Best wishes

Jonathan
Received on Mon Feb 10 2003 - 04:49:48 GMT