[GRASS-dev] GRASS startup window patches

[Paul Kelly]

On Sat, 6 Jan 2007, Glynn Clements 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.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?

That's right. The g.proj -d output (although I was thinking of removing 
it) already provides detailed information on the datum-related component 
of any input co-ordinate system. It might be useful if this was 
re-organised a bit and then another flag was added that would list the 
possible choices of datum parameters for a particular input co-ordinate 
system? Maybe the GUI could then run a couple of pre-processing steps 
using g.proj with different flags to determine if extra datum information 
was required, and get the user to select a particular set of parameters. 
How to merge them in with the user-provided co-ordinate system may not be 
easy though (it seems if proj4="+init=epsg:1234 +towgs84=1,2,3" is used, 
the PROJ-string parser in OGR ignores anything else once it has found a 
+init key). But we could maybe work around that.

And then it would be more acceptable to fail with G_fatal_error if 
the datum information is not set (the "interactive" parameter in 
GPJ_osr_to_grass() would become a "fatal error" parameter). Maybe offer an 
extra flag to g.proj that the user could specify on the command-line to do 
interactive prompting (this would have to be moved out of the library 
function and into g.proj though).
It's one possible option anyway.