[GRASS5] [bug #1956] (grass) r.reclass: re-reclass categories off by one/many

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

Subject: r.reclass: re-reclass categories off by one/many

Platform: GNU/Linux/i386
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: GRASS 5.0.0pre4

r.reclass produces a shift in assigned categories when reclassifying raster layers which are themselves products of a reclassification (re-reclass). this shift is easily visible when comparing the resulting files in MAPSET/cellhd. it appears to me to be a small mistake in the compose() function in src/raster/r.reclass/cmd/reclass.c which is only called for re-reclass.
if the lowest assigned category number is not 0, the way the category table is filled will be inadeqate (i.e. array is not filled starting from position 0), as G_put_reclass() will read that array starting from 0 later on.
my C isn't so hot, but the following change made it work for me:

in src/raster/r.reclass/cmd/reclass.c:
<start diff output>
64c64
< new->table[i] = k;
---

  new->table[i - new->min] = k;

</end>

this also worked for the interactive mode (i expect it calls the same function).

maybe this solution is a little too simple, i don't claim to have fully (or even partially) understood the design behind the structs involved.
what mystifies me is why i haven't seen anything in the bug reports about this. the problem surfaced in a grass course at the university of freiburg using the spearfish data set. the task was to reclassify the "texture" raster layer, which is a reclassification of the "soils" raster layer. the results where quite obviously weird - i would have thought this might have happened elsewhere. my search of the bug lists, google groups etc didn't produce any hits, though.
anyway, HTH, over to you :slight_smile:

Caspar Hasenclever

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

Request Tracker wrote:

Subject: r.reclass: re-reclass categories off by one/many

r.reclass produces a shift in assigned categories when reclassifying
raster layers which are themselves products of a reclassification
(re-reclass). this shift is easily visible when comparing the
resulting files in MAPSET/cellhd. it appears to me to be a small
mistake in the compose() function in
src/raster/r.reclass/cmd/reclass.c which is only called for
re-reclass.

if the lowest assigned category number is not 0, the way the category
table is filled will be inadeqate (i.e. array is not filled starting
from position 0), as G_put_reclass() will read that array starting
from 0 later on.

my C isn't so hot, but the following change made it work for me:

in src/raster/r.reclass/cmd/reclass.c:
<start diff output>
64c64
< new->table[i] = k;
---
> new->table[i - new->min] = k;
</end>

This looks correct; however, the same needs to be done for the no-data
case, i.e.:

--- src/raster/r.reclass/cmd/reclass.c 28 Mar 2002 17:30:39 -0000 1.4
+++ src/raster/r.reclass/cmd/reclass.c 20 Jun 2003 00:48:30 -0000
@@ -55,13 +55,13 @@
   j = old->table[i - old->min];
   if (G_is_c_null_value(&j) || j < mid->min || j > mid->max)
   {
- G_set_c_null_value(&new->table[i], 1);
+ G_set_c_null_value(&new->table[i - new->min], 1);
       continue;
   }

   k = mid->table[j - mid->min];

- new->table[i] = k;
+ new->table[i - new->min] = k;
     }
}

I've committed this fix to the CVS HEAD version.

this also worked for the interactive mode (i expect it calls the same
function).

The interactive version simply runs the non-interactive version to do
the actual reclass operation.

maybe this solution is a little too simple, i don't claim to have
fully (or even partially) understood the design behind the structs
involved.

what mystifies me is why i haven't seen anything in the bug reports
about this. the problem surfaced in a grass course at the university
of freiburg using the spearfish data set. the task was to reclassify
the "texture" raster layer, which is a reclassification of the "soils"
raster layer. the results where quite obviously weird - i would have
thought this might have happened elsewhere. my search of the bug
lists, google groups etc didn't produce any hits, though.

I suspect it's because reclassing of reclass maps isn't particularly
common; it wasn't even possible until the "pre4" release (March
2002).

--
Glynn Clements <glynn.clements@virgin.net>