Hi Steve,
> From: Steve Hankin
> To: Bert Jagers
> Cc: cf-metadata at cgd.ucar.edu
> Sent: Tuesday, December 05, 2006 12:27 AM
> Subject: Re: [CF-metadata] curvilinear cartesian coordinates case
The above message contained the following:
> When we look at files that mix variables in XY with variables in XYZ
> we'll see some redundancy in the grid objects (or else complexity), so
> we may see the weight of the arguments shift back slightly.
Can you give an example? Are you referring to generic XYZ datasets without
independent horizontal and vertical dimensions or also XY variables like
water levels and XYZ variables like 3D velocity fields?
> To my eye John Caron's suggestion is the most elegant and natural of
> the three proposed. But as part of the cost/benefit discussion one
> needs to consider that as-is it is a departure from the CF 1.0
> specification -- the "grid_mapping" attribute has changed its meaning
> and is no longer attached to the dependent variables. Is this a big cost?
> There's little cost if no files have actually been created that use the
> current grid_mapping.
I think that shifting grid_mapping away from the dependent variables is a
good step. How to deal with legacy files is indeed an issue.
> However, John, isn't much of the apparent difference is just in the
> changing interpretation of names?
>
> CF 1.0 John's proposed
> grid_mapping ==> coordinateSystems
> grid_mapping_name ==> grid_mapping
>
> Doesn't John's proposal using the current CF 1.0 attribute names become:
>
> int Dutch_CoordSystem;
> Dutch_CoordSystem:coordinates = "dutch_x dutch_y";
> Dutch_CoordSystem:grid_mapping_name = "EPSG19914";
> int German_CoordSystem;
> German_CoordSystem:coordinates = "german_x german_y";
> Dutch_CoordSystem:grid_mapping_name = "EPSG16362";
> float velocity(time,layer,m,n);
> velocity:grid_mapping = "Dutch_CoordSystem German_CoordSystem" ;
> velocity:coordinates="lat lon"; // can also list 1D coordinate
> variables
> float dutch_x(m,n);
> float dutch_y(m,n);
> float german_x(m,n);
> float german_y(m,n);
>
> which is a relatively small extension of CF1.0 (and still elegant).
I think there are two fundamental differences here:
1) Now, the grid mapping refers to the coordinates. If there multiple grids
are included in the file (e.g. in case of grids of staggered grid points, or
multiple grid mosaics), this approach would require multiple grid mappings
whereas John's original approach would define multiple coordinate systems*
and one grid mapping. I agree with Jonathan's point of view that a grid
mapping should not refer to coordinate variables.
* In my previous mail, I distinguished: grids, coordinate systems and
coordinate transformations. I don't like the way in which the term
"coordinate system" is used in John's mail and on the coordinate system
object model web page that he refers to. I think that the proper name should
be a grid or mesh object: it refers to specific points of a more general
coordinate system as I see it.
A coordinate system (in my definition) refers to the general coordinate
space (e.g. spherical coordinates as opposed to cylindrical or cartesian
coordinates) and can be easily extended to include local coordinate spaces
in use for geography such as Mercator projections. Although coordinate
systems and coordinate transformations are fundamentally different from my
point of view, it may be difficult to effectively seperate one from the
other since most coordinate systems are defined by their coordinate
transformation to/from spherical coordinates.
2) The usage of EPSG19914 as a grid_mapping_name suggests that it is an
accepted grid_mapping_name. Although the European Petroleum Survey Group
maintains a comprehensive list of coordinate systems. There is as yet no
association with grid_mapping_names and CF.
Note: If we continue the discussion on this proposal we might want to add it
to the wiki page that Jonathan created:
http://cf-pcmdi.llnl.gov/trac/wiki/MultipleProjections
Best regards,
Bert
Received on Tue Dec 05 2006 - 00:57:14 GMT
