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@u.washington.edu>
Reply-To: <dfinlays@u.washington.edu>
Date: Sun, 06 Nov 2005 20:16:18 -0800
To: Michael Barton <michael.barton@asu.edu>
Subject: Re: Developing a New Grass UIBy 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@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-2402phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbartonFrom: David Finlayson <dfinlays@u.washington.edu>
Reply-To: <dfinlays@u.washington.edu>
Date: Sun, 06 Nov 2005 19:08:22 -0800
To: <michael.barton@asu.edu>
Subject: Developing a New Grass UIMichael -
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
USAOffice: 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
USAOffice: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays