[GRASS-dev] Need to update g.setproj

[Paul Kelly]

Hello Michael
Michael Barton wrote:
> G.setproj is a critical GRASS module because it is the primary way to 
> create new locations that GRASS must have to run.
> 
> However, because it requires an interactive x-terminal, g.setproj will 
> not work with the native winGRASS. It will not work with a non-x11 aqua 
> Mac GRASS. Nor will it work with the wxPython interface under development.
> 
> This was brought home in a recent GRASS workshop for graduate students 
> here when no one using Windows could create a new location in the normal 
> way. Using EPSG codes also currently bombs under winGRASS, presumably 
> because somewhere it needs an xterm.

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.

The actual interaction with the user should be abstracted behind the 
library functions and not of concern to the developer of the module. My 
thinking is if the user is running a text-based session (i.e. 
GRASS_UI_TERM variable set) they would be prompted in the traditional 
way (Enter list to list choices etc.) or if they're using a Tcl/Tk based 
GUI then a Tcl/Tk dialog window would pop up with a drop down list of 
choices, check boxes/ radio buttons or whatever is appropriate. If the 
GUI used had a C API this mightn't be a *huge* task actually. I have a 
tiny little bit of experience with Gtk and it looked fairly easy to 
construct a dialog window with those sorts of options. Although I don't 
have a clue how you'd do it with Tcl/Tk. Perhaps the window that pops up 
when you start a command from the GUI, showing all the parser options, 
is a clue though.

> So we REALLY need a non-interactive version of g.setproj. You should be 
> able to put in the same parameters that you do in the interactive 
> version: datum, datum transform option (if any), extents, and 
> resolution. This should be pretty easy to do (I say as a someone who 
> doesn’t know C). Because the datum and datum transform come from text 
> files in $GISBASE/etc, it should be pretty easy to make a GUI scrollable 
> list from these files. The extents and resolution are typed in by the user.
> 
> Is there anyone who can make g.setproj accessible as a command-line 
> module without needing an interactive xterm? I can make up a quick TclTk 
> GUI to go with it.

What you describe above will require some interaction anyway, because 
later prompts tend to be based on earlier choices. I don't agree that a 
non-interactive g.setproj is the solution - as said above my preferred 
option is to make a way of having interactive modules be compatible with 
the GUI. I think this could benefit other modules too. E.g. I really 
miss interactive mode in g.region. It's nice to just fire up a module 
and enter the choices it prompts you for rather than having to work 
everything out in advance, run the module and hope for the best!

A wider issue is the whole big ugly way g.setproj determines which 
parameters each projection needs with the G_geo_* functions in libgis. 
Very ugly, inflexible and actually doesn't handle things totally 
correctly with projections that can have their parameters expressed in 
more than one way (e.g. lcc). It's a long-term project to sort this one 
out and there'd be no point in re-writing g.setproj without sorting that 
out first. Hopefully a re-write of the PROJ.4 library in the long-term 
might produce a function that could be called to list the parameters 
required by each projection. That would be a major step forward.

Paul