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

[Glynn Clements]

Paul Kelly wrote:

> > I can confirm this bug.
> >
> > Problem is - this EPSG code requires aditional user input from comand
> > line - just try to run "g.proj -c proj4=+init=epsg:2258
> > location=EpsgBug" whithin GRASS session and g.proj will ask for
> > aditional parameters. As current tcl/tk code does not open xterm for
> > g.proj operations, it stucks on waiting user input from nonexisting
> > xterm app.
> 
> The attached patch will run g.proj in a terminal Window in case it needs 
> to prompt for user input. I think it is a good workaround for the time 
> being?

I think that "good workaround" is an oxymoron; workarounds have a
habit of relieving the pressure to actually fix the bug.

> > IMHO this should be fixed in g.proj first to make it independend from
> > interactive comandline usage and then startup screen can be fixed to
> > use new g.proj feature.
> 
> 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).

It isn't ideal, but it's a lot less non-ideal than assuming that a
terminal is available.

Also, note that g.proj already silently uses the default parameters if
you read the settings from stdin with wkt=- or proj4=-, so it isn't as
if we currently *insist* upon full datum information being provided.

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