[GRASS5] [bug #1066] (grass) strange r.reclass warning

Justin_Hickey_via_RT · May 28, 2002, 2:11pm

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

Subject: strange r.reclass warning

grass obtained from: CVS
grass binary for platform: Compiled from Sources

Dear developers,

the r.reclass command prints a strange message:

r.reclass in=riserve2001 out=tberiserve < reclassfile
WARNING: Unable to create dependency file in [riserve2001 in
habitatCap2001]

The reclassfile looks like this:
164 45 49 28 78 34 171 = 1 caprioli campionati negativi
213 206 152 182 = 2 solo caprioli campionati positivi
6 65 57 15 = 3 solo casi umani
185 83 192 = 4 casi umani e caprioli campionati positivi

The original map is not in the current mapset and belongs to a different owner.
r.info riserve2001
| Layer: riserve2001 Date: Thu May 31 15:42:47 2001 | Mapset: habitatCap2001 Login of Creator: lpotrich | Location: pat | DataBase: /mpa_gdata/ssi/BIO/GRASS_DATA/data

g.gisenv
GISDBASE=/mpa_gdata/ssi/BIO/GRASS_DATA/data
LOCATION_NAME=pat
MAPSET=adonini

Perhaps the reclass_to file cannot be written? The current warning is
not really helpful...

Angela
Markus

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

Glynn_Clements · May 28, 2002, 10:07pm

Request Tracker wrote:

Subject: strange r.reclass warning

grass obtained from: CVS
grass binary for platform: Compiled from Sources

Dear developers,

the r.reclass command prints a strange message:

r.reclass in=riserve2001 out=tberiserve < reclassfile
WARNING: Unable to create dependency file in [riserve2001 in
habitatCap2001]

The reclassfile looks like this:
164 45 49 28 78 34 171 = 1 caprioli campionati negativi
213 206 152 182 = 2 solo caprioli campionati positivi
6 65 57 15 = 3 solo casi umani
185 83 192 = 4 casi umani e caprioli campionati positivi

The original map is not in the current mapset and belongs to a different owner.
r.info riserve2001
| Layer: riserve2001 Date: Thu May 31 15:42:47 2001 | Mapset: habitatCap2001 Login of Creator: lpotrich | Location: pat | DataBase: /mpa_gdata/ssi/BIO/GRASS_DATA/data

g.gisenv
GISDBASE=/mpa_gdata/ssi/BIO/GRASS_DATA/data
LOCATION_NAME=pat
MAPSET=adonini

Perhaps the reclass_to file cannot be written?

Correct.

BTW, this was the very first change I made to GRASS (bug #229, March
2001). Before that, r.reclass would just fail if you didn't have write
permission on the source mapset.

The current warning is not really helpful...

src/libes/gis/reclass.c, line 261:

G_warning (_("Unable to create dependency file in [%s in %s]"),
buf2, reclass->mapset);

Feel free to change it; although I'm not sure that any message will be
helpful to a user that doesn't understand the details of the reclass
mechanism. Maybe the situation should be silently ignored?

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

Markus_Neteler1 · May 29, 2002, 6:30am

On Tue, May 28, 2002 at 11:07:28PM +0100, Glynn Clements wrote:

Request Tracker wrote:

> Subject: strange r.reclass warning
>
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
>
> Dear developers,
>
> the r.reclass command prints a strange message:
>
> r.reclass in=riserve2001 out=tberiserve < reclassfile
> WARNING: Unable to create dependency file in [riserve2001 in
> habitatCap2001]
>
> The reclassfile looks like this:
> 164 45 49 28 78 34 171 = 1 caprioli campionati negativi
> 213 206 152 182 = 2 solo caprioli campionati positivi
> 6 65 57 15 = 3 solo casi umani
> 185 83 192 = 4 casi umani e caprioli campionati positivi
>
> The original map is not in the current mapset and belongs to a different owner.
> r.info riserve2001
> | Layer: riserve2001 Date: Thu May 31 15:42:47 2001 | Mapset: habitatCap2001 Login of Creator: lpotrich | Location: pat | DataBase: /mpa_gdata/ssi/BIO/GRASS_DATA/data
>
> g.gisenv
> GISDBASE=/mpa_gdata/ssi/BIO/GRASS_DATA/data
> LOCATION_NAME=pat
> MAPSET=adonini
>
> Perhaps the reclass_to file cannot be written?

Correct.

BTW, this was the very first change I made to GRASS (bug #229, March
2001). Before that, r.reclass would just fail if you didn't have write
permission on the source mapset.

> The current warning is not really helpful...

src/libes/gis/reclass.c, line 261:

G_warning (_("Unable to create dependency file in [%s in %s]"),
buf2, reclass->mapset);

Feel free to change it; although I'm not sure that any message will be
helpful to a user that doesn't understand the details of the reclass
mechanism. Maybe the situation should be silently ignored?

I suggest yes - it will be more confusing than helpful (and the user
can even do nothing about it except generating an own local copy
of the "foreign" mapset which is mostly not possible or desired).

We could keep the warning commented in the code in case we change our
opinion in future.

Markus

Bernhard_Reiter · May 29, 2002, 3:34pm

On Wed, May 29, 2002 at 08:30:51AM +0200, Markus Neteler wrote:

On Tue, May 28, 2002 at 11:07:28PM +0100, Glynn Clements wrote:

> > the r.reclass command prints a strange message:
> >
> > r.reclass in=riserve2001 out=tberiserve < reclassfile
> > WARNING: Unable to create dependency file in [riserve2001 in
> > habitatCap2001]

> > Perhaps the reclass_to file cannot be written?
> Correct.

> > The current warning is not really helpful...

> Maybe the situation should be silently ignored?

No. It is important to warn.

I suggest yes - it will be more confusing than helpful (and the user
can even do nothing about it except generating an own local copy
of the "foreign" mapset which is mostly not possible or desired).

What about adding "you can normally savely ignore this warning."
or "this means that you cannot do xxxxxxxxxxx in the future
if you need this, you have to make a local
copy of the foreign maps. Otherwise you can ignore this warning."

Of course xxxxxxxxxxxx would have to be filled.

Russell_Nelson · May 29, 2002, 4:03pm

Bernhard Reiter writes:
> No. It is important to warn.

If nothing bad is going to happen, then why is it a WARNING? Why not
word it as a Note instead?

Bernhard_Reiter · May 29, 2002, 4:19pm

On Wed, May 29, 2002 at 12:03:43PM -0400, Russell Nelson wrote:

Bernhard Reiter writes:
> No. It is important to warn.

If nothing bad is going to happen, then why is it a WARNING? Why not
word it as a Note instead?

Good question: I was under the impression that it will have some
consequences. If it doesn't why attempting that operation?

Glynn_Clements · May 29, 2002, 10:00pm

Bernhard Reiter wrote:

> > No. It is important to warn.
>
> If nothing bad is going to happen, then why is it a WARNING? Why not
> word it as a Note instead?

Good question: I was under the impression that it will have some
consequences. If it doesn't why attempting that operation?

A brief explanation of reclassed_to:

When creating a reclass map, G_put_reclass() attempts to append the
details of the resulting map to the *source* map's "reclassed_to"
file. This allows programs to discover whether a given map has any
reclass maps based upon it, via G_is_reclassed_to().

The main user of G_is_reclassed_to() is g.remove, which refuses to
remove a map if it is known to be the base map for any existing
reclass maps.

The warning occurred if the base map's reclassed_to file cannot be
updated (due to the lack of write permission). The only consequence of
this is that the base map wouldn't have any record of the reclass map,
so it could be removed while the reclass map existed, rendering the
reclass map useless.

A brief history of reclassed_to:

1. It wasn't present in GRASS 4.3.

2. It was present in the 2001/02/26 GRASS 5 CVS snapshot (the first
version of GRASS 5 which I tried) but, at that time, failure to update
the reclassed_to file caused r.reclass to fail. So, a "normal" user
typically couldn't generate a reclass of a map in the PERMANENT
mapset.

3. Around March 2001, I ran into this problem, and reported it as a
bug (#229). Once I had CVS commit access, I changed G_put_reclass() to
generate a warning but to indicate success.

4. Following Markus' recent comments, I disabled the warning, as:

a) the issue doesn't have a simple explanation,

b) even if the user understands the issue, they probably can't do much
about it (apart from taking their own copy of the base map, so that
they will have write permission; but this probably shouldn't be
encouraged).

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