[GRASS-dev] Zooming issue in gis manager

[Glynn Clements]

Joel Pitt wrote:

> > I think that the core problem is that d.rast cannot render an
> > arbitrary portion of a map; the rendered image has to be aligned to
> > the cell boundaries.
> >
> > The region always has an integer number of rows and columns. d.rast
> > always ensures that the entire region just fits inside the frame; one
> > pair of edges will always exactly touch the corresponding edges of the
> > region.
> >
> > Thus, the rendered image will only ever show whole cells. You will
> > never get a situation where part of a cell is shown and the other part
> > cropped.
> 
> How much difficulty would it be to alter the behaviour of d.rast to
> allow partial
> cells to be rendered?
> 
> If someone were to make the change, can anyone think of what flow on
> effects this would have for other components of GRASS? (Not too much
> of an issue since a flag could be added to d.rast to have this as
> optional behaviour).

It isn't trivial, for reasons of both implementation and design.

d.rast uses various functions from lib/display to do most of the work. 
Either these functions would need to be changed, or d.rast would need
to be re-implemented without them.

The main one is D_do_conversions() from lib/display/cnversions.c,
which is used by D_cell_draw_setup[_RGB](). This takes a Cell_head and
a screen rectangle (integer coordinates), and determines the
offset/scale parameters for a set of linear transformations which can
convert between cell array indices, geographic coordinates and screen
coordinates.

These parameters are then used by D_u_to_a_row() etc, which in turn
are used by D_draw_cell().

Probably the most viable solution would be an extended version of
D_do_conversions() which takes two Cell_head structures.

The first would be the current region (which determines the mapping
between geographic coordinates and cell array indices), while the
second would be the region to fit to the screen rectangle (only the
bounds would be used, with the resolution and rows/cols being
ignored).

The existing D_do_conversions() would just call the extended version
with the same Cell_head for both arguments.

There would also need to be extended D_cell_draw_setup[_RGB]
functions, and some means to tell d.rast (and d.rgb, d.his, ...) which
region to draw (you can't use the current region, because the current
region is always subdivided into an exact number of rows and columns,
and changing that certainly isn't viable).

-- 
Glynn Clements <glynn at gclements.plus.com>