[GRASS-dev] Need to update g.setproj

[Michael Barton]

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.

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.

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.

Michael
__________________________________________
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



> From: Paul Kelly <paul-grass at stjohnspoint.co.uk>
> Date: Thu, 28 Sep 2006 08:53:09 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: GRASS-DEV <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Need to update g.setproj
> 
> 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