⇐ ⇒

[CF-metadata] curvilinear cartesian coordinates case

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 29 Nov 2006 08:14:55 +0000

Dear Brian and Bert

> But adding
> auxiliary coordinate names to the grid_mapping attribute is a duplication
> of information.
That's a good point.

> Of course we could decide *not* to put the projection
> coordinates in the "coordinates" attribute, and instead to only put them in
> the grid_mapping attribute.
I suppose there would be logic in that, which would resemble how we treat
formula_terms, wouldn't it? formula_terms is the only place we name the
"components" of coordinate variables. We do not put them in the coordinates
attribute, although they are rather like auxiliary coordinate variables.
Thus, we could make it optional to list projection coordinates in the
coordinates attribute if they are instead listed in an extended-format
grid_mapping attribute.

> But I still like Bert's original suggestion best. It seems quite natural to
> me to attach the grid_mapping directly to
> the coordinates that use that mapping -- even if it needs to be specified
> in two variables. This actually makes the description of the projection
> coordinates more self contained, rather than relying on some data variable
> to make the connection between the auxiliary coordinate variables and a
> grid_mapping variable.
Yes, I see that advantage too. However, you could equally argue that there
is no need for the association of the projection coordinates and the grid
mapping in the absence of a data variable. I don't like the repetition of the
grid_mapping attribute, but I agree that the projection coordinates and the
grid mapping belong together (as in my suggestion).

I'm not being deliberately awkward :-) - just exploring possibilities.

Digression: this is an instance of how we have generally developed conventions
by discussion. It is not obvious to me that trial implementations would help.
We have written examples of both schemes, and as humans we have no difficulty
in interpreting them. Hence programs could be written to interpret them. The
problem is sufficiently simple it seems unlikely we have made a fundamental
error. As you say, Brian, opinions about which is "easier" depend partly on
taste, rather than more objective criteria.

Best wishes

Jonathan
Received on Wed Nov 29 2006 - 01:14:55 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒