[GRASS5] G3D libraries notation

[Paul Kelly]

Hello

On Tue, 3 Dec 2002, Alfonso Vitti wrote:

> The idea is to rewrite the functions, which now use the "x-y" notation,
> to make them follow the "rows-cols" notation.
>

I think this is a very good idea. I know from working in image processing
that it is very easy to get confused between pixel co-ordinates, which are
discrete integer "rows-columns" values, and distance across or up the
image, which is a continuous floating point number and can be referred to
in "x-y" notation. I also always use 'columns' instead of 'cols' in my
code to avoid any possible confusion (however remote) with 'colours'.

Normally also "rows-columns" notation starts from the upper left corner of
the region, while "x-y" starts from the lower left. This is always a
terrible source of complicated code as the number of rows in the region
must be known to convert between row and y values. So it would be good to
standardise this if possible to have the same origin but I have no idea
what state the g3d code is in at the minute.

I don't know if the first element in GRASS raster row-column arrays is 0 or 1
(in MATLAB it is 1; in C it is 0). If the first cell in the region is (row=0,
column=0), then the corner of the region should be (x=-0.5, y=-0.5) or if the
first cell is (row=1, column=1) then the corner of the region will be
(x=0.5, y=0.5). Using this notation then the centre of each cell's "x-y"
co-ordinates will be the same as the "row-column" co-ordinates for the cell.
Having this offset of 0.5 in the "x-y" co-ordinates makes interpolation
calculations etc. quite simple and intuitive.

It is probably obvious that most of my experience with raster data has
been image processing in MATLAB and I haven't done any GRASS raster
programming, so all my ideas may not be suitable or consistent with
existing GRASS practice (this second reason is always the most important I
think). But I have thought a lot about this sort of thing and have come up
with some ideas for best practice.

To summarise, I think using "row-column" notation is good because it
forces programmers to think in terms of discrete integer values, which is
how the raster tile is read, and realise they need to do re-sampling and
interpolation if necessary to improve the accuracy of their calculations.

Sorry if I've missed the point but I hope this is useful and makes sense.
If you can point out a sample file in the GRASS source that has some of
the code with bugs I may have a chance to look at some of it and see if the
changes I suggest would be the same as yours.

Paul Kelly