[GRASS5] r.in.mat, r.out.mat for MATLAB I/O

[Hamish]

> > To make my life a bit easier, I was thinking out writing two new
> > modules: r.in.mat and r.out.mat. These would save and load Matlab 
> > binary ".mat" files in a manner much like r.in.ascii & r.out.ascii.

...

> > * I've got to make a choice whether to make [1,1] to be top-left or
> > bottom-left of the map. Matlab can deal with both ("axis xy" or 
> > "axis ij"), but "xy" (bottom-left) is default. Which is better to
> > use?
> 
> In GRASS, row 0 is the North edge and column 0 is the West edge so, to
> the extent that it makes a difference, top-left would seem more
> logical.

ok
 
> What is the difference exactly? Just how arrays are displayed?

Little difference really, in matlab's engine arrays start at [1,1] but
otherwise are just mathematical constructs so it doesn't really
matter/is all in your mind.

If you display raw values to the console screen, [1,1] is top left.
However if you plot the array as a surface in the default "axis xy"
mode, [1,1] is the bottom left (well [0,0] really but it snaps to the
extent of the data) & the map is displayed upside-down. If you give it 
the command "axis ij", it flips the x-axis in the plot window and the 
map displays as you'd expect.


> > * The data storage format is (I think) in the FORTRAN style,
> > 
> > e.g. an array called "A":
> > 
> > A = [ 1 2 3
> >       4 5 6
> >       7 8 9 ];
> > 
> > is saved as A[9] = {1, 4, 7, 2, 5, 8, 3, 6, 9};
> > with rows x column data stored elsewhere.
> > 
> > I can see this being a headache.. Have to load the whole map instead
> > of just one row at a time. Have to use lots of memory or lots of
> > slow loops..
> 
> Or just dump the data in the order that GRASS provides it, and
> transpose it in Matlab.

That's *really* easy to do:
 map = map';

with perhaps a flipud() or fliplr() if needed.

but that seems like a half measure to me.
Probably what I'll try first in the prototype version though.


> > Matlab supports the IEEE values of "inf" and "-inf", do I have to
> > trap that in r.in.mat and convert to null?
> 
> I'm not sure. The handling of infinite values isn't clearly defined.

Until someone has need for it (I don't), I think I'll just tag them as
null. (slope?)


regards,
Hamish