[GRASS-dev] Need to update g.setproj
paul-grass at stjohnspoint.co.uk
Thu Sep 28 03:53:09 EDT 2006
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.
More information about the grass-dev