[GRASS-dev] GRASS startup window patches

[Glynn Clements]

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

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.

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