[GRASS5] [bug #4145] (grass) r.patch -z eats holes in data

Request Tracker grass-bugs at intevation.de
Mon Mar 6 23:35:08 EST 2006


this bug's URL: http://intevation.de/rt/webrt?serial_num=4145
-------------------------------------------------------------------------

Subject: r.patch -z eats holes in data

Platform: GNU/Linux/x86
grass obtained from: Other (CDROM etc)
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: 6.0.1

r.patch with the -z option does not patch null data in the first input with 0 data in later inputs.

r.patch with the -z option is frequently used to patch together data of somewhat poor quality in which 0 is used both for no data in the boundaries of patches and as a legitimite piece of data in the interior of tiles. It is my belief, therfore, that the correct behaviour for r.patch is to not only attempt to replace nulls and zeros with data points, but also to replace nulls with zeros. Changing this behaviour would make the results of r.patch much less dependent upon the order in which input maps are presented. As it is the first input map's zeros are preserved when there is no other data, but the zeros in the other input maps are removed and replaced with nulls (because when no replacement is found it defaults to the value of the first input by the act of not changing anything).

You can see an example of these holes (magenta dots near bright curves at bottom and elsewhere) here: http://www.shockfamily.net/cedric/grass/spearfish1.png

Here is the segment of code in do_patch.c as it currently stands:

    if (ZEROFLAG)  /* use 0 for transparency instead of NULL */
    {
	if (G_is_zero_value(result, out_type) ||
	    G_is_null_value(result, out_type))
	{
	    if(G_is_zero_value(patch, out_type) ||
	       G_is_null_value(patch, out_type))
		more = 1;
            else
	    {
	        G_raster_cpy(result, patch, 1, out_type);
		if(out_type==CELL_TYPE)
	            G_update_cell_stats ((CELL *) result, 1, statf);
	    }
	} /* ZERO support */
    }


And here is a suggested, and untested, replacement to fix this problem:

    if (ZEROFLAG)  /* use 0 for transparency instead of NULL */
    {
	if (G_is_zero_value(result, out_type) ||
	    G_is_null_value(result, out_type))
	{
	    if(G_is_null_value(patch, out_type))
		more = 1;
            else
	    {
	        if (G_is_zero_value(patch, out_type))
	            more = 1;
	        G_raster_cpy(result, patch, 1, out_type);
		if(out_type==CELL_TYPE)
	            G_update_cell_stats ((CELL *) result, 1, statf);
	    }
	} /* ZERO support */
    }

If the replacment data is null we mark the row as having more replacements to be done and skip replacing the cell, as before. However if the patch is zero we go ahead and apply it (replacing either a zero or null value), but still mark the row as candidate for further replacement.

--Cedric Shock

-------------------------------------------- Managed by Request Tracker




More information about the grass-dev mailing list