Should the dataset object have a "dimensions" method?

[GoogleCodeExporter]

Shouldn't the dataset object have a "dimensions" method, to see the names of 
the dimensions for a particular variable?

If I open a dataset
nc=ncgeodataset(url)
I can see the size of a variable via:
nc.size(var)
but I can't see the names of the dimensions for that variable, which would be 
useful if I can't remember which dimensions I might want to extract data from.  

The nc.axes(var) is not the same thing -- it finds coordinate axes, not simple 
the variable names, and doesn't work on non-1D axes:

>> url = 'http://geoport.whoi.edu/thredds/dodsC/examples/bora_feb.nc';
>>  nc = ncgeodataset(url);

>> nc.axes('u')

ans = 

    'ocean_time'
    's_rho'
    []
    []

So we need a "nc.dimensions" or "nc.dims" that acts like this:

>> nc.dims('u') = 

    'ocean_time'
    's_rho'
    'eta_u'
    'xi_u'

Original issue reported on code.google.com by rsignell on 30 Jan 2012 at 1:06

[GoogleCodeExporter]

try using geovariable.axes(). That should return all of the coordinate variable 
names. We could add a method to get the actual netcdf dims, but would that be 
useful to matlab users?

Original comment by crosb...@gmail.com on 30 Jan 2012 at 2:40

[GoogleCodeExporter]

I don't want to go to the geovariable level for this.  I thought of this 
because I was just about to so a demo of NCTOOLBOX, using it just the way you 
would be used to working with NetCDF files.  Looking at size of variable, names 
of dimensions for the variables, and then selecting by indices.  

And yes, the dimension names will be useful.  Think of users who have been 
working with familiar netcdf files in which the dimension names are meaningful 
and recognized, but they can't remember what order they appear.  This will be a 
common use case for new users of NCTOOLBOX, I believe.   

Original comment by rsignell on 30 Jan 2012 at 3:00

[GoogleCodeExporter]

I guess i just don't understand why one would need to know a netcdf dimension 
name. You can't do anything with it from the toolbox. You're not talking about 
coordinate variables? I thought the whole point of the toolbox was to shield 
users from the lower level stuff, if they want to use the netcdf java stuff 
it's there: nc.netcdf

Original comment by crosb...@gmail.com on 30 Jan 2012 at 3:37

[GoogleCodeExporter]

Okay, let me try one more time to explain why you would want to know:  Say you 
are a ROMS user who has worked for years with ROMS.  You know that the 
dimension names lon_rho and lat_rho are lat and lon, so all you need to do is 
see them listed to know how you want to index into the array using syntax like
nc{'temp'}(1,end,1:2:end,1:2:end)

Yes, the usefulness of the CDM is to hide this, but not every NetCDF file will 
be CDM compliant. 

And finally, yes, it's there in nc.netcdf, but that's the whole friggin' file 
and it goes streaming by and then you have to scroll back up...  sucks!

Isn't this super easy?   If you still don't believe me, just trust me, because 
I'm right.  ;-)

Original comment by rsignell on 30 Jan 2012 at 3:47

[GoogleCodeExporter]

OK, now i understand. You are not talking about netcdf dimensions (the things 
you create so that you can add data to a netcdf file). You are talking about 
coordinate variables.

This is a change I can make because I'm already doing it. The current nc.axes 
you are using is on the ncdataset class, which doesnt really know anything 
about anything. But how do you want to order coordinate axes when they share a 
position?

Also just typing nc.netcdf prints the cdl, but nc.netcdf if the netcdf dataset 
object so you use nc.netcdf.othercommands like get netcdf dimensions.

But I would also like to stress that I think people should be learning to use 
the geovariable syntax and not rely on the {} old style syntax.

Original comment by crosb...@gmail.com on 30 Jan 2012 at 3:59

[GoogleCodeExporter]

No, actually, I really mean dimension names, not coordinate names.  I messed up 
the previous example by saying (lon_rho and lat_rho, when I really meant 
eta_rho and xi_rho)

Original comment by rsignell on 30 Jan 2012 at 4:09

[GoogleCodeExporter]

Hi Rich, it shouldn't be a problem to add nc.dimensions. If I get a free minute 
today I'll add it.

Original comment by bschlin...@gmail.com on 30 Jan 2012 at 4:22

[GoogleCodeExporter]

Awesome!  I should have asked you first!  ;-)

Original comment by rsignell on 30 Jan 2012 at 4:25

[GoogleCodeExporter]

I just didnt understand what you wanted. I've already got it done.

Original comment by crosb...@gmail.com on 30 Jan 2012 at 4:27

[GoogleCodeExporter]

Original comment by crosb...@gmail.com on 30 Jan 2012 at 4:36

• Changed state: Fixed

[GoogleCodeExporter]

Ha! I didn't get your message until after I added it. Alex. Sorry, but I 
removed your version; it relied on a well behaved toString method on a Java 
collection, which can be a bit unreliable. I also moved the dimension method 
from ncgeodataset into ncdataset, so that it's available all the 'dataset' 
classes.

Original comment by bschlin...@gmail.com on 30 Jan 2012 at 4:41

[GoogleCodeExporter]

And it works!!   Awesome.   Thanks!!

Original comment by rsignell on 30 Jan 2012 at 4:48

[GoogleCodeExporter]

Its ok your implementation was better and i miss typed something. Caught your 
changes when I went to move the method to ncdataset

Original comment by crosb...@gmail.com on 30 Jan 2012 at 4:50

[GoogleCodeExporter]

Original comment by crosb...@gmail.com on 30 Jan 2012 at 5:50

• Changed state: Verified