Hi Brian:
>
> Example:
>
> dimensions:
> c1 = 5;
> c2 = 6;
> c3 = 7;
> c4 = UNLIMITED;
> variables:
> float v(c4,c3,c2,c1);
> float c4(c4);
> float c3(c3,c2,c1);
> float c2(c2);
> float c1(c2,c1);
>
> The interpretation is that grid point (n,k,j,i) is located in some
> coordinate system at ( c4(n), c3(k,j,k), c2(j), c1(j,i) ). How the
> application actually determines where this position is in physical space is
> outside of the scope of this definition. But, e.g., if one were following
> the COARDS conventions then this would be determined by the using the units
> attribute conventions to determine the latitude, longitude, vertical, and
> time coordinates.
>
I agree that this definition works as long as the number of coord.
functions is <= the number of
dimensions.
>
> 2) There is no correspondence between a dimension and a coordinate in
> the case where coordinate variables are not 1D. So having them share a
> name is confusing.
>
> In the original definition of coordinate variables only the 1D case was
> considered and so the connection between a dimension and its corresponding
> coordinate was explicitly made. In the definition for the generalized
> coordinate variable it is pointed out that one can only make the
> correspondence for the special 1D case. One way to think about case where
> multiD coordinate variables are required is that the list of dimension
> names is being used to provide a list of coordinate names.
I think you are just saying that we can mitigate the confusion by
admitting that there is no correspondence in general between coord
functions and dimensions. But for someone looking at the file, not at
our conventions, it may still be misleading.
>
> 3) It is confusing to use the same names to refer to different coordinates
> in different coordinate systems.
>
> One rebuttal to this (provided by the proposer of the objection; thanks
> Steve) is that this is already true for the existing 1D coordinate
> variables. I would add that dimensions and variables have separate name
> spaces in netCDF implying that they are distinquishable by context. So we
> need to look at more than a name to avoid confusion (just like the parser
> of a CDL file must).
I didnt understand Steve's comment. If theres a one-to-one
correspondence between an index and a physical value, the index can be
identified with the coordinate without confusion. Is there a
counter-example? Of course we can keep our name spaces seperate in our
heads as well as in our compilers, but it could be an extra cognitive
burden.
>
> Summary:
>
> The current 1D coordinate variable convention is extremely useful and it
> covers the most common cases for describing a dependent variable's
> coordinates. I believe that the generalization to multidimensional
> coordinate variables for describing non-rectilinear coordinate systems
> retains the simplicity that made the original convention so successful. It
> does not address the issues of how to represent multiple coordinate systems
> for the same dependent variable nor how to represent the coordinates for a
> non-gridded collection of points. These will need to be resolved by new
> conventions on attributes. A compelling argument for coordinate variables
> is that no conventions on attributes are required and this should make them
> the natural choice for describing a variable's "primary" coordinate system.
>
I could live with your proposal; I hope we by embed it into a more
general convention.
