[GRASS-dev] GRASS startup window patches

Paul Kelly paul-grass at stjohnspoint.co.uk
Sat Jan 6 06:27:35 EST 2007


On Sat, 6 Jan 2007, Glynn Clements wrote:

>> as Tcl falsely
>> assumes a command that writes to stderr is issuing an error. This applies
>> to g.proj too. If partially-specified datum information is passed to
>> g.proj, it WILL try to interactively prompt the user for complete
>> information. This is done by printing to stderr and looking for an input
>> on stdin.(The Tcl catch command will treat this as an error.) There are
>> also circumstances where g.proj will issue a warning (but still proceed to
>> create the location OK), and again this writes to stderr and the catch
>> command will erroneously assume there is an error.
>
> No, it's exec which treats it as an error; the catch command catches
> the exception which exec throws so that it doesn't terminate the
> program.

Yes that's right of course - what I was getting at was gis.m treats it as 
an error really - it skips over what it was supposed to be doing, so in 
general it stays running but is an undefined state as some variables 
haven't been set and you need to re-start it to get back to doing 
something useful. But not a lot that can be done about this.

>> I think, until we can work out some way of always passing fully specified
>> datum information to g.proj, that when g.proj is used for location set-up
>> we should run it in a pop-up terminal Window. So if it does choose to
>> prompt the user it (while kludgy and archaic-looking) will actually work.
>
> What is the problem with simply removing the "interactive" parameter
> from GPJ_{osr,wkt}_to_grass()?

Because then, if there is partially-specified datum information, a (likely 
sub-optimal) default set of datum parameters must be used. I tried to 
explain this here: 
http://www.nabble.com/g.proj-and-datum-information-%28and-gis.m%29-t2484411.html#a6928102
and haven't come up with an easier solution since then. All I can say that 
if, either no datum information at all, or fully specified (i.e. datum 
name and parameters) are passed to g.proj as part of the input co-ordinate 
system description, then it won't attempt to interactively prompt. IMHO 
perhaps we need to look at ways the GUI can verify that the datum 
information is complete before it attempts to create the location? I 
really don't know what's best.

Paul




More information about the grass-dev mailing list