[GRASS5] Zoom

[Glynn Clements]

Radim Blazek wrote:

> > Hmm. I see some utility in being able to flag whether the datasource
> > will be used for input, output, or input and output.  Pretty much every
> > module has to go through a bunch of checks for this, so why not have the
> > parser handle it?  The behavior might change if we move away from only
> > being able to edit/write data in the current mapset.
> 
> I think, that most of modules, should not open vectors for update
> (input and output, if I understand you well). Then data may not be lost,
> if module crashes or incorect parameter is specified. The only 
> module which should update old vector is v.digit.
> 
> I agree, that some checks should be done by parser, but some probably
> by *_open(). Typically:
> 1) map existence should be checked by parser and error printed, if necessary 
> 2) error should be reported by *_open(), if it fails to open the map

More generally, most library functions should just call
G_fatal_error() whenever an exceptional condition occurs, rather than
returning NULL/0/1/-1/non-zero or whatever.

It is possible to define a fatal error handler, so programs which need
to continue in the presence of errors can do so.

> I don't know, on which level should be checked, if the new map already exist,
> (that needs some system, how to tell to parser/open function, if should 
> a)work interactively (ask what to do), b) overwrite or c) quit.

I have wondered if it would be worth having the parser handle certain
flags and options automatically. In this case, having it recognise
"-o" as an indication to overwrite existing output maps.

Other special flags might include -v and/or -q for verbose/quiet
operation; this would automatically affect G_percent(), plus a
hypothetical G_message() function, and maybe G_warning().

Special options might include "dbase=", "location=" and "mapset=".

> > > V_CATS may be something like '1,3,7-9,11' and may be parsed by
> > > Vect_str_to_cat_list (char *str, struct cat_list *list);

OK; I wouldn't expect applying a generic "list" constructor to the
primitive "category" type to handle that. But you could have a
primitive "category range" type, and have "list of category range" as
a derived type.

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