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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
