Gary Granger wrote:
>
> 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
I dont understand your use of "consistency" and "othogonality" here, but
I do agree with this statement:
> 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.
...
> > 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 guess my point is simple: mapping in grid space is trivial, and needs
no further conventions.
I do want to say what a coord sys. is, and carefully add as much
semantics as possible, and still be as general as possible. So I'm not
satisfied with saying there's absolutely no interpretation (ie meaning)
to a coordinate system.
>
> > 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. :)
Its a minor point, but im thinking of human readability, not file size.
>
> > > 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.
Lumping them all together would be a valid general coord system. I want
to also make a convention about a specialized coord sys (probably called
georeferencing) that would require saying exactly what the lat,lon and
altitude coords are (or something equivalent), and no more.
...
> > > 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
Im sorry, I dont understand what this is.
...
> > > 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...
thats a good point, to make sure that its in the variable name space.
