Convert lon to [-180 180] in grid_interop only if lon stays monotonic

[GoogleCodeExporter]

We need to modify the grid_interop method to leave the longitude alone when 
trying to force it to the range [-180 180] makes longitude non-monotonic.

When accessing the RTOFS global data using grid_interop, subtracting 360 to 
force longitude to span [-180 to 180] makes the longitude non-monotonic. It 
becomes a vector that starts at 70, goes up to 180, then jumps to -180 and 
continues increasing from there, instead of climbing smoothly from 70 to 433.
It then plots incorrectly, and is not CF-compliant.

If we would have left the longitude values alone, it would plot fine using 
m_map.  Attached is the file reverts the longitude values to their original 
state (via the lines between "start hack" and "stop hack") so they are 
monotonic again.  

Will the subsetting work correctly on this type of grid?

Original issue reported on code.google.com by rsignell on 8 Nov 2011 at 2:05

Attachments:

• rtofs_global.m

[GoogleCodeExporter]

Actually, I noticed this problem using the nc{'var'}(2,1,:,:).grid    syntax, 
not with the grid_interop method.  But I think they are the same thing, right?

Original comment by rsignell on 8 Nov 2011 at 2:32

[GoogleCodeExporter]

Original comment by rsignell on 8 Nov 2011 at 3:20

[GoogleCodeExporter]

I am a little confused. Can you show me?

Original comment by crosb...@gmail.com on 17 Nov 2011 at 5:22

[GoogleCodeExporter]

Did you see the m-file?   We don't want to have to do the gyrations with 
longitude that this m-file has to currently do.

Original comment by rsignell on 17 Nov 2011 at 5:32

[GoogleCodeExporter]

I accept that the coordinates I think need to be monotonic for plotting. Should 
we just throw out the -180/180 conversion then? Whats the benefit?

Original comment by crosb...@gmail.com on 17 Nov 2011 at 7:28

• Changed state: Started

[GoogleCodeExporter]

We were converting to -180 to 180 because we wanted geosubset to work (e.g. if 
the user asks for s.lon=[-70 -60] and the data spans [290 300] will they get 
data back?) But I guess it's best to make geosubset work correctly, not adjust 
the data.

Original comment by rsignell on 17 Nov 2011 at 7:45

[GoogleCodeExporter]

Hmm that's a tough call. We could probably handle the this on the geosubset 
side, check to see the bounds of the lon variable and then convert the input 
bbox values appropriately?

Original comment by crosb...@gmail.com on 17 Nov 2011 at 8:01

[GoogleCodeExporter]

I made a change so that we don't do the -180/180 conversion for the 
grid_interop method. Now we convert the geosubset bbox lon limits from -180/180 
to the convention that the dataset follows just to do the subsetting, and 
return whatever the data is in the native conventions. This requires that input 
into geosubset is mandatory -180/180.

Original comment by crosb...@gmail.com on 17 Nov 2011 at 8:41

• Changed state: Fixed

[GoogleCodeExporter]

So if the data goes from [0 360], and we want to request 10 degrees on either 
side of the dateline, we request s.lon=[170 -170]?

Original comment by rsignell on 17 Nov 2011 at 9:16

[GoogleCodeExporter]

Yes, s.lon = [-170 to 170] I think. Does it seem to work like that? I haven't 
thought through the changes enough to know if it should also work for the 
73-433 rtofs dataset, but ideally we should be able to accomodate it.

Original comment by crosb...@gmail.com on 18 Nov 2011 at 2:44

[GoogleCodeExporter]

The fix doesn't seem to be working correctly for attached test where we request
>> s.lon

ans =

  -71.5000  -63.0000

but the longitude in the data spans [  148.6406  357.3209]

we get this really ugly and not very informative error:

>> nam_4km_example
Index exceeds matrix dimensions.

Error in ncdataset/readdata (line 447)
                    ranges.add(ucar.ma2.Range(first(i) - 1, last(i) - 1, stride(i)));

Error in ncdataset/data (line 165)
                    d = obj.readdata(variable, first, last, stride);

Error in ncgeodataset/subsref (line 210)
                            B = builtin('subsref',obj,g);

Error in ncvariable/somedata (line 353)
                data = obj.dataset.data(name, first, last, stride);

Error in ncvariable/data (line 174)
                d = somedata(obj, 1, first, last, stride);

Error in ncgeovariable/geosubset (line 491)
                d.data = obj.data(first, last, stride);

Error in ncgeovariable/subsref (line 685)
                            sref = builtin('subsref',obj,s);

Error in nam_4km_example (line 28)
us=uvar.geosubset(s);

Original comment by rsignell on 30 Nov 2011 at 5:09

Attachments:

• nam_4km_example.m