Paul Kelly wrote:
> Personally, I'd rather modules which are supposed to be
> non-interactive (e.g. r.in.gdal) were fixed so that they really were
> non-interactive. The pervasive assumption that a module can fall back
> to communicating with the user via a terminal is the biggest issue
> standing in the way of a decent GUI for GRASS.
r.in.gdal requires user input if it is creating a new location based on
the co-ordinate system associated with an external dataset *and* the
datum specified in that co-ordinate system has more than one possible
set of transformation parameters. There is no way to automatically
determine which set is most appropriate; it depends on several factors,
most notably what part of the country the dataset is situated in.
So allow the user to specify it as a command-line parameter, and fail
if it is required but not provided. Ideally, the error message should
enumerate the valid options.
To make a non-interactive guess or assumption would be lulling the user
into a false sense of security and might result in loss of accuracy
later if the most appropriate set of datum parameters had not been
chosen. IMHO the best way around this is to provide the user with all
the information available about the various sets of transformation
parameters and let him or her choose the most appropriate set for the
area. As there is still no GRASS library for user interaction like this
the most foolproof way of doing it remains the traditional interactive
terminal approach.
Hence the problem as outlined previously.
Perhaps the best thing to do for now (although controversial I'm sure)
might be to remove the capability to automatically create a new location
from r.in.gdal and v.in.ogr, leaving g.proj as the only module with the
capability?
IMHO, creating a new location and importing a raster map are such
fundamentally different operations that they don't belong in the same
binary.
The task of creating a new location should probably be moved to e.g.
g.newlocation.gdal.
[More generally, there should be g.* commands for managing locations
and mapsets, i.e. creation, deletion, copying, renaming.]
There could be multiple Tcl/Tk GUI entries for g.proj: one
of them could be specifically for creating a new location based on the
co-ordinate system associated with an existing external dataset and this
could be forced to always spawn a terminal (although it still sometimes
wouldn't be needed, e.g. when creating a WGS84 location where there is
only one possible set of datum transformation parameters). This
functionality should probably also be added to the start-up screen. But
I know virtually nothing of the GRASS GUI especially the recent
improvements.
One of the main limitations is that it doesn't cope well with programs
which have different "modes", i.e. substantially separate functions
bundled into a single program (although arguably such situations
suggest a design flaw in the program itself).
In particular, if a program has an interactive mode, the only way that
the GUI can handle this is to always launch the program in a terminal.
There's no way that a program can inform the GUI that it is
interactive only for certain combinations of arguments.
This isn't just an issue for the GUI. It applies equally to scripts,
web interfaces etc. Falling back to prompting the user makes life easy
for the programmer, but it can substantially reduce the usefulness of
the program.
--
Glynn Clements <glynn@gclements.plus.com>