[GRASS5] Re: Developing a New Grass UI

Sun Nov 6 23:35:52 EST 2005

Good points. 

I'd proposed to keep the GUI scriptable (nviz is scriptable currently) but
not rely on separate commands for each display/visualization function.

In your example, you would still use d.rast, d.barscale, etc. But d.mon,
d.zoom, and even d.what.rast would not be useable.

Here the division would be between operations that create map layers
(d.rast, d.grid, a non-existent d.volume, etc.) and those that strictly
manipulate the display (d.mon, d.zoom, etc).

If we can seamlessly integrate 2D and 3D visualization (something that would
make GRASS a real standout), however, keeping the current layer creation
commands like d.rast become more complicated because you have to provide
options to control tilt, z-exaggeration, aspect, etc. for each such command.

By scriptable, I was thinking of a structure  whereby you could specify
'display the following layers as 2D' followed by a list of layer items and
their options; or 'display the following layers as 3D with the 3D display
options...' followed by a list of layers.

This way you are issuing a set of commands to the UI, rather than having the
UI run a set of independent display commands, a subtle, but significant
difference.

This is more or less what you can do with nviz now.

How would this work for you?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: David Finlayson <dfinlays at u.washington.edu>
> Reply-To: <dfinlays at u.washington.edu>
> Date: Sun, 06 Nov 2005 20:16:18 -0800
> To: Michael Barton <michael.barton at asu.edu>
> Subject: Re: Developing a New Grass UI
> 
> By moving visualization into the gui, how do you do things like set up
> image servers where you may need to routinely automate map production?
> For example, satellite data that is routinely post-processed in GRASS
> and then posted to a server for distribution. You may want to add map
> titles, graticule, north-arrows, scale bars etc (in short make a map).
> But you certainly don't want to do this by hand for each image!
> 
> I use a similar automated work flow to make maps out of model output
> (dozens of runs at a time) where consistency between images is
> important. We do much more of this type of thing in ArcInfo where the
> output runs into the thousands of images at a time. This particular
> example is where we went back to ArcInfo after frustrations with map
> templates in ArcGIS (still required a mouse to load the images into
> the template).
> 
> - David
> 
> On 11/6/05, Michael Barton <michael.barton at asu.edu> wrote:
>> David,
>> 
>> I'm copying this to the developer's list because your comments are well
>> thought out and (I suspect) express well the outlook of an important segment
>> of the GRASS user community, particularly developers and those who use GRASS
>> on a daily basis.
>> 
>> I agree wholeheartedly that it remains important to maintain the CLI for GIS
>> operations in GRASS for many of the reasons you point out, including
>> automation and scripting that solve problems not considered during GUI
>> development. This flexibility gives GRASS additional functionality.
>> 
>> However, I think operations now carried out through commands like d.mon
>> select=X0 and d.zoom map=[name] can be handled much better via an
>> interactive GUI. I feel the same is true for commands like d.rast and
>> d.vect. Building display control into the GUI makes it more flexible than if
>> it must issue a set of commands whenever you want to do something as
>> apparently "simple" as see a map or select a window. That is, a program the
>> includes graphic displays is easier to work with--by al--if the complexities
>> of such display operations operate largely behind the scenes. There are also
>> programming advantages to controlling the display directly from the GUI
>> rather than via an intermediary set of commands. IMHO, NVIZ is much more
>> flexible and functional than trying to use a GUI to run the GRASS 5.x d.3d
>> command. Graphics and CAD programs may retain a CLI to process images and
>> drawings, but by and large display control is through on-screen manipulation
>> of some kind--for good reason.
>> 
>> Where we make the distinction between direct GUI control and commands that
>> can be called directly through the CLI (and optionally through a menu) is an
>> important issue to discuss. For myself, I'd make the cut between
>> manipulating files/processing spatial and attribute data/analyzing
>> data/spatial operations/etc and visualization/display control/digitizing.
>> The first group would be CLI with optional access via menus (as we have
>> now). The second group would be integrated into the GUI (like in NVIZ or
>> QGIS). Attribute data management would be a hybrid: accessible via CLI SQL
>> and GRASS data management modules and via a more interactive
>> spreadsheet-like interface distinct from the display GUI. But that is my
>> opinion given my experience using GRASS, GIS in general, other programs, and
>> many years on a Mac. While I can appreciate the power of R, I'd much rather
>> use JMP in my own research. Others may well see it differently. This is the
>> reason for asking for input.
>> 
>> Thanks very much for your insightful comments. This kind of response if very
>> helpful.
>> 
>> Michael
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution and Social Change
>> Arizona State University
>> Tempe, AZ 85287-2402
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
>> 
>>> From: David Finlayson <dfinlays at u.washington.edu>
>>> Reply-To: <dfinlays at u.washington.edu>
>>> Date: Sun, 06 Nov 2005 19:08:22 -0800
>>> To: <michael.barton at asu.edu>
>>> Subject: Developing a New Grass UI
>>> 
>>> Michael -
>>> 
>>> I noticed a thread at gmane.comp.gis.grass.devel (I am not a list
>>> member) about a road map for a new GRASS UI and thought that I would
>>> chime in (this is long).
>>> 
>>> Right now the GUI is an afterthought in GRASS and new users face a
>>> steep learning curve to get anything at all done. So clearly something
>>> must be done to make using GRASS easier for average and casual users.
>>> But, as you are developing a vision for the next-generation GRASS, I
>>> would urge you to consider a model more like Matlab, Mathematica or R
>>> (etc.) rather than ESRI's ArcGIS. In all of the former programs there
>>> is a nice GUI wrapping a CLI interface. Things like interactive plots,
>>> menus, etc are available to ease users into the program, but the key
>>> interface is not a GUI, it is an "enhanced" command line.
>>> 
>>> The advantage of this format is that new users get the hand-holding
>>> they need, it is easy to make visual changes to plots, etc.,
>>> infrequently used features are wrapped in wizards etc., but crucially,
>>> there is no fundamental difference between casual use and advanced
>>> use. Full automation is available from the CLI or from a script and
>>> they use EXACTLY THE SAME COMMANDS...nothing new to learn.
>>> 
>>> Compare the matlab model with ArcGIS. ArcGIS was designed to be a
>>> GUI-first system after the huge success of ArcView. After more than 7
>>> years on the market ESRI is still distributing ArcInfo. Why? In part,
>>> I think, because it is orders of magnitude more difficult to automate
>>> the new interface and advanced users refused to use ArcObjects (VB or
>>> C++) to do it. ESRI relented in the latest version (9.X) and has
>>> bolted on a Python interface and a GUI model builder that go part-way
>>> to restoring the automation capabilities lost, but I assure you that
>>> ArcInfo will continue to be popular until the CLI in ArcGIS matures
>>> into a first-class interface.
>>> 
>>> To me the lesson is that GIS (like math software) is extremely
>>> complex. To be useful it also needs to be extremely flexible. GUI's
>>> have the fundamental shortcoming that a designer has to anticipate
>>> every possible use scenario in order to provide appropriate buttons
>>> and panels. Advanced users will be hamstrung if the interface doesn't
>>> support flexibility. The CLI for all of its initial shortcomings is
>>> very easy to automate, easy to combine with other programs in ways not
>>> anticipated by the program designers...in short, flexible. (I am
>>> thinking here of your suggestion to remove the d.* commands in favor
>>> of an enhanced monitor GUI)
>>> 
>>> I would like to see a GUI wrapped around the CLI to cover things like
>>> setting up program directories, default environments, etc. It would be
>>> useful to have a GUI wrapped around the monitors for zooming,
>>> printing, moving objects on the display, etc. But I think that the
>>> design should be towards making the CLI easier to use rather than
>>> trying to replace it or hide it.
>>> 
>>> My 2 cents (more like a couple of bucks...)
>>> 
>>> --
>>> David Finlayson
>>> Marine Geology & Geophysics
>>> School of Oceanography
>>> Box 357940
>>> University of Washington
>>> Seattle, WA  98195-7940
>>> USA
>>> 
>>> Office: Marine Sciences Building, Room 112
>>> Phone: (206) 616-9407
>>> Web: http://students.washington.edu/dfinlays
>> 
>> 
> 
> 
> --
> David Finlayson
> Marine Geology & Geophysics
> School of Oceanography
> Box 357940
> University of Washington
> Seattle, WA  98195-7940
> USA
> 
> Office: Marine Sciences Building, Room 112
> Phone: (206) 616-9407
> Web: http://students.washington.edu/dfinlays