[GRASS-dev] Re: m.distance / SWIG-Python interface + passingpointers with SWIG [was: d.measure w/ bearing]

[Michael Barton]

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