[GRASS5] Zoom

[Radim Blazek]

I must clear up, what G_define_standard_option() is. 
It just calls G_define_option() and defines what is in g50 usually
done in modules (and repeated many times):

      Opt = G_define_option();
      case G_OPT_R_INPUT:
            Opt->key          = "input";
            Opt->type         = TYPE_STRING;
            Opt->required     = YES;
            Opt->gisprompt    = "old,cell,raster";
            Opt->description  = "Name of input raster";
            break;

No new types are added to parser, sorry if I made confusion.

On Friday 03 May 2002 02:33 am, Eric G. Miller wrote:
> > No it is only old map for modules which dont have output (like d.vect).
> > (BTW, I think that input could be always input=, but map= is already
> > used in g50 and it seems to me that others want this distinction?)
>
> 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

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.

Instead of: ---------------------------------------------------------------->
    vectfile = G_define_option();
    vectfile->key               = "map";
    vectfile->type              = TYPE_STRING;
    vectfile->required          = YES;
    vectfile->multiple          = NO;
    vectfile->gisprompt         = "old,dig,Vector";
    vectfile->description       = "vector file";
...
    if (NULL == (mapset = G_find_file2 ("dig", vectfile->answer, G_mapset())))
    {
        sprintf (errmsg, "Could not find file '%s'", vectfile->answer);
        G_fatal_error (errmsg);
    }
...
    level = Vect_open_old (&Map, vectfile->answer, mapset);

    if (level < 1)
        G_fatal_error ("File open failed");
 
    if (level < 2)
    {
        fprintf (stdout,"\n");
        fprintf (stdout,"v.support has not been run.  \n");
        fprintf (stdout,"\n");
        exit (1);
    }

should be enough: ---------------------------------------------------------->
    vectfile = G_define_standard_option(G_OPT_V_MAP);
    Vect_set_open_level (2);
    Vect_open_old (&Map, vectfile->answer, "");
----------------------------------------------------------------------------- 

> > 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);
>
> Well, maybe something more generic like numeric list, with flavors for
> integers and floats?  

Of course, it would be better, if somebody writes that functions in gislib,
I'll use that for vectors :)

> Is "struct cat_list" a new addition, or just for example?

Addition, defined in grass51/include/vect/dig_structs.h
struct cat_list
  {
    int field;        /* category field */
    int *min;         /* pointer to array of minimun values */
    int *max;         /* pointer to array of maximum values */
    int n_ranges;     /* number ranges */
    int alloc_ranges; /* allocated space */
  };

Radim