geosubset method fails for non-typical, but CF-compliant dimension ordering

[GoogleCodeExporter]

geosubset seems to be assuming a dimension order of lat,lon, and fails for 
lon,lat.   Here is a topography dataset written as topo[lat,lon] (works) and 
topo[lon,lat] fails.  Yet both are CF-compliant and plot fine in ToolsUI, 
ncWMS.  Should identify the lon and lat coordinates by netcdf java functions, 
not by ordering.  

url1='http://geoport.whoi.edu/thredds/dodsC/usgs/data0/bathy/geoid03.nc';
url2='http://geoport.whoi.edu/thredds/dodsC/usgs/data0/bathy/geoid03_flip.nc';
nc=ncgeodataset(url1);
tvar=nc.geovariable('topo');
help geosubset
s.lat=[41 46];
s.lon=[-71 -65];
sub=tvar.geosubset(s); %works
nc=ncgeodataset(url2);
tvar=nc.geovariable('topo');
sub=tvar.geosubset(s); %fails

Original issue reported on code.google.com by rsignell on 17 Nov 2011 at 6:06

[GoogleCodeExporter]

I think its more complicated than that, but yet it is a known issue that hasn't 
been corrected yet. May already be an open issue here.

Original comment by crosb...@gmail.com on 17 Nov 2011 at 6:27

[GoogleCodeExporter]

Original comment by crosb...@gmail.com on 19 Dec 2011 at 6:14

• Changed state: Started

[GoogleCodeExporter]

I've made some changes to geosubset. They work for the dataset above, but will 
need to be tested for the various arrangements of time/lat/lon, z/lat/lon, 
time/z/lat/lon including the 2-d lat/lon as well as the 1-d lat/lon of 
different lengths.

Original comment by crosb...@gmail.com on 20 Dec 2011 at 3:38

[GoogleCodeExporter]

We need to figure out h_stride. Right now h_stride(1) is the rows stride, and 
h_stride(2) is columns stride, if the lat/lon coordinates are 2-d matrices. If 
the lat/lon coordinates are different length 1-d arrays, then h_stride(1) is 
lat stride, and h_stride(2) is lon stride I think...

Original comment by crosb...@gmail.com on 20 Dec 2011 at 4:48

[GoogleCodeExporter]

How about if we use the same syntax that ERDDAP uses?
They put the stride right in the middle of the lon request, like this:
s.lon_range=[-71.5:2:-65.5]
s.lat_range=[38.0:3:46.0]

Original comment by rsignell on 20 Dec 2011 at 5:53

[GoogleCodeExporter]

Oops. I guess the arguments would have to be strings, though, if we did that, 
like
     s.lon_range='-71.5:2:-65.5'
or else Matlab would not pass the right thing.

Maybe s.lon_range
      s.lon_stride

      s.lat_range
      s.lon_stride

is better

Original comment by rsignell on 20 Dec 2011 at 5:56

[GoogleCodeExporter]

I think that the lon/lat_stride option won't quite work with very curvilinear 
datasets. (its technically incorrect for any curvilinear datasets I think). its 
really like an i/j horizontal stride, maybe we should just make the only option 
to be one number for horizontal striding?

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

[GoogleCodeExporter]

It certainly is an i,j stride, not a lon/lat stride, but stride *should* work 
for any structured grid, not matter how curvy it is, because logically the data 
is just a 2D (or 3D, or 4D) in [(n),(k),j,i] space.

-Rich

Original comment by rsignell on 3 Jan 2012 at 6:24

[GoogleCodeExporter]

I just meant the terminology is confusing. Maybe we just have one single number 
as a horizontal stride parameter.

Original comment by crosb...@gmail.com on 3 Jan 2012 at 7:43

[GoogleCodeExporter]

Original comment by crosb...@gmail.com on 20 Apr 2012 at 4:29

• Changed state: Fixed

[GoogleCodeExporter]

So does "fixed" mean that now only 1 number is allowed for horizontal stride?

Original comment by rsignell on 20 Apr 2012 at 5:05

[GoogleCodeExporter]

No, i think 2 is still allowed. I had already fixed the original problem, and 
this was hanging around as an unfinished issue.

Original comment by crosb...@gmail.com on 20 Apr 2012 at 8:47