[CF-metadata] Re: projections in CF

From: Brian Eaton <eaton>
Date: Tue, 18 Feb 2003 12:09:47 -0700

Hi Jonathan,

In your first example you use a variable named "mymapping" to contain the
mapping definition and claim that the method is less convenient to read
because you need to remember a name which has no meaning and find the
variable that it refers to someplace else in the ncdump output. I'm afraid
I have myself to blame since you were just following the example in which I
also used a meaningless name. But the point was that the variable name can
be anything, in fact if there's only one projection in the file there would
be no reason not to give the variable the name
"rotated_latitude_longitude".

Same point applies to your second example. "hadleymapping" and
"ncarmapping" don't help identify the projection. Those variables could
just as easily be named "rotated_latitude_longitude" and
"lamert_conformal_conic" respectively.

Given that informative names are used for the variables that contain the
map definition I still think it's easier to look at a single name which
describes a specific projection (i.e., a group of attributes which define
specific map parameters) and use it to recognize when multiple variables
share a mapping. You're right of course; there are matters of personal
preference involved in this. So then what criteria do we use to choose the
formulation for CF? It seems to me that the general software engineering
principle of never unnecessarily duplicating data applies here.

Your main objection (I think) to factoring out the projection is that it
causes difficulty when rearranging variables into different files. We've
established that this is no different than what must be done for the
associated coordinate variables, so a utility that can deal correctly with
the coorinates will posses the necessary functionality to identify
identical grid mappings.

I disagree with your assertion that factoring the coordinates is a problem
and that we only do it that way for space considerations. Factoring out
duplicated data is just good software engineering practice. Can you
imagine looking at an ncdump output and trying to verify that all 100
variables share the same coorinate if they each maintained their
coordinates in attribute values?

Brian

On Sun, Feb 16, 2003 at 09:38:59PM +0000, Jonathan Gregory wrote:
> Dear Brian
>
> Thanks for your posting. It could be that this discussion depends on personal
> preferences. You wrote
>
> > I'm not in favor of individual attributes unless the projection can be
> > factored out.
>
> so I'll address that first. Sorry I was sloppy in referring to the proposed
> method for defining projections as an attribute, when it is actually a
> variable with attributes.
>
> The current CF proposal has the advantage of showing the name of the mapping
> (rotated_latitude_longitude in this example). It has
>
> float T(lev,rlat,rlon);
> T:units="K";
> T:grid_mapping="rotated_latitude_longitude ",
> grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
> float precipitation(lev,rlat,rlon);
> T:units="kg m-2 s-1";
> T:grid_mapping="rotated_latitude_longitude ",
> grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
>
> whereas in the new proposal (modified because grid-mappings are not necessarily
> projections) we would have
>
> char mymapping(p_len);
> mymapping:grid_mapping_type="rotated_latitude_longitude";
> mymapping:grid_north_pole_latitude=32.5;
> mymapping:grid_north_pole_longitude=170.0;
>
> ... other stuff ...
>
> float T(lev,rlat,rlon);
> T:units="K";
> T:grid_mapping="mymapping";
> float precipitation(lev,rlat,rlon);
> T:units="kg m-2 s-1";
> T:grid_mapping="mymapping";
>
> I find the latter less convenient to read, actually. Whereas in the former
> case, when I am looking at the data variable I have the mapping right in front
> of me, in the latter I have to remember its name while looking somewhere else
> in the CDL file to find out what it is. The name itself may not tell me any-
> thing about the projection, especially if it has been generated automatically.
>
> If the mappings of two variables are not the same, because they come from
> different models, for instance, again I think this factoring-out makes the
> CDL file less easy for a human to read. In the current CF proposal we have
>
> float Thadley(lev,rlat,rlon);
> Thadley:units="K";
> Thadley:institution="Hadley Centre";
> Thadley:grid_mapping="rotated_latitude_longitude ",
> grid_north_pole_latitude: 32.5 grid_north_pole_longitude: 170.";
> float Tncar(lev,rlat,rlon);
> Tncar:units="K";
> Tncar:institution="NCAR";
> Tncar:grid_mapping="lambert_conformal_conic ",
> "standard_parallel: 25.0 longitude_of_central_meridian: -95.0 ",
> "latitude_of_projection_origin: 25.0";
>
> and in the new proposal we have
>
> char hadleymapping(p_len);
> hadleymapping:grid_mapping_type="rotated_latitude_longitude";
> hadleymapping:grid_north_pole_latitude=32.5;
> hadleymapping:grid_north_pole_longitude=170.0;
> char ncarmapping(p_len);
> ncarmapping:grid_mapping_type="lambert_conformal_conic";
> ncarmapping:standard_parallel=25.0;
> ncarmapping:longitude_of_central_meridian=-95.0;
> ncarmapping:latitude_of_projection_origin=25.0;
>
> ... other stuff ...
>
> float Thadley(lev,rlat,rlon);
> Thadley:units="K";
> Thadley:institution="Hadley Centre";
> Thadley:grid_mapping="hadleymapping";
> float Tncar(lev,rlat,rlon);
> Tncar:units="K";
> Tncar:institution="NCAR";
> Tncar:grid_mapping="ncarmapping";
>
> Looking at the data variables of the new proposal, I have no information about
> what the mappings are except that they are probably different - even that is
> not certain because the definitions might be identical. In the present
> proposal, it is obvious that they really are different, and also I can see the
> definitions of the mappings in the same place in the file.
>
> You're right, the factoring-out is the same as with coordinate variables.
> Coordinate variables also have the consequent difficulty that you have to do
> some complicated programming to avoid writing duplicate coordinate variables to
> a file. I would say that is a *problem* with coordinate variables, rather than
> a feature of them that we want to use for grid mappings as well! In the case of
> coordinate variables, we do it that way because their space requirements are
> not trivial, but for grid mappings that is not an issue, as we have agreed.
>
> Regarding the other point, you write
>
> > 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.
>
> Point taken. To address this, I propose we provide a parser for the
> grid_mapping attribute, which decomposes it into key-value pairs, checks the
> keywords are valid (from its knowledge of the allowed mappings), checks the
> syntax for valid numbers and casts them into the right type. This should not
> be very hard. We have to do most of this for other kinds of CF attribute as
> well, so such a utility would have several uses.
>
> Cheers
>
> Jonathan
Received on Tue Feb 18 2003 - 12:09:47 GMT