1. The inner dimension is used. The rule is to look up the group tree
from innermost to root and choose the first one that is found
with a matchng name.
2. The fact that it is a dimension for a coordinate variable is not relevant
for the
choice.
However, note that this rule is only used by ncgen when disambiguating a
reference
in the CDL. The issue does not come up in the netcdf API because
you have to specifically supply the dimension id when defining the dimension
for a variable.
The rule is implemented in the ncgen parsing code. I can tell you specifically
where if you really want to know.
=Dennis Heimbigner
Unidata
Pedro Vicente wrote:
Hello everyone
I have a couple questions regarding the definition of dimensions in groups;
Consider the following CDL definition
netcdf in_grp {
dimensions:
lon=3;
variables:
//coordinate variable
float lon(lon);
data:
lon=1,2,3;
group: g1 {
dimensions:
lon=2;
variables:
float lon(lon);
float data(lon)
data:
lon=1,2;
} // end g1
} // end
There is a "lon" dimension/coordinate variable both at root and in group /g1 and they
have different dimensions, so variable named "data" has 2 dimensions with the same name
in scope,
and somehow has to choose one
Just wanted to confirm
1) Is this definition legal?
2) What is the algorithm that the netCDF library uses to distinguish between both dimensions in scope for the variable /g1/data?
3) Defining "lon" as a coordinate variable instead of just a dimension name, does this definition has any consequence for the way this is handled by the library for this case?
Can someone from Unidata please point me to the location in the source code
where this is handled?
thanks
Pedro
----------------------
Pedro Vicente
http://www.space-research.org/
------------------------------------------------------------------------
_______________________________________________
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
