[GRASS-dev] Zooming issue in gis manager

Hamish hamish_nospam at yahoo.com
Thu Nov 2 18:26:55 EST 2006


Glynn Clements wrote:
> > 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).


.. the resultant module should proabably be called something other
than "d.rast". ("d.raster", "d.rast.fuzzy",...)


Hamish




More information about the grass-dev mailing list