[GRASS-dev] Rast_set_window() changes in 7.0

[Markus Metz]

Glynn Clements wrote:
>
> r42876 implements a fairly invasive change to the raster window
> handling in 7.0. Specifically:
>
> 1. Modules which read and write maps at different resolutions now make
> use of the ability to set separate input and output windows
> (Rast_set_input_window() and Rast_set_output_window()).
>
> 2. Changing the input/output window while maps are open for read/write
> (respectively) now generates a fatal error. There should be no need to
> do so, and I want to get bug reports for any cases I've overlooked.
> Rast_set_window() changes both the input and output windows.
>
There is a problem with gdal linked maps. In lib/raster/get_row.c a change like

--- get_row.c	(revision 42959)
+++ get_row.c	(working copy)
@@ -927,7 +927,7 @@
 static void get_null_value_row_gdal(int fd, char *flags, int row)
 {
     struct fileinfo *fcb = &R__.fileinfo[fd];
-    DCELL *tmp_buf = Rast_allocate_d_buf();
+    DCELL *tmp_buf = Rast_allocate_d_input_buf();
     int i;

     if (get_map_row_nomask(fd, tmp_buf, row, DCELL_TYPE) <= 0) {

or

--- get_row.c	(revision 42959)
+++ get_row.c	(working copy)
@@ -927,7 +927,7 @@
 static void get_null_value_row_gdal(int fd, char *flags, int row)
 {
     struct fileinfo *fcb = &R__.fileinfo[fd];
-    DCELL *tmp_buf = Rast_allocate_d_buf();
+    DCELL *tmp_buf = G__alloca(R__.rd_window.cols * sizeof(DCELL));
     int i;

     if (get_map_row_nomask(fd, tmp_buf, row, DCELL_TYPE) <= 0) {


is needed, Rast_allocate_d_buf() does not work on a split window.

Markus M


> I would appreciate it if people can test any affected modules.
> Specifically, the following are the modules and libraries which called
> Rast_set_window:
>
>        display/d.rast.arrow
>        display/d.rast.num
>        general/g.region
>        imagery/i.atcorr
>        imagery/i.ifft
>        imagery/i.rectify
>        lib/display
>        lib/gpde
>        lib/lidar
>        lib/rst/interp_float
>        ps/ps.map
>        raster/r.basins.fill
>        raster/r.category
>        raster/r.coin
>        raster/r.compress
>        raster/r.describe
>        raster/r.external
>        raster/r.flow
>        raster/r.horizon
>        raster/r.in.arc
>        raster/r.in.ascii
>        raster/r.in.bin
>        raster/r.in.gdal
>        raster/r.in.gridatb
>        raster/r.in.mat
>        raster/r.in.png
>        raster/r.in.poly
>        raster/r.neighbors
>        raster/r.null
>        raster/r.proj
>        raster/r.recode
>        raster/r.resamp.bspline
>        raster/r.resamp.filter
>        raster/r.resamp.interp
>        raster/r.resamp.rst
>        raster/r.resamp.stats
>        raster/r.rescale
>        raster/r.slope.aspect
>        raster/r.sun
>        raster/r.support.stats
>        raster/r.support
>        raster/r.surf.idw2
>        raster/r.to.rast3
>        raster/r.to.rast3elev
>        raster/simwe/simlib
>        raster3d/r3.cross.rast
>        raster3d/r3.out.vtk
>        raster3d/r3.to.rast
>
> In particular, anything using the gpde, lidar or rst libraries should
> be a priority.
>
> FWIW, the rationale behind the "split window" functionality is to
> avoid having r.resamp.* continually changing the window between the
> input and output resolutions, as this causes the column mapping to be
> regenerated for the input map each time.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>