[GRASS-dev] Need to update g.setproj

[Paul Kelly]

Hello Michael and Glynn
Glad to see this has finally become a show-stopping bug to force some 
discussion of it ;)

Michael Barton wrote:
> Paul,
>
> Thanks for the detailed reply. The larger problem is that Windows and Mac
> 'native' (i.e., aqua) platforms don't use an xterm. So I don't see how we
> can require interactive xterm use. It can be an optional way to run the
> module if you are using a terminal, but we also need to be able to achieve
> the same function without this.

Well yes what I was proposing was that interactive use need not require an 
interactive terminal window, if we create some functions that abstract the 
interactive prompting from the module so it doesn't care whether it is 
being run from the command-line user interface or a graphical user 
interface; all it does is let the user know what options are available and 
receive the user's response.

> What I suggest is simply that the module fail with a meaningful error
> message (e.g. "You must enter a datum transformation for this projection")
> if the proper combination of parameters are not set in the end. It is fairly
> straightforward to do the interactive part in a GUI platform like TclTk or
> wxPython. Users would be prompted for different options depending on which
> other options they chose. That is, different options would be presented for
> wgs84 UTM than for NAD83.

That just doesn't seem elegant to me. E.g. suppose somebody wanted to 
write a different GUI to call g.proj (there are several GRASS GUIs about) 
then all this interactive prompting functionality would have to be 
re-implemented in that GUI too. E.g. in GRASS already g.proj is called 
both from the start-up screen and gis.m I guess.

> To do this, however, it must be completely runable from the command line,
> with no interaction required. This takes considerable burden of the
> underlying C module. Don't worry about dropping the xterm interaction that
> is already there. People can continue to use it if desired. We just need an
> alternative mode that does not require it. The latter could be turned on and
> off by a flag, for example.

But the interactive prompting and converting of user input forms the vast 
bulk of what g.setproj does. Really what you are proposing is duplicating 
this functionality in a new Tcl/Tk module. I just thought it would be nice 
(to avoid code repetition, easy to fix bugs etc.) if the command-line 
interactive and GUI interactive versions of a module could be combined in 
one place using (as yet non-existent) interactive input functions 
abstracted from the user interface.


On Thu, 28 Sep 2006, Glynn Clements wrote:

> Paul Kelly wrote:
>
>> Specifically, the GPJ_osr_to_grass() function called in g.proj needs
>> some way of interacting with the user if (and only if) the datum isn't
>> fully specified in the input co-ordinate system description (EPSG code,
>> input georeferenced file or anywhere else. r.in.gdal and v.in.ogr have
>> the same problem.) It achieves this by calling GPJ_ask_datum_params(),
>> which prompts the user in the traditional GRASS way (Enter to cancel,
>> "list" to list options etc.) There is no way to determine in advance
>> (before running the module) what options might be needed here. What we
>> really need is a library for interactive input from the user. E.g. a
>> function to set the question, functions to prompt for a yes/no answer,
>> or functions to list the possible answers and prompt to use one. A
>> little bit similar to vasklib as it is currently, but nowhere near such
>> a rigid structure.
>
> I disagree. All functionality should be available in a non-interactive
> manner for cases where there isn't a user available.

Well GPJ_osr_to_grass() has an "interactive" flag, which if set to 0 will 
use the "default" parameters for the datum conversion instead of 
prompting. This mode is used when the output is non-vital, e.g. r.in.gdal 
compares the projection of an input map with the current location to check 
they match. But there really is no such thing as default datum 
transformation parameters and in the case of setting up a new location, 
it's likely to lead to bad data IMHO if the user knows no better and 
assumes GRASS has set up everything for them perfectly. So for the case of 
g.proj, it calls GPJ_osr_to_grass() with the interactive flag set, to 
force interactive prompting and force the user to make a decision on which 
are the best datum parameters to use for their area.

Are you suggesting this prompting be the responsibility of the GUI before 
it runs the module? Would it not then need to be cloned for every 
different GUI? And make prior knowledge of all the parameters for the 
datum etc. a pre-requisite for using the module from the command-line?

A flag could be added to g.proj/g.setproj to call GPJ_osr_to_grass() in 
non-interactive mode, but that really would just be ignoring the problem I 
feel.

> For the time being, the ability to provide a
> list of key/value pairs for projection-specific options will have to
> suffice.

Well you can more or less do that already, if you pass the parameters to 
g.proj as a PROJ.4-style string. If the datum parameters are fully 
specified it will not prompt for them.

> In the longer term, the lack of metadata within PROJ itself is a
> long-standing problem which doesn't look like it's going to get fixed
> any time soon. In that situation, the only option is to maintain our
> own database of projections which includes the required and accepted
> options for each projection.

Well personally, if I had any time to spend on such an effort (currently 
unlikely) I would be more likely to offer it as a contribution to the PROJ 
distribution than to try and improve the GRASS implementation (in the 
hope of course that the GRASS implementation could be replaced by the PROJ 
one): both because I feel the current GRASS implementation is a mess not 
worth improving, and because I know from previous discussions on the PROJ 
list that there is a demand for such a thing.

Paul