[GRASS-dev] i.rotate in Add-ons, philosophy for the region increase before processing

[Glynn Clements]

Yann Chemin wrote:

> Could you please give me your advice:
> 
> i.rotate in add-ons will need to have some space around the image before
> rotating it, then it should actually write to disk that enlarged (and
> rotated) raster data.
> In the GRASS GIS manual, it says that it is not recommended to play with
> window sizes once you opened a raster (
> http://grass.osgeo.org/programming7/gislib.html#Region).
> 
> Should it be telling the user to select a region large enough before
> running it?
> Should there be an exception for a module (i.e. playing around with region
> settings within module)?
> Any other option?

Not changing the region after opening a raster is an implementation
constraint. It doesn't constrain how a module behaves. You just need
to set the window before opening the raster (you don't need to open a
raster in order to obtain its "cellhd").

In the case of something like i.rotate, it shouldn't force the user to
rotate the entire image, as they might only need a portion of it. 
Instead, it should provide an option to enlarge the region to fit the
rotated image.

Also, regarding i.rotate specifically:

1. At a minimum, it should support any affine transformation, not just
rotation. Possibly even projective and/or polynomial transformations.

2. The rotation origin should be able to be specified by the user.

3. It's working the wrong way around; the output coordinates should be
projected to the input coordinate system, to ensure that there aren't
any gaps.

4. It should support interpolation methods other than
nearest-neighbour.

5. It shouldn't require loading the entire raster into memory.

The easiest way to get most of these features would be to take the
code from r.proj.

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