[GRASS-dev] RFC: Module Option Parser

[Brad Douglas]

On Fri, 2006-12-15 at 09:22 +0000, Glynn Clements wrote:
> Brad Douglas wrote:
> 
> > I'm in the process of updating/upgrading the imagery libraries and
> > modules.  I have run into a problem which I wish to simplify, but would
> > require modification of lib/gis/parser.c, etc.
> > 
> > I think we can all agree that i.ortho.photo is a mess and hasn't been
> > able to evolve as the rest of GRASS has.  I want to remove as much
> > interactivity as possible, but that creates a dilemma:
> > 
> > A) I can break i.ortho.photo into 7-8 separate modules, or
> > B) I can make it a single module by using the following structure:
> 
> I strongly favour option A; see below.
> 
> > Option A does not set well with me and Markus has agreed, privately, due
> > to the ever growing list of GRASS modules, so I need something a bit
> > 'better'.
> > 
> > - Create an Option that allows to select from a series of commands like
> > v.build does:
> > 
> >     tool_opt = G_define_option ();
> >     tool_opt->key         = "tool";
> >     tool_opt->type        = TYPE_STRING;
> >     tool_opt->required    = YES;
> >     tool_opt->multiple    = NO;
> >     tool_opt->description = _("The ortho tool to use:\n"
> >                 "\t\ttarget    - Target imagery location and mapset\n"
> >                 "\t\tdem       - Digital Elevation Model (elevation)\n"
> >                 "\t\tcamera    - Camera parameters\n"
> >                 "\t\ttransform - Transformation parameters\n"
> >                 "\t\texposure  - Exposure parameters\n"
> >                 "\t\tparams    - Ortho photo parameters\n"
> >                 "\t\trectify   - Rectify the ortho photo");
> >     tool_opt->options     =
> > "target,dem,camera,transform,exposure,params,rectify";
> > 
> > ...but alter it a bit, namely changing the first line to:
> > tool_opt = G_define_selection(), a new function.
> > 
> > In order to make this work and keep the many options from spamming
> > i.ortho.photo --help (as many of the above selections have multiple
> > options that are not related to each other), I would like to propose the
> > following changes:
> > 
> > - Create a new function: G_define_selection ();
> > - Add another option to G_define_option () that would link an option to
> > a selection:
> >     dem_opt = G_define_option ();
> >     dem_opt->key           = "dem";
> >     dem_opt->type          = TYPE_STRING;
> >     dem_opt->required      = NO;
> >     dem_opt->multiple      = NO;
> >     dem_opt->description   = _("Digital Elevation Model");
> > --> dem_opt->selection     = "dem";   <--- new option
> > 
> > So...when I do 'i.ortho.photo --help', I get a list of selections to
> > choose from.  When I do, 'i.ortho.photo select=dem --help', I only get a
> > list of options associated with the "dem" selection (ie. dem_opt).
> > 
> > Comments, suggestions, and better ideas are always welcome.
> 
> Extending the infrastructure for a single module is normally a clue
> that the problem is with the module.

I may have had i.ortho.photo in mind, but I intentionally tried to make
it extensible to other modules.

Modules that could readily benefit (by no means a complete list):
v.distance
v.lidar*
v.lrs*
v.net*
r.resamp*
v.surf*
r.li*
r.le*
r.support*

> If most of the options only apply to a specific "mode", that suggests
> that each mode should be implemented as a separate module. If they
> share common code, make it a library.

I disagree.  Currently there are about 150 raster and 65 vector modules.
The list is not shrinking and becoming a bit unwieldy.

Either way, I don't want to waste a whole lot of time discussing this.
I made my best case.  If option A still looks like the best route, then
that's what I'll do.


-- 
Brad Douglas <rez touchofmadness com>                    KB8UYR/6
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785