CF group:
I also would vote for Bert's original suggestion of attaching the
grid_mapping directly to
the coordinates that use that mapping.
I'm wondering how we move forward with this issue. We formed a
CF-Conventions Committee, and would it be time to have the commmitee
"convene" and decide if and how this should be implemented?
-Rich
On 11/28/06, Brian Eaton <eaton at ucar.edu> wrote:
> 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
Received on Thu Nov 30 2006 - 09:52:27 GMT
