Russ Rew wrote:
>
> I think you've got rectilinear coordinate systems specified clearly, but
> there may be a problem in trying to use vector spaces and linear algebra
> terminology to define coordinate systems that aren't vector spaces.
> What are the basis vectors for a coordinate system based on (lat, lon,
> height)? They can't be (1, 0, 0), (0, 1, 0), and (0, 0, 1), in
> (radians, radians, meters) because in a vector space, every vector has a
> unique representation as a linear combination of the basis vectors, but
> (lat, lon, height) and (lat, lon+2*pi, height) represent the same
> element.
I beleive that the suitable modulo functions will make this into a
vector space. A similar question is whether spherical coords are indeed
a basis set for R3, which I believe is true; perhaps someone else can
answer definitively? If not, the whole description of coord systems as
basis vectors in a vector space is pretty specious.
>
> I would also like to consider the possibility of a more general notion
> of coordinates, for example treating climatology data so that `month'
> could be a dimension with a corresponding coordinate variable in a
> dataset such as:
>
> ...
> dimensions:
> lat = 19;
> lon = 36;
> month = 12;
> variables:
> float average_temperature(month, lat, lon);
> // coordinate variables
> float lat(lat);
> float lon(lon);
> // `month' doesn't currently qualify as a coordinate variable,
> char month(3,month) = "jan","feb","mar",...,"dec";
> ...
>
> Here `month' might be considered a _nominal_ coordinate variable, from a
> useful categorization of value types that Harvey Davies once pointed out:
Yes, I see that my use of vector spaces has some problems:
1) "Nominal" coordinates do not have addition or scaler
multiplication defined on them, so are not vectors. Basically I am
confusing "vector" with "tuple".
The most general way I can think of describing coordinates is
that they assign physical meaning to indices of a dimension. It might be
there are no algebraic operations that can be performed on them. So
the general definition of coordinate system would simply be a set of
coordinate functions from the index set to the "physical meaning" set,
both represented as tuples. The requirement of one to one mapping would
still hold.
2) I am very interested in a special kind of coordinate system,
namely a georeferencing one that maps to physical 3D space. We know
intuitively (?!) that that system is a vector space, and also a metric
space with the usual distance norm. So there's lots of algebraic
operations defined.
I want to single out this coordinate system for all kinds of special
treatment. So I would propose a convention to identify these coordinate
functions. eg:
dimensions:
npoints = 541;
variables:
lon(npoints);
lat(npoints);
geopotential(npoints);
geopotential:geo_coordinates = "lon lat lev";
This example uses the coordinate reference attribute convention.
There's no obvious exact analogue when using coordinate variables, to
distinguish the georeferencing coordinates from other coordinates. The
COORDS conventions have you look at the units of the coordinate
variables. The CSM group proposes to use the same method, with some
additional enumerations of possible vertical coordinates. The idea is
that if the units of the coordinate variable are "udunits convertible"
to "deg_east" or "deg_north" or "km above msl" or whatever, then you can
figure out which coord var is which.
I myself would prefer an unambiguous convention that just lists the
coordinate functions, even if they are coordinate variables. Thus, a
global attribute
:geo_coordinates = "lon, lat, lev";
would unambiguously state what the georeferencing coordinate system is.
A field attribute could also be used, and override a global attribute if
it existed.
3) Time is also a coordinate that requires special treatment, and as
far as I'm concerned should just be named:
:time_coordinate = "month";
Its interesting to note the similarity here with
http://www.unidata.ucar.edu/packages/netcdf/coords/0016.html
from Richard P. Signell (rsignell@xxxxxxxxxxxxxxxxxx) (Tue, 20 Oct 1992
13:41:38 EDT) in that he also insists on distinguishing the spatial and
time coordinates.
> As a small step toward moving closer to resolution of extending the
> netCDF conventions for coordinates, I have put together and will
> maintain a Web page linking to netcdfgroup postings relevant to this
> subject:
>
> http://www.unidata.ucar.edu/packages/netcdf/coords/
this was very useful to have access to these past threads, thanks.
> Current candidates for convention extensions include multidimensional
> coordinate variables and referential attributes. If neither of these
> turns out to be adequate for solving most problems of interest, I'm not
> sure we would be better off adopting both of them. It might be better
> to just document them more clearly so that datasets can use them,
> applications can support them, and future data users have a common
> understanding of of what these sorts of conventions mean and when they
> are useful.
Right now I'd say that coordinate variables satisfy the need to "keep
simple things simple" and coordinate reference attributes should be able
to describe any coordinate system (that can be described).
To elucidate that last remark, let me say something about hybrid
coordinates.
In this case,
Pressure(x,y,z) = a(z) * pref + b(z) * SurfacePressure(x,y)
Here, (x,y,z) are the indices, pref is a constant, SurfacePressure is a
2D field, and a and b are 1D fields. I use a(z) + b(z) as a perfectly
good coordinate variable for z, which I call the hybrid coordinate.
However, if I want the actual pressure (or equivalent height) at a point
(x,y,z), I need to calculate it using the above formula.
The point is, until we can embed functions (methods) in our netcdf
files, we cant really represent the above formula in the way it is
written. What we can do now, however, is to compute the field
Pressure(x,y,z) and store it in the netcdf file, and it becomes a
perfectly good coordinate function for the "altitude" coordinate of a
georeferencing coordinate system. So the cost is that we have to store a
3D field, when all the info is really available in 2 1D fields (a and b)
and 1 2D field (SurfacePressure).
Which is just a long example to say that we currently have only arrays
to represent functions.
