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@gclements.plus.com>