[GRASS-dev] GRASS startup window patches

[Michael Barton]

>From the point of view of someone who needs to use this GRASS module in an
external scripting environment, I agree with the proposal here.

Michael


On 1/6/07 7:04 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Paul Kelly wrote:
> 
>>>> 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.h
>> tml#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.
> 
> Regardless of what's best, interactive prompting is worst.
> 
> I don't have a problem with an approach where anything which isn't
> explicitly specified gets a default value. IMHO, what really matters
> is that the user has some way to provide this information; it's not up
> to us to force them to do so.
> 
> If using a default isn't considered acceptable, then missing
> parameters should result in an error, not terminal interaction.
> 
> As it stands, if you want g.proj to ensure that the defaults aren't
> used, it should just be a matter of ensuring that the proj4= option
> contains either towgs84= or nadgrids=, no?
> 
> However, I would favour replacing the GPJ_ask_datum_params() call in
> GPJ_osr_to_grass() with G_fatal_error(). In the absence of complete
> datum information, the choice provided by the "interactive" parameter
> would then be default-vs-error rather than default-vs-prompt.
> 
> This would eliminate the need to modify g.proj.
> 
> Prompting assumes the existence of stdin, and in most cases[1]
> assuming the existence of stdin is a bug.
> 
> [1] The main exception being when the user explicitly requests the use
> of stdin. Libraries should *never* use stdin.
> 
> Apart from GPJ_osr_to_grass(), the only other use of
> GPJ_ask_datum_params() is in g.setproj, which is still a complete
> mess. A fair amount of it could be made non-interactive by changing
> the functions in get_num.c to obtain the requested parameter from a
> key=value list rather than prompting for it. Most of the mess is due
> to all the hard-coded special cases.

__________________________________________
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