[GRASS5] Inconsistencies among modules

GRASS GRASS developer
1

  Two inconsistencies I've picked up:

  1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
output file name with no warning that that file already exists, and asking
the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
tell the user that the output file name exists, does not ask for directions,
and refuses to let the user overwrite it. Recommendation: always check,
always ask, follow the user's directions.

  2) Most modules present a status indication of processing; usually the
percentage completed. Other modules (today it was r.poly) give no indication
whether they are slowly working or have silently passed away.
Recommendation: have a progress indicator for all modules.

Thanks,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                 Making environmentally-responsible mining happen.

2

Rich Shepard wrote:

Two inconsistencies I've picked up:

1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
output file name with no warning that that file already exists, and asking
the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
tell the user that the output file name exists, does not ask for directions,
and refuses to let the user overwrite it. Recommendation: always check,
always ask, follow the user's directions.

Folks,

What would the normal mechanism be to ask the user if they want to overwrite
an existing raster layer?

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

3

Frank Warmerdam wrote:

Rich Shepard wrote:

> Two inconsistencies I've picked up:
>
> 1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
>output file name with no warning that that file already exists, and asking
>the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
>tell the user that the output file name exists, does not ask for directions,
>and refuses to let the user overwrite it. Recommendation: always check,
>always ask, follow the user's directions.
>

Folks,

What would the normal mechanism be to ask the user if they want to overwrite
an existing raster layer?

r.mapcalc does it the right way, most of other programs don't

mapcalc> diff=owhusle-owhusle.rst
diff - already exists. ok to overwrite? (y/n)

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

4

Rich Shepard wrote:

  1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
output file name with no warning that that file already exists, and asking
the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
tell the user that the output file name exists, does not ask for directions,
and refuses to let the user overwrite it. Recommendation: always check,
always ask, follow the user's directions.

There are two distinct issues here. One is the behaviour of
G_parser(), the other is the application.

1. If an option has a "gisprompt" field which starts with "new", and
the program is run without arguments, G_parser() won't let you specify
a layer which already exists. However, if you provide command line
arguments, G_parser() won't complain if the layer exists.

2. An individual applications might implement its own checks; if it
does, it might unconditionally refuse to overwrite or it might prompt.
Also, it might choose to prompt only if stdin is a terminal; in which
case, there's the issue of whether or not to overwrite in the case
where it doesn't prompt. Or it might provide a flag to inhibit
prompting; or this might get rolled into the behaviour of switches
such as -q (quiet) or -v (verbose).

  2) Most modules present a status indication of processing; usually the
percentage completed. Other modules (today it was r.poly) give no indication
whether they are slowly working or have silently passed away.
Recommendation: have a progress indicator for all modules.

This is likely to be a lot easier to actually implement than point 1
above. It doesn't require any significant design; it just needs people
to add calls to G_percent() within programs. However, there may be a
few cases where a percentage indication isn't practical.

It's straightforward in cases where the workload is a pre-determined
number of iterations of a loop with fairly constant overhead per
iteration. It's less straightforward for recursive algorithms, or
where a process is iterated until some test is passed.

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

5

Helena wrote:

Frank Warmerdam wrote:

Rich Shepard wrote:

Two inconsistencies I've picked up:

1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
output file name with no warning that that file already exists, and asking
the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
tell the user that the output file name exists, does not ask for directions,
and refuses to let the user overwrite it. Recommendation: always check,
always ask, follow the user's directions.

Folks,

What would the normal mechanism be to ask the user if they want to overwrite
an existing raster layer?

r.mapcalc does it the right way, most of other programs don't

mapcalc> diff=owhusle-owhusle.rst
diff - already exists. ok to overwrite? (y/n)

Folks,

For reference, r.mapcalc only prompts if it is in interactive mode, which it
determines using "interactive = isatty(0)". It uses
"G_find_file ("cell",result,G_mapset())" to test if the raster already exists,
and G_yes() to test for a user response.

I presume it just overwrites silently if not in interactive mode.

As someone (email already deleted!) pointed out, G_parser() actually does this
sort of existance test if it prompts for the raster name, but not if supplied on
the command line. Should we look at fixing G_parser() to check for command
line arguments too instead of trying to build alot of logic into each program?

If so, should we leave this for post 5.0? I hate to make dramatic system wide
changes shortly before a release.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

6

Frank Warmerdam wrote:

Helena wrote:

>Frank Warmerdam wrote:
>
>>Rich Shepard wrote:
>>
>>> Two inconsistencies I've picked up:
>>>
>>> 1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
>>>output file name with no warning that that file already exists, and asking
>>>the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
>>>tell the user that the output file name exists, does not ask for directions,
>>>and refuses to let the user overwrite it. Recommendation: always check,
>>>always ask, follow the user's directions.
>>>
>>Folks,
>>
>>What would the normal mechanism be to ask the user if they want to overwrite
>>an existing raster layer?
>>
>
>r.mapcalc does it the right way, most of other programs don't
>
>mapcalc> diff=owhusle-owhusle.rst
>diff - already exists. ok to overwrite? (y/n)
>

Folks,

For reference, r.mapcalc only prompts if it is in interactive mode, which it
determines using "interactive = isatty(0)". It uses
"G_find_file ("cell",result,G_mapset())" to test if the raster already
exists,
and G_yes() to test for a user response.

I presume it just overwrites silently if not in interactive mode.

As someone (email already deleted!) pointed out, G_parser() actually
does this
sort of existance test if it prompts for the raster name, but not if
supplied on
the command line. Should we look at fixing G_parser() to check for command
line arguments too instead of trying to build alot of logic into each
program?

If so, should we leave this for post 5.0? I hate to make dramatic system
wide
changes shortly before a release.

definitely for post 5.0 This is not the kind of change that should be done now.

Helena

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

7

On Wed, Aug 08, 2001 at 12:47:19PM -0700, Rich Shepard wrote:

  Two inconsistencies I've picked up:

  1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
output file name with no warning that that file already exists, and asking
the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
tell the user that the output file name exists, does not ask for directions,
and refuses to let the user overwrite it. Recommendation: always check,
always ask, follow the user's directions.

I don't know if there is a correct behavior. My personal feeling is
that modules should not overwrite existing files unless explicitly told
to do so (such as with a force flag). It's much easier to handle the
overwrites with raster files than with vector files (which actually have
several related files). I don't like the idea of the prompt after
initial argument parsing because it interferes with the potential to
create graphical front-ends to commands (of course, several commands
still currently expect a terminal for post-parser input at this point
anyway).

  2) Most modules present a status indication of processing; usually the
percentage completed. Other modules (today it was r.poly) give no indication
whether they are slowly working or have silently passed away.
Recommendation: have a progress indicator for all modules.

Not always possible or meaningful. Vectors don't lend themselves to
meaningful percentages necessarily as parts can vary in size and
complexity. Also, it's not always easy to work in the G_percent() calls
without drastic rewrites of a module (and still may not be possible).
But, progress can still be indicated textually ("Doing foo..", "Doing
bar..", etc...).

--
Eric G. Miller <egm2@jps.net>

8

On Wed, Aug 08, 2001 at 09:06:39PM -0500, Helena wrote:

Frank Warmerdam wrote:

> Helena wrote:
>
> >Frank Warmerdam wrote:
> >
> >>Rich Shepard wrote:
> >>
> >>> Two inconsistencies I've picked up:
> >>>
> >>> 1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
> >>>output file name with no warning that that file already exists, and asking
> >>>the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
> >>>tell the user that the output file name exists, does not ask for directions,
> >>>and refuses to let the user overwrite it. Recommendation: always check,
> >>>always ask, follow the user's directions.
> >>>
> >>Folks,
> >>
> >>What would the normal mechanism be to ask the user if they want to overwrite
> >>an existing raster layer?
> >>
> >
> >r.mapcalc does it the right way, most of other programs don't
> >
> >mapcalc> diff=owhusle-owhusle.rst
> >diff - already exists. ok to overwrite? (y/n)
> >
>
> Folks,
>
> For reference, r.mapcalc only prompts if it is in interactive mode, which it
> determines using "interactive = isatty(0)". It uses
> "G_find_file ("cell",result,G_mapset())" to test if the raster already
> exists,
> and G_yes() to test for a user response.
>
> I presume it just overwrites silently if not in interactive mode.
>
> As someone (email already deleted!) pointed out, G_parser() actually
> does this
> sort of existance test if it prompts for the raster name, but not if
> supplied on
> the command line. Should we look at fixing G_parser() to check for command
> line arguments too instead of trying to build alot of logic into each
> program?
>
> If so, should we leave this for post 5.0? I hate to make dramatic system
> wide
> changes shortly before a release.

definitely for post 5.0 This is not the kind of change that should be done now.

Helena

I agree... Another thing to consider is that the modules shall
not query when used in scripted mode. Otherwise the automatisation
would be broken. Definitly a 5.1 issue.

Rich, other, if possible, look into

documents/parameter_proposal.txt

the mentioned overwrite story is already described there.

Markus

9

Frank Warmerdam wrote:

As someone (email already deleted!) pointed out, G_parser() actually
does this
sort of existance test if it prompts for the raster name, but not if
supplied on
the command line. Should we look at fixing G_parser() to check for command
line arguments too instead of trying to build alot of logic into each
program?

Yes.

If so, should we leave this for post 5.0? I hate to make dramatic system
wide changes shortly before a release.

Definitely.

For a start, to solve this particular issue correctly would require
the "force overwrite" flag to be understood by G_parser() itself.

And this is only the tip of the iceberg in terms of potentially
worthwhile changes to application startup. I think that we need to
undertake a comprehensive survey of the way that programs are handling
their command line, so that G_parser() itself can provide features
such as:

+ Common flags, e.g. -q (quiet), -v (verbose), -f (force overwrite).

+ Option combinations; i.e. being able to tell G_parser() that one of
a set of alternatives is required, rather than telling it that none
are required followed by the application itself checking that at least
one was provided.

+ More specific types, e.g. colour, coordinate, datum, projection,
etc, rather than just specifying TYPE_STRING and having the
application decode it. Merge the "type" field with the first two parts
of the "gisprompt" field, so that names of
{old,new,any}-{raster,vector,sites} layers are each a specific type.

+ Dynamic defaults, e.g. where the default value depends upon the
current location/mapset or on settings obtained from the current
monitor.

+ Probably many more features, which would be made clear by a survey
of the code which existing applications have surrounding the call to
G_parser().

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

10

On Wed, 8 Aug 2001, Frank Warmerdam wrote:

Rich Shepard wrote:

> Two inconsistencies I've picked up:
>
> 1) Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
>output file name with no warning that that file already exists, and asking
>the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
>tell the user that the output file name exists, does not ask for directions,
>and refuses to let the user overwrite it. Recommendation: always check,
>always ask, follow the user's directions.
>

What would the normal mechanism be to ask the user if they want to overwrite
an existing raster layer?

I would also take issue with a single policy. The R interface is currently
written to refuse to overwrite existing raster and site layers. I could
add an argument to the function in R to permit overwriting, but R
functions aren't interactive as such, so a user could set overwrite=TRUE
(default FALSE) and still clobber data.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.

11

On Wed, 8 Aug 2001, Helena wrote:

definitely for post 5.0 This is not the kind of change that should be done now.

  I agree.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                 Making environmentally-responsible mining happen.