Fri, Jun 20 2003
01:10:17
|
|
Request created by guest
|
|
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 :)
Caspar Hasenclever |
|
Fri, Jun 20 2003
02:55:20
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16114.23034.283146.304819@cerise.nosuchdomain.co.uk>
|
Date |
Fri, 20 Jun 2003 01:48:58 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #1956] (grass) r.reclass: re-reclass categories off by one/many
|
In-Reply-To |
<20030619231018.57587139BB@lists.intevation.de>
|
References |
<20030619231018.57587139BB@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PATCH_UNIFIED_DIFF, QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.44
|
X-Spam-Level |
|
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>
|
|
Wed, Aug 13 2003
16:01:12
|
|
Status changed to resolved by pkelly
|
|