[GRASS-dev] Re: gui startup bug (new locn by epsg code)

[Glynn Clements]

Paul Kelly wrote:

> >> How do you propose it is fixed? It is arguable IMHO that the problem is
> >> not in g.proj. It will only interactively prompt if *partially complete*
> >> datum information is passed to it. If the GUI passes projection
> >> information that has been pre-processed so the datum part is OK, then it
> >> will not interactively prompt. This was discussed in an earlier thread.
> >
> > Yes, and I proposed a solution: replace the call to
> > GPJ_ask_datum_params() with either a call to G_fatal_error() or some
> > form of error indication (e.g. "return -1"). Assuming the availability
> > of a terminal to obtain missing data from the user is a bug in
> > GPJ_osr_to_grass().
> >
> > Unless someone else proposes an alternative solution soon, I intend to
> > change GPJ_osr_to_grass() to simply ignore the "interactive"
> > parameter; if datum parameters are missing, you get the defaults; it
> > will be up to the user to fix it afterwards. That approach has the
> > advantage that it doesn't require any changes to calling programs
> > (g.proj, v.in.ogr, r.in.gdal).
> 
> If it has to be done I wouldn't like to see the functionality to choose 
> datum parameters from the tables in GRASS relegated to only g.setproj.
> I was thinking along the lines of adding a new "interactive" flag to
> g.proj.

That takes us back to the issue of the GUI needing to determine
whether or not a module is interactive. It's bad enough that modules
don't report (via --tcltk, --interface-description, etc) whether or
not they are interactive, but that can be fixed easily enough[1].

What can't easily be fixed is modules which are either interactive or
not depending upon the specific combination of flags and options; how
is a module supposed to communicate that information to the GUI?

[1] I was planning on adding an "interactive" field (and possibly
"xmonitor" or similar) to struct GModule, so that interactive modules
would do e.g.:

	module = G_define_module();
	...
	module->interactive = YES;

This information would then be passed to the GUI so that it knows that
the module requires a terminal.

> If this flag was specified along with -p, -j, -w or -c it would prompt as 
> at present if datum information was incomplete; if used along with the -d 
> flag then after reporting the datum information it would ask the user if 
> he/she wished to change the parameters.
> 
> And every other place that calls GPJ_osr_to_grass() or GPJ_wkt_to_grass() 
> (I'm thinking of r.in.gdal and v.in.ogr and g.proj without the 
> -i/interactive flag specified) would set the interactive flag in the 
> function to 0.

IMHO, the right way to do this is to simply remove the interactive
flag from those functions, and leave it to the caller to update the
datum transformation if necessary.

g.setproj is at least consistent: it is interactive to the core, and
calls GPJ_ask_datum_params() directly. Other modules (i.e. g.proj,
r.in.gdal and v.in.ogr) should:

1. Provide an option to allow the user to specify any additional
parameters, e.g. "projparms=nadgrids=conus".

2. If complete information isn't provided by either the source data or
the aforementioned option, either:
a) use the default values and print a warning, or
b) generate an error indicating that you must manually specify either
nadgrids or towgs84 via the option.

-- 
Glynn Clements <glynn at gclements.plus.com>