Hi gary:
Thanks for your contributions. Below are some questions and comments:
>
> ----------------------------------------------------------------------------
>
> A first example is a 3-D temperature grid for an ocean model. (I'm just a
> programmer so the real-life applicability of the examples may be off. :)
> Suppose the grid is curvilinear with sigma levels, defined with dimensions
> (i, j, k). But for analysis or plotting the grid may need to be viewed over
> lat/lon and either sigma or depth for the height, where the lat, lon, sigma,
> and depth mappings are stored directly in the file as variables. Lat and lon
> depend upon the (j,k) coordinate, depth depends upon (i,j,k), sigma depends
> upon (i).
>
> * lat(j,k)
> * lon(j,k)
> * depth(i,j,k)
> * sigma(i)
>
> There are at least four coordinate systems which associate the manifold
> domain with an alternate base domain (using the wording Steve mentioned),
> including the identity coordinate system.
>
> (i,j,k) => (depth, lon, lat)
> (i,j,k) => (sigma, lon, lat)
> (i,j,k) => (i, lon, lat)
> (i,j,k) => (i,j,k)
>
> So to associate each alternate mapping with the temperature variable, each
> mapping is named in the temp variable's temp attribute (except for the
> identity since it's implicit):
>
> float temp(i, j, k);
> temp:temp = "depth-map sigma-map lat-lon-map";
>
> The mapping name refers to a global attribute which lists the coordinates of
> the system. I appended -map to the names for clarity; I'm not suggesting the
> convention require it.
>
> :depth-map = "depth lon lat";
> :sigma-map = "sigma lon lat";
> :lat-lon-map = "lon lat";
> :sigma = "sigma";
>
> float lat(j, k);
> float lon(j, k);
> float sigma(i);
> float depth(i,j,k);
> depth:depth = "sigma";
>
> Each coordinate name in a global map attribute refers to the variable which
> maps to the values of that coordinate. There is some important consistency
> here: a variable is always a mapping (from N-space to the 1-D range of the
> variable), and the global map attributes are always used to specify the
> components or range for a mapping, e.g., the coordinates of a coordinate
> system.
I would restate as: "a variable and a coord sys for the variable can both be
considered functions on (more or less) the same index domain". I just wanted to
check if you are saying more?
>
> Note that the lat-lon-map is independent of the i coordinate, in which case
> the i coordinate is added to the lat-lon-map as an identity mapping of the
> indices along i. E.g., point (1,1,1) of temp is at coordinate (1, -105.0,
> 40.1) in the lat-lon-map coordinate system, point (2,j,k) is at (2,
> lon(j,k), lat(j,k)).
>
> A user or application can deduce the coordinates on the depth grid of point
> (i,j,k) by calculating (depth(i,j,k), lon(j,k), lat(j,k)). Choosing
> sigma-map yields (sigma(i), lon(j,k), lat(j,k)).
>
> The sigma global map attribute indicates that it makes sense to plot depth
> along a sigma axis, using the values of the sigma variable as the axis
> coordinates. This is an example of the recursiveness allowed by the
> convention. The temp variable's temp attribute can be followed to the
> depth-map mapping, which points to the depth variable. But the depth
> variable itself has an alternate coordinate system, sigma, whose global map
> attribute refers directly to the sigma variable. Through this recursion an
> application could infer the availability of the sigma-map mapping without it
> being explicitly named in the temp attribute.
I dont understand what the point of the lat-lon map or the sigma-map coord
systems are. It seems like they are implied by the depth-map and the
sigma-map coord systems?
Also, the need for the identity coord function is not obvious. I would just
say that the lat-lon coord sys is not complete. I am also noticing that the
identity coord function doesnt really "assign a physical value", which is
my definition of a coord system. I acknowledge you might need it now and
then for ill-specified files, but I dont really think it deserves much of
a place in our conventions.
>
> Note that this example doesn't change much if some of the variables are
> dependent upon time. If the lat and lon variable mappings are static, the
> coordinate systems would look like below.
>
> dimensions:
> time (UNLIMITED);
> i = 10;
> j = 100;
> k = 100;
>
> variables:
>
> float time(time);
> float temp(time, i, j, k);
> temp:temp = "depth-map sigma-map lat-lon-map";
> float salinity(time, i, j, k);
> temp:temp = "depth-map sigma-map lat-lon-map";
> float density(time, i, j, k);
> temp:temp = "depth-map sigma-map lat-lon-map";
> float depth(time, i,j,k);
> depth:depth = "sigma";
> float lat(j, k);
> float lon(j, k);
> float sigma(i);
>
> :depth-map = "depth lon lat";
> :sigma-map = "sigma lon lat";
> :lat-lon-map = "lon lat";
> :sigma = "sigma";
> :time = "time";
>
> The time mapping attribute is essentially an encoding of the usual
> interpretation of 1-D coordinate variables. For backwards compatibility, the
> existence of a coordinate variable could imply this attribute. Since none of
> the alternate mappings for temp depend upon the time coordinate, time is
> looked up as its own mapping, and the time global attribute refers back to
> the time variable.
>
> The temp coordinate systems could also be named "more completely" as
> follows:
>
> :depth-map = "time depth lon lat";
> :sigma-map = "time sigma lon lat";
> :lat-lon-map = "time i lon lat";
>
> This is perhaps clearer and might be preferred by some users. The i
> component in the lat-lon-map does not refer to another variable or mapping,
> so it reverts to the identity mapping from the domain of the i coordinate.
> (The identity mapping is effectively the default coordinate system for a
> dimension.)
>
> Comments
>
> I thought about allowing the mapping names to refer directly to the
> variable's attributes rather a global attribute, but in my opinion it's
> better to make a mapping name unique for the whole file and avoid allowing
> conflicting uses of map names between variables. I also considered letting a
> mapping name refer directly to a variable name, so that these global
> attributes would be unnecessary.
>
> :sigma = "sigma";
> :time = "time";
>
> But that violates the orthogonality and consistency of mapping names always
> being global attributes. I think some confusion could be avoided by naming
> every mapping explicitly as a global attribute, even those mappings
> currently implied by the coordinate variable convention.
I think its important to have global specification with variable override.
Imagine you have a file with 150 variables in it, and you have to specify the
coord
sys for each individual variable. Now you have a ncdump output: gotta check
each one
to see if they are the same (barf) ! On the other hand, if you have three
variables
each with a different coord system, its more compact to specify at the variable
level.
>
> Lastly, there is nothing preventing an application from merging alternate
> mappings of a variable. The temperature mappings could be listed as follows:
>
> float temp(time, i, j, k);
> temp:temp = "time depth-map sigma-map lat-lon-map";
>
> :depth-map = "depth";
> :sigma-map = "sigma";
> :lat-lon-map = "lon lat";
> :sigma = "sigma";
> :time = "time";
>
> An application could assemble all possible combinations of mappings and
> their coordinates, and in any order, including:
>
> (time(time), i, j, k)
> (time(time), sigma(i), j, k)
> (time(time), depth(time,i,j,k), lat(j,k), lon(j,k))
> (lat(j,k), lon(j,k), i, time)
> (i, j, k, time(time), sigma(i), depth(time,i,j,k), lon(j,k), lat(j,k))
>
> The last mapping, consisting of the intersection of all of the possible
> coordinate systems, might be useful for a table. (A really, really, big
> table. :) The mappings which can be described with this convention are
> merely a superset of those possible with the proposed coordinates
> referential attribute, which essentially lists the independent variables of
> each alternate coordinate system for a variable. I'm merely suggesting an
> extension of the referential idea to allow naming specific sets of
> coordinates, so that each coordinate set can completely and more intuitively
> describe a base coordinate system, not just for one variable but for the
> whole file.
I really think this is the wrong way to go, but as I see that you basically
argue
against it below, I'll assume you agree. But by saying that you would allow it I
think you confuse whether you are listing coordinate systems or coordinate
functions (I think "independent variables" is not true). All your good examples
I think list coord systems.
>
> ----------------------------------------------------------------------------
>
> Examples
>
> Wire Coil
>
> Here's Steve's wire coil example using the above ideas. I added two
> coordinate systems for the wire temperature: the physical distance along the
> wire and the cartesian coordinates.
>
> dimensions:
> s = 100;
>
> variables:
> float temp(s); // temperature along spiral
> temp:temp = "distance-map cylinder-map cartesian-map"
> float rho(s); // distance from CCS center axis
> float theta(s); // CCS azimuth
> float z(s); // CCS height
> float distance(s);
> distance:units = "cm";
> float y(s);
> float x(s);
>
> // physical distance along wire
> :distance-map = "distance"
> // cylindrical coordinate system (CCS)
> :cylinder-map = "z rho theta";
> // Cartesian map
> :cartesian-map = "z y x";
this is good.
>
> Rectilinear Grid
>
> The simple coordinate variable case for a rectilinear grid
>
> float temp(lat,lon);
> float lat(lat);
> float lon(lon);
>
> becomes:
>
> float temp(time,lat,lon);
> temp:temp = "world-map";
> float lat(lat);
> float lon(lon);
> :world-map = "lon lat";
>
> The lat and lon dimensions could be renamed without affecting the
> association described. Since the lat and lon mappings are independent of
> each other in this case, this example could boil down to exactly the
> previous referential attribute examples, except the usual coordinate
> variable convention has been made explicit with a global map attribute:
>
> float temp(time,lat,lon);
> temp:temp = "lat lon";
> float lat(lat);
> float lon(lon);
> :lat = "lat";
> :lon = "lon";
>
> Comparisons to coordinates Attribute
>
> The temp mappings in the wire coil example can be replaced with their
> constituent coordinates (variables), similar to the Walker and Waring
> example and to Signell's independent variables:
>
> > double salt(n,k,j,i);
> > salt:long_name = "Salinity";
> > salt:units = "1";
> > salt:coordinates = "t cell_z cell_y cell_x cell_lat
>
> temp:temp = "distance z rho theta y x"
>
> An application can generate all possible combinations of the mappings,
> "factor out" (Russ' words) coordinates where possible and if desired, and
> allow a user to choose the ones which make most sense. However, using the
> global coordinate attribute allows the sensible mappings to be explicitly
> named once for a file and referred to directly in each variable, and the
> availability of "common" coordinate systems is more immediately evident to
> the user. Also, the first mapping in a variable's referential attribute can
> designate the default coordinate system.
>
> Also, I'd prefer using a global attribute over using variable attributes
> with the same name as the corresponding dimension. Several fields with the
> same "manifold" domain would each need attributes for each dimension,
> instead of naming a single mapping in a single variable attribute. A global
> map attribute would be unique for the whole file, whereas dimension
> attributes among different variables would be redundant and could
> contradict. Russ gave similar arguments and others in support of the global
> dimension attribute.
>
> >From John Caron's comments about Walker and Waring:
> >
> > One part of their example I disagree with is lumping all of the
> > coordinate functions together:
> > double salt(n,k,j,i);
> > salt:long_name = "Salinity";
> > salt:units = "1";
> > salt:coordinates = "t cell_z cell_y cell_x cell_lat
> > cell_lon";
> >
> > While there's nothing illegal about it, better is:
> > salt:coordinates_xy = "t cell_z cell_y cell_x";
> > salt:coordinates_latlon = "t cell_z cell_lat cell_lon";
> > emphasizing that you are specifying two coordinate systems.
>
> I would agree with John, but I'd suggest this construction:
>
> double salt(n,k,j,i);
> salt:long_name = "Salinity";
> salt:units = "1";
> salt:salt = "lat-lon-map cartesian-map";
>
> :lat-lon-map = "t cell_z cell_lat cell_lon";
> :cartesian-map = "t cell_z cell_y cell_x";
>
> The coordinate systems are explicit, and they only need to be specified once
> rather than for each variable.
your formulation would be acceptable; i'm not convinced that the temp:temp part
is worth the trouble; theres nothing to suggest such an attribute should point
to a coordinate system. The tradeoff is explicitness (eg an attribute
"coordinate")
vs avoiding "english-centricity".
also i dont really agree/understand the notion of "factoring out".
>
> Boundary Layers
>
> Russ' boundary layer example using referential attributes, converted to
> global map attributes:
>
> dimensions:
>
> bndlay = 5 ; // boundary layers
> lon = 93 ;
> lat = 65 ;
>
> variables:
>
> float RH_bndlay(bndlay, lat, lon) ;
> RH_bndlay:long_name = "relative humidity in boundary layer" ;
> RH_bndlay:units = "percent" ;
> RH_bndlay:RH_bndlay = "boundary-map";
>
> float bndlay_bot(bndlay) ;
> bndlay_bot:long_name = "bottom of layer" ;
> bndlay_bot:units = "hPa" ;
>
> float bndlay_top(bndlay) ;
> bndlay_top:long_name = "top of layer" ;
> bndlay_top:units = "hPa" ;
>
> :boundary-map = "bndlay_bot bndlay_top lat lon";
ive been toying with the idea of introducing a grouping syntax, like:
:boundary-map = "(bndlay_bot bndlay_top) lat lon";
but i havent yet thought it through.
>
> record Attribute
>
> The NUWG conventions suggest a record attribute for model grids.
>
> float u(record, z, x, y);
> u:record = "valtime, reftime";
>
> double valtime(record);
> valtime:long_name = "valid time of model";
> valtime:units = "minutes since (1993-1-1 00:00:00.0)";
>
> double reftime(record);
> reftime:long_name = "reference time of model";
> reftime:units = "minutes since (1993-1-1 00:00:00.0)";
>
> Using map attributes, the multiple time components become a global mapping,
> similar to Russ' example of a dimension attribute for time:
>
> 2. A global "dimension attribute":
>
> :time = "year day_of_year second_of_day";
>
> Following are the corresponding examples using global map attributes. The
> time mappings could be combined with lat/lon or other mappings for the other
> dimensions as needed.
>
> variables:
> float u (record, z, y, x);
> u:u = "model-time-map";
> float observed_temp (record, z, y, x);
> observed_temp:observed_temp
> "time-map model-time-map month-map";
> int year(record);
> int day_of_year(record);
> float second_of_day(record);
> char month(record,4);
>
> :time-map = "year day_of_year second_of_day";
> :model-time-map = "valtime reftime";
> :month-map = "year month";
this is a confusing example, partly because of the indirection
but once i parse it, i guess its straightforward:
(i'll eliminate the x,y,z dimensions):
we have two variables u(record) and observer_temp(record).
u has coordinate system model-time-map, and observed_temp
has coordinate systems model-time-map, time-map, and month-map.
it would be surprising (though certainly possible) that in a real file
u would not also have the other two time coords.
>
> Grid levels
>
> Here is an example based on the NUWG conventions for alternate grid level
> coordinates, p or vpt.
>
> float u(record, z, x, y);
> u:z = "vpt, p";
>
> Using the global map attributes:
>
> float u(record, z, x, y);
> u:u = "pres-grid-map vpt-grid-map";
> float p(record, z, x, y);
> u:u = "vpt-grid-map";
> float vpt(record, z, x, y);
> u:u = "pres-grid-map";
>
> :pres-grid-map = "p x y";
> :vpt-grid-map = "vpt x y";
>
> The default coordinate system for u would use pressure p for the height
> axis, but availability of vpt is evident.
actually, its explicit.
>
> ----------------------------------------------------------------------------
>
> Extensions
>
> Set Notation
>
> Looking to the future, the global mapping attribute could adopt some
> specialized syntax so that simple mappings could be included as a formula
> rather than a whole array of data. If the distance variable in the wiring
> example above is proportional to s, then distance-map could describe the
> mapping using set notation.
>
> :distance-map = "{ (s) : s*1.6 }"
this could be worth exploring. we'd need a syntax definition.
did i say we couldn't embed methods?
>
> Virtual Vector Variables
>
> Since the global map attribute essentially lists multiple components of an
> n-space range, it could also be interpreted as a vector. Perhaps call it a
> virtual vector variable:
>
> float u_wind (time);
> float v_wind (time);
> float w_wind (time);
>
> :wind = "u_wind v_wind w_wind"; // 3-D vectors over time
>
> The problem is how to clearly indicate wind as a virtual variable. Perhaps
> in a global vectors or variables attribute.
how about
:vector_<name> = "list of components";
eg
:vector_wind = "u_wind v_wind w_wind"; // 3-D vectors over time
although the question of what applications might do with tat info is unanswered.
>
> Sub-mapping
>
> It would be interesting to be able to specify mappings which map directly to
> the coordinates of dimensions in the file. Suppose we wanted to specify a
> subset of the ocean temperature grid in the first example. We could specify
> a coordinate system whose range maps a subset of the domain of the temp
> variable over (i,j,k). As one possibility, specify integer variables which
> map into i, j, and k, and a global mapping which uses a colon (':') to
> indicate that the coordinates map directly into the i, j, and k coordinates
> of temp. The same method could be used for specifying the path of a particle
> through the grid:
>
> dimensions:
> i = 10; // Whole grid
> j = 100;
> k = 100;
> i2 = 10; // Region of grid
> j2 = 20;
> k2 = 20;
>
> float temp (time, i, j, k);
> temp:temp = "subgrid-map particle-trace-map";
> float depth(time, i,j,k);
> depth:depth = "depth-estimate particle-trace-map";
> float lat(j, k);
> lat:lat = "particle-trace-map";
> float lon(j, k);
> lon:lon = "particle-trace-map";
>
> int a (i2, j2, k2);
> int b (i2, j2, k2);
> int c (i2, j2, k2);
>
> int particle_i (time);
> int particle_j (time);
> int particle_k (time);
>
> :subgrid-map = "a:i b:j c:k";
> :particle-trace-map = "particle_i:i particle_j:j particle_k:k";
>
> Using a "sub-mapping" implies a different domain for the variable's mapping.
> In the case of plotting the water temperature along the particle track, the
> user asks for temp over the particle-trace-map, which an application can
> directly expand to
>
> temp (particle_i(time), particle_j(time), particle_k(time))
>
> The particle's locations would be
>
> lat (particle_j(time), particle_k(time))
> lon (particle_j(time), particle_k(time))
> depth (time, particle_i(time), particle_j(time), particle_k(time))
>
> which in turn might be described by a "virtual vector":
>
> :particle_locn = "lat lon depth";
>
> If the sub-grid were sampled along each dimension independent of the other
> dimensions:
>
> int a (i2);
> int b (j2);
> int c (k2);
sorry, my eyeballs glazed over....
i'll try this example again later....
>
> Close
>
> I left out details, like the specific syntax of the referential attribute,
> and I'm concentrating specifically on describing coordinates systems and
> mappings. Other conventions could be added later, such as units, projection
> types, labelling of geographic coordinates so that applications can
> recognize them, orientation of coordinates (e.g. vertical vs horizontal),
> and so on.
>
> I've been working with netcdf since the beginning, especially with regards
> to visualization software (Zebra) which stores and interprets
> multi-dimensional data. Some netcdf conventions for describing these data
> and their geographic coordinates would be very helpful, so I wanted to
> contribute some ideas. If any of my reasoning is wrong, faulty, or unclear,
> please let me and/or the netcdf mailing list know. Thanks for taking time to
> check this out.
>
> ----------------------------------------------------------------------------
>
> Gary Granger
> July 12, 1997
i would be interested in examples from real life that you think a convention
should cover,
especially if not already listed in http://acd.ucar.edu/~caron/coordvar.html
Regards,
John.
