Bert Jagers wrote:
> Dear all,
>
> Richard Gorman wrote:
>
>> On 23/11/2006 8:58 a.m., Jonathan Gregory wrote:
>>
>>> Right. I agree with that, in my alternative argument of today i.e. X
>>> and Y
>>> are useful to identify the horizontal coords. If X and Y are
>>> attached to
>>> 1D coordinate variables, then any 2D auxiliary coordinate variable
>>> which
>>> has those dimensions must be in the horizontal. That is a bit more
>>> work, but
>>> it seems more natural to me that X and Y should belong with 1D axes.
>>>
>> Agreed, identifying 1D coordinate variables is where the axis
>> attribute is useful. I'm not sure either way on the merits of axis
>> attributes for 2D coordinate variables.
>
>
> Is there really that much of a difference between 1D coordinate
> variables and 2D coordinate variables?
>
> Below I have modified Simon Wood's example and stripped it as much as
> possible of visible clues as to what each coordinate variable
> represents without confusing myself. Furthermore, I have changed from
> global latitude/longitude coordinates to a local coordinate system
> since everybody seems to agree that latitude and longitude can be
> determined from standard names and/or units. The document "NetCDF
> Climate and Forcast (CF) Metadata Conventions. Version 1.0, 28 October
> 2003" http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html
> (Chapter 5) recommends that latitude and longitude should always be
> specified using the coordinates attribute. However, for grids that are
> already curvilinear in a local cartesian coordinate system, I am not
> sure how to deal with both cartesian auxiliary coordinates and global
> latitude/longitude auxiliary coordinates. Furthermore I am not yet
> able to convert to latitude/longitude in our model output since our
> model does not require the characteristics of the cartesian projection
> to be known, so I am not able to specify latitude/longitude allways.
>
> case 1: 1D coordinate variables
>
> dimensions:
> time = 1;
> m = 5008; n = 5536;
>
> variables:
> // coordinate variables
> float time(time);
>
> float m(m);
> m:standard_name = "projection_x_coordinate";
> m:units = "km";
>
> float n(n);
> n:standard_name = "projection_y_coordinate";
> n:units = "km";
>
> // observation data
> float sst(time, n, m);
> sst:standard_name = "sea_surface_temperature";
> sst:coordinates = "n m";
> ...
>
> If I get naming conventions right, in this case m and n are coordinate
> variables. I'm not sure whether it is allowed to refer to them also as
> auxiliary coordinate variables using the coordinates attribute. That m
> corresponds to x coordinate and n corresponds to y coordinate can be
> determined from their standard_names and probably also from order of
> indices (COARDS convention) and the order of names in the coordinate
> attributes (CF convention).
CF does not require ordered dimensions, so one could not infer from that.
I dont think theres an order of names in coordinate attributes.
>
> case 2: 2D coordinate variables
>
> dimensions:
> time = 1;
> m = 5008; n = 5536;
>
> variables:
> // coordinate variables
> float time(time);
>
> float coord1(n, m);
> coord1:standard_name = "projection_x_coordinate";
> coord1:units = "km";
>
> float coord2(n, m);
> coord2:standard_name = "projection_y_coordinate";
> coord2:units = "km";
>
> // observation data
> float sst(time, n, m);
> sst:standard_name = "sea_surface_temperature";
> sst:coordinates = "coord2 coord1";
> ...
>
> In this case coord1 and coord2 are auxiliary coordinate variables.
> Normal coordinate variables are not available. That coord1 corresponds
> to x coordinate and coord2 corresponds to y coordinate can be
> determined from their standard_names and from the order of their names
> in the coordinate attributes (CF convention). As I see it, we have
> less clues here than in the case of 1D coordinate variables. So, why
> do we need to have an additional attribute axis = "X" in the 1D case
> (except for backward compatibility or compatibility among various
> conventions)?
I agree we dont need an axis attribute, the standard name is sufficient.
As an aside: the above files are valid CF, but not georeferencing,
because there is no lat/lon or projection info. So we cant display it
with a map overlay, combine it with other datasets, etc. Im sure its
useful for your purposes, but its not much use to anyone else. I think
it would be useful for CF to have an official notion of
"georeferencable" and specify the mandatory information to acheive that,
include it in the CF validator, etc. The problem is that a file can be
CF compliant but not useful, and its usually because the writer has made
a mistake or ommission, not because the info isnt available.
Received on Thu Nov 23 2006 - 10:45:06 GMT
