[GRASS5] The status of 5.0

[Glynn Clements]

Helena wrote:

> 912 - warning in r.mapcalc for NULL and INT/INT behavior

1. Has the "bug" part been resolved? I.e. the fact that r.mapcalc
sometimes failed to produce a result? If not, can you (Markus) provide
a suitable test case?

2. What is the problem with NULL values? AFAICT, NULL values are
handled correctly.

3. Generating a warning for INT/INT is easy enough. But that isn't
really a bug; certainly not a "release critical" bug (in that 4.3
doesn't generate a warning either).

4. If anyone has test cases for r.mapcalc, I would appreciate it if
r.mapcalc3 could be similarly tested.

> 249,845 - r.reclass - I am not sure whether I understand this correctly but
> it appears that the command works differently than described in manual,
> I suggest here to change the manual and remove the * rule from there as it does
> not
> work and it does not seem to be an easy fix. It is easy to run r.null to change
> the
> NULLs to 0 or anything else on the reclassed file.
> I suggest to remove the following sentence from the manual:
> "To include all (remaining) values the asterix "*" can be used.
> This rule has to be set as last rule. No further rules are accepted after
> setting this rule."
> and close this bug report

It appears that the range of the reclass table is determined only by
the explicitly specified categories. '*' only affects categories which
lie within that range. An example (from spearfish):

    GRASS:~ > r.reclass input=fields output=foo
    
    Enter the rule or 'help' for the format description:
    > 5 = 1
    > 10 = 2
    > * = 3
    > 
    
    GRASS:~ > r.info foo | tail -n 10
     |----------------------------------------------------------------------------|
     |   Reclassification of [fields] in mapset [PERMANENT]                       |
     |                                                                            |
     |         Category        Original categories                                |
     |                                                                            |
     |          1              5                                                  |
     |          2              10                                                 |
     |          3              6-9                                                |
     +----------------------------------------------------------------------------+

It might be possible to fix this by extending the range of the reclass
table to the range of the input when a default rule is provided.

> A side note:
> > what do we do with "bugs" like this - keep them there with low priority
> > (there is plenty of them there) or vote whether they should be removed?
> >You can change the area to "wish" after clicking on "Area" on top of the
> >bug report.
> 
> I am not sure that I should be making decisions about what should be
> changed to wish and what is a critical release bug as I am not
> a programmer and for whatever reason my view may differ from majority -
> (although others could change it back)

Well, the conventional definition of a "bug" is that the program fails
to behave as documented. Users often consider it a bug if the program
fails to behave according to their expectations, but this definition
is too subjective to be of any use.

Also, nearly all programs have limitations which will cause them to
fail (e.g. due to insufficient memory or disk space) even though the
input is valid.

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