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

[Michael Barton]

First, Paul I truly appreciate your work on trying to find a way for the
TclTk GUI to deal with the xterm interaction in g.proj. This is certainly an
improvement over having the interface simply lock up mysteriously (and
thanks to Maris for discovering the cause of this so quickly).

That said, I have to agree with Glynn on the long term way to fix this. Any
module that depends on question/response interaction with a user via an
xterm is going to be problematic on any GUI that does not also depend on an
xterm. Given the limitations of the display technology in the older GRASS
xterm protocols, I agree that we should aim to stop depending on it.

A failure with an informational error message or using a set of defaults,
with a warning output to the user that some projection parameters are
lacking, should be as good as question/response in an xterm. This keeps the
projection process transparent, doesn't let the user enter incorrect or
incomplete information without being informed that he/she is doing so, and
doesn't run the risk of hanging an interface wrapped around GRASS. It is
also much better for scripting, where you don't want your script to hang
while waiting for user input from a non-existent xterm.

Finally, if the EPSG file contains incomplete projection information for
some entries, shouldn't that be fixed with whoever supplies this file? If
this becomes a useful way to create locations in GRASS, it needs to be an
accurate and complete list of projection parameters.

My 1.5 centimos worth...

Michael


On 1/30/07 3:45 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> 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.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton