Across the ether fly the words of John Caron:
> >
> > 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?
I agree with your statement, and I should probably add something like it.
But I would also want to keep the points about consistency (orthogonality),
since there is an important distinction between the variable being the
"function", and the global attribute being the "grouping" of other
functions (variables) into the components of a coordinate system.
> 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?
float time(time);
float depth(time, i,j,k);
float temp(time, i, j, k);
temp:temp = "depth-map sigma-map lat-lon-map";
:depth-map = "depth lon lat";
:sigma-map = "sigma lon lat";
:lat-lon-map = "lon lat";
The lat-lon map specifies two coordinate variables, lon and lat, which
depend only upon dimensions j and k, so dimensions time and i implicitly
use the identity map. An application could then plot 'temp' over (time, i,
lon, lat). In other words, specifiying the lat-lon-map in 'temp'
explicitly indicates (time, i, lon, lat) as a coordinate system. The
depth-map and sigma-map both map i to different coordinates, and so they do
not imply the same coordinate system as the lat-lon-map.
Perhaps it would be useful to refer to other maps within a map:
:depth-map = "depth lat-lon-map";
:sigma-map = "sigma lat-lon-map";
:lat-lon-map = "lon lat";
I haven't thought about this possibility much; it could get prohibitively
confusing.
> 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.
Yes, I admit I am not using your definition of a coordinate system. My
intent is to be more general than that. Whether a coordinate variable is
"physical" or not is a separate issue to me, and in my estimate that notion
can and should be a separate quality (ie, attribute) of the variable. Brian
Eaton summed it up well:
Basically the interpretation of the coordinates is a separate issue
from how to identify which variables are the coordinates.
If I want an application to plot the temperature grid of a model in the
"grid space", I want to see the grid indices along each axis and not
physical coordinates. In other words, the dimension indices are mapped to
coordinates using an identity mapping. I agree that explicitly including
time and i in the map would be more complete (lat-lon-map = "time i lon
lat"), but as I comment later I didn't want to make that sort of
completeness a requirement.
> 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 e
> ach one
> to see if they are the same (barf) ! On the other hand, if you have three var
> iables
> each with a different coord system, its more compact to specify at the variab
> le level.
I wouldn't object to map attributes at the variable level, but I'd still
advocate for only allowing global. If each variable uses the same
coordinate system(s), then each need only reference the system(s) by name,
and each system can be defined consistently in one, easy-reference global
attribute. If each variable uses a different coordinate system, then that
coordinate system has to be specified somewhere, either in a variable
attribute or globally. So while compactness of size would not be an issue,
I agree that 'compactness of definition' would be compromised. However,
for a netcdf file with 150 variables each with a different coordinate
system... sounds to me like someone's just asking for trouble. :)
> > 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 intuitivel
> y
> > 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 a
> rgue
> against it below, I'll assume you agree. But by saying that you would allow i
> t I
> think you confuse whether you are listing coordinate systems or coordinate
> functions (I think "independent variables" is not true). All your good exampl
> es
> I think list coord systems.
I don't want to prohibit anyone from going either way. Someone concerned
about specifying only complete and natural coordinate systems in their
files could do so, and to me that's the significant part. Others, like
those in this discussion who have suggested it, could just list all
possible coordinate variables in a single mapping attribute and be done
with it.
> > >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 onc
> e
> > rather than for each variable.
>
> your formulation would be acceptable; i'm not convinced that the temp:temp pa
> rt
> is worth the trouble; theres nothing to suggest such an attribute should poin
> t
> to a coordinate system. The tradeoff is explicitness (eg an attribute "coordi
> nate")
> vs avoiding "english-centricity".
Yeah, I'm not too concerned about how the "coordinates" attribute gets
named or identified. Among the other pros, I like using the variable name
because it's an extension of the current coordinate variable convention: an
identifier in another name-space identical to the variable name is already
being used to indicate something special. I'm continuing the
tradition... :)
> > 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.
This NCL example would definitely take some further qualification for an
application to recognize the notion of a "boundary". But again, I think
this belongs in the realm of conventions for a coordinate variable's
attributes. For boundary-map as it is above, a table of values in that
coordinate system would be useful, for example:
Coordinates: Value:
bndlay_bot(bndlay) bndlay_top(bndlay) lat(lat,lon) lon(lat,lon) RH_bndlay
> > 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.
Perhaps. My intent was to show that there could be two separate time
coordinate systems: one which is only valid for observed data, and one for
model data which includes the valid time and reference time components.
Hence the variable 'u', which I took to be a model variable, does not have
coordinate systems for the observed time coordinates.
> > 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?
No one said we couldn't, and I'm sure lots of people are thinking about it.
I was just "wondering aloud" how such a mechanism might fit into the
scheme in the future.
> > 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 unanswer
> ed.
Perhaps there is a special case we can define for zero-dimensional
variables (which I agree with Harvey should be allowed) with a coordinate
attribute:
variables:
float wind;
wind:wind = "wind-vector";
:wind-vector = "u_wind v_wind w_wind";
This way the name appears in the variable name space, as it properly should
I think, where an application expects to see it and which identifies the
name as a variable. And all the conventional attributes (yet to be defined
:) can be associated with the vector variable as for other variables. I
think I like this idea the best so far...
Any variable with only a single value but needing a coordinate would
need to have one dimension:
dimensions:
point = 1;
variables:
int color(point);
color:color = "point";
float point(point);
:point="point";
> 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
No additions at the moment; thanks for assembling the examples though. And
thanks especially for your feedback.
gary
