On Mar 4, 2008, at 4:50 AM, Patton, Eric wrote:
This means that for the specific issue at hand, i.e. d.measure with
bearing, I strongly plead for adding the possibility of giving
start /
end coordinates as parameters to the module. This would then allow
other
uses beyond the wxgrass gui such as web apps, shell scripts, etc.
As I have mentioned before, I am afraid that slowly but surely the
wxgrass gui will multiply functionality which is only available
via the
gui, but should, in my eyes, also be available from the command line.
I'm thinking of things like profiling, measuring, etc.
Moritz
I agree; the ability to use and script modules on the command line
is a
key feature that I rely on. GUI lock-in of certain features would
really
be frustrating.
~ Eric.
This is why we should have a non-interactive version of d.measure.
We've been slowly getting non-interactive versions of key command
modules over the past couple years. A command that returns the
distance between two xy coordiates would be useful. As I said
earlier, modifying d.measure (or as Hamish has suggested, creating a
new m.measure) would be desirable.
FWIW, there are already 2 non-interactive profiling commands that can
be used in scripts that have existed for a long time, r.transect and
r.profile. The GUI (both TclTk and wxPython) simply display the
results of running r.profile. As far as I am concerned, this is the
ideal model: a GRASS command that can be used in scripting, also used
in a GUI script to produce an interactive display.
The issue is not that we are losing functionality to a GUI. It is the
difference between a command that returns a new map (or other file,
such as a graphic image) or returns information, and a command that
has a hard-coded interactive interface built in. When GRASS was first
developed, there weren't any widely used, easy ways to control an
interactive interface. So a suite of commands were developed in which
interfaces were hard-coded into the modules. Because this was done,
we are still dealing with 20-year-old interface design and it's
headaches (e.d., i.orthophoto). I agree with Glynn that we are better
off in terms of current and future flexibility to use a dedicated GUI
scripting platform that sits on top of GRASS to create the
interactive user interface and handle interactive displays. This is
much easier to update as the technology changes (e.g., moving from
TclTk to wxPython).
This does not mean getting rid of GRASS commands. It simply means
that we need to take the hard-coded interactive interfaces out of
GRASS commands so that you can type them on the command line and they
run without further intervention on the part of the user. In fact,
this makes them much easier to script (e.g., you can't script
i.orthophoto or i.points). Tightly coupling command line tools and an
interactive interface in the same module limits both ways of
manipulating GIS data. There are simply some things you can do in a
good GUI that you can't do with commands and vice versa. You can't
drag a box to zoom a display on the command line--but you can enter
extents into g.region and have the same computational result. For
profiling, r.profile returns detailed information on the elevations
between a series of xy points. This information can be viewed and
manipulated in a variety of ways. You could drop it into a
spreadsheet or gnuplot and plot it, for example. The GUI provides a
visually appealing, interactive way to access this information. That
is what it supposed to do, but doing this does not decrease the
functionality or value of the underlying command that produced the
information.
Michael
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
