Hi Jonathan,
I think Bert's suggestion of attaching the grid_mapping to the auxiliary
coordinates is simpler than including both auxiliary coordinate variable
names and grid mapping names in the grid_mapping attribute. I can predict
that we won't agree on what's "easier" to interpret :-) But adding
auxiliary coordinate names to the grid_mapping attribute is a duplication
of information. 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. 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.
Brian
On Tue, Nov 28, 2006 at 04:19:17PM +0000, Jonathan Gregory wrote:
> Dear Bert
>
> I agree with you and Brian that we could allow the grid_mapping attribute to
> be attached to auxiliary coordinate variables. The reason why we didn't do that
> before is because it isn't really the property of any auxiliary coordinate
> variable, but belongs to a coordinate system composed of several auxiliary
> variables. However you have raised a problem with that, and that's is a simple
> solution. An alternative solution would be to change the grid_mapping attribute
> to a different format, something like this:
>
> float waterlevel(TIME,M,N);
> waterlevel:long_name = "water level" ;
> waterlevel:units = "M" ;
> waterlevel:standard_name = "sea_surface_height" ;
> waterlevel:positive = "up" ;
> waterlevel:coordinates = "z_lat z_lon zgrid_y_nl zgrid_x_nl zgrid_y_de zgrid_x_de";
> waterlevel:grid_mapping = "zgrid_x_nl: zgrid_y_nl: EPSG19914 zgrid_x_de: zgrid_y_de: EPSG16362";
> double zgrid_x_nl(M,N);
> zgrid_x_nl:long_name = "grid cell centres, x-coordinate, EPSG19914" ;
> zgrid_x_nl:units = "M" ;
> zgrid_x_nl:standard_name = "projection_x_coordinate" ;
> double zgrid_y_nl(M,N);
> zgrid_y_nl:long_name = "grid cell centres, y-coordinate, EPSG19914" ;
> zgrid_y_nl:units = "M" ;
> zgrid_y_nl:standard_name = "projection_y_coordinate" ;
> double zgrid_x_de(M,N);
> zgrid_x_de:long_name = "grid cell centres, x-coordinate, EPSG16362" ;
> zgrid_x_de:units = "M" ;
> zgrid_x_de:standard_name = "projection_x_coordinate" ;
> double zgrid_y_de(M,N);
> zgrid_y_de:long_name = "grid cell centres, y-coordinate, EPSG16362" ;
> zgrid_y_de:units = "M" ;
> zgrid_y_de:standard_name = "projection_y_coordinate" ;
>
> In this version, grid_mapping is still an attribute of the data variable, but
> now it has the form "auxcoord: [auxcoord: ...] grid_mapping [auxcoord: ...]"
> which indicates the set of auxiliary coordinates which belongs to each
> grid_mapping variable. I'd suggest that an advantage of this is that it
> wouldn't require looking in different places for the information. I based
> this syntax on cell_methods but of course others would be possible. What do
> you think?
>
> I assume that we should continue to support the current kind of grid_mapping
> in any case.
>
> > 2) let the reader search for compatible coordinates (dimensions match data)
> > based on standard_names.
>
> The reason we didn't do that is not only that it is more work, but that it
> might not give the right results. There might be auxiliary coordinates with
> a given dimension that applied to some data variables but not others, for
> example.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Nov 28 2006 - 13:55:52 GMT
