RE: [GRASS5] [bug #2238] (grass) r.series: support for wildcards in input filenames

GRASS GRASS developer
1

I did a search and found 558 uses of G_parser in the grass source.

John Huddleston

-----Original Message-----
From: Hamish [mailto:hamish_nospam@yahoo.com]
Sent: Tuesday, December 02, 2003 3:40 PM
To: Glynn Clements
Cc: neteler@itc.it; grass-bugs@intevation.de; grass5@grass.itc.it;
jhuddleston@itc.nrcs.usda.gov
Subject: Re: [GRASS5] [bug #2238] (grass) r.series: support for wildcards in
input filenames

> > > It would be nice if r.series would accept wildcards for the
> > > input maps.
> > >

...

> > That may also true for several other modules; in which case, it
> > might be better to figure out how to build this into G_parser().

...

> > > e.g.

...

then G_parser() would do glob expansion, so in Hamish' example, using:
   input=insitu_data.*
would have the same result as:
   input=insitu_data.001,insitu_data.002,...,insitu_data.052

...

The issue isn't figuring out how to implement wildcard expansion;
that's easy enough to do without using system() hacks. The issue is
deciding how to make use of it within GRASS.

I'd just point out that it should have a check against MAXFILES.
[Maybe not in this case, I haven't studied how r.series works]

Moreover, it would be good to have MAXFILES defined globally, such as
with DEFAULT_BG_COLOR, etc.

src/raster/r.patch/cmd/nfiles.h:
---------------------------------------------------------------------
/* The number of cell files that can be patched together.
*
* All cell files will be opened at one time, so this number can not
* be arbitrarily large.
*
* Must be smaller than MAXFILES as defined in src/libes/gis/G.h which
* in turn must be smaller than the operating system's limit.
* (Given by `cat /proc/sys/fs/file-max` in Linux 2.4)
*/

#define MAXFILES 200
---------------------------------------------------------------------

regards,
Hamish

2

Huddleston, John wrote:

I did a search and found 558 uses of G_parser in the grass source.

That sounds about right; every non-interactive module should use it
(although a few don't).

However, so long as we don't change existing behaviour, it will only
affect modules which are explicitly changed to use the new features.

[Aside: The G_parser() API (including G_define_option() and
G_define_flag()) is quite well suited to extensions; one can add new
fields to "struct Option" and "struct Flag" without having to change
all of the existing modules.]

My suggestion is to add a new type, e.g. TYPE_MAP, which would behave
like TYPE_STRING, except that G_parser() would do glob expansion on
existing map names when opt->multiple is set. r.series, r.patch and
r.out.mpeg would be prime candidates for using this extension. Such
modules would just need to use the new type.

Actually, there are prior suggestions for expanding the set of types
which G_parser() recognises. One of them is to have e.g. TYPE_OLD_MAP
and TYPE_NEW_MAP. Both would behave like TYPE_STRING; however,
TYPE_OLD_MAP would require that the map already exists (allowing
errors to be handled automatically by G_parser()), while TYPE_NEW_MAP
would require that the map doesn't already exist. In both cases, the
names would automatically be checked for legal names with
G_legal_filename().

TYPE_NEW_MAP is potentially problematic, as one might want to provide
an option to allow existing maps to be overwritten. However,
TYPE_OLD_MAP is straightforward enough. OTOH, it would be better to
have distinct types, e.g. TYPE_OLD_RASTER, TYPE_OLD_VECTOR etc.

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