Hi John,
I like this proposal. It's a nice extension of what we started with the
grid mapping variables. I think creating objects to represent grids is a
good step forward. Jonathan has expressed doubts about this, e.g.,
On Wed, Nov 29, 2006 at 08:14:55AM +0000, Jonathan Gregory wrote:
> Dear Brian and Bert
> ....
> > 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 routinely create files that contain only grid data. A typical use of
these files is as input to an application that does regridding. Such an
application may, for example, take an input datafile at some resolution, an
input grid file at a different resolution, and produce an output datafile
at the resolution contained in the grid file.
Brian
On Thu, Nov 30, 2006 at 05:35:33PM -0700, John Caron wrote:
> try again, hopefully fixing some format probelms
>
>
>
> Jonathan Gregory wrote:
> >Dear Rich
> >
> >
> >>I also would vote for Bert's original suggestion of attaching the
> >>grid_mapping directly to
> >>the coordinates that use that mapping.
> >
> >Can you explain why that seems better to you than (my) alternative of
> >naming
> >2D projection coordinates in the grid_mapping variable instead of making
> >them
> >auxiliary coordinate variables? The reasons why I prefer this at present
> >are
> >that the grid_mapping attribute stays where it is, that it serves as a
> >single
> >place to find the information that defines the mappings, and that there is
> >no
> >redundancy. Perhaps other people have other ideas.
>
> I'd like to give a different slant on it.
>
> >From my POV, the problem is that there a concept "coordinate system"
> >floating around that doesnt currently have a representation in the netcdf
> >file. If I understand Bert's case, he has (at least) 2 coordinate systems
> >for his data variables. This actually comes up anytime you have both
> >projection x,y and lat,lon coordinates, for example.
>
> So going into abstraction, we want to have coordinate system "objects", and
> we want to be able to associate more than one of them with a data variable.
> A coordinate system consists of a list of coordinate variables (1D
> "coordinate variables" or "auxilary variables"), and "coordinate
> transforms" such as projections or vertical transforms. (Ive worked out
> this object model in more detail at
> http://www.unidata.ucar.edu/software/netcdf-java/reference/CSObjectModel.html. The CDM maps CF-1.0 into this object model.)
>
> Coming back to representation, one possibilty is to steal the same idea we
> used for "grid mapping variables", which is really just a container
> variable for projecction parameters. In the CDM, this is a "coordinate
> transform variable", ie a variable that defines a coordinate transform, in
> this case a projection. So we could also define a "coordinate system
> variable", which defines both its coordinates and the grid_mapping:
>
> int Dutch_CoordSystem;
> :coordinates = "dutch_x dutch_y";
> :grid_mapping = EPSG19914;
>
> int German_CoordSystem;
> :coordinates = "german_x german_y";
> :grid_mapping = EPSG16362;
>
> and the data variables point to them, instead of using coordinates
> attribute:
>
> float velocity_x(TIME,Layer,M,N);
> velocity_x:long_name = "velocity, x-component" ;
> velocity_x:units = "M/S" ;
> velocity_x:standard_name = "x_sea_water_velocity" ;
> velocity_x:coordinateSystems = "Dutch_CoordSystem Belgian_CoordSystem" ;
> _______________________________________________
> 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
Received on Thu Nov 30 2006 - 18:45:23 GMT
