[GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19

[Trevor Wiens]

On Thu, 8 Jun 2006 21:55:35 -0700
"David Finlayson" <david.p.finlayson at gmail.com> wrote:

> As far as I am concerned, there are more pressing issues for GRASS than the GUI.

I disagree. See below.

> #1. is an (optional) portable shell that doesn't require (but doesn't
> inhibit) a UNIX back end
> #2. is a complete face-lift to the map production capabilities of GRASS.
> 
> I recently designed several large-format maps for a public display of
> our mapping capabilities (coastal USGS). I found that I didn't have
> the control or flexibility I needed in GRASS to do the maps the way I
> wanted. ps.map just isn't very powerful yet. I regressed to
> ArcGIS/Illustrator for the first time in over a year :(
> 
> I think it was possible, just too difficult to script the rgb > his
> transformations in the short time I had available. Also the map
> decorations I needed just weren't available in GRASS.

Cartography is a weakness throughout GIS in general, not only GRASS.
The fact that it is still normal to pull GIS output into drawing
programs to make it acceptable is an embarrassment. However to generate
professional output efficiently, both scripting and interactive
controls are needed. Setting colours and themes and layers are obvious
in a well designed config file and command combination (BTW I hate GMT
with its multiple commands for every layer; so tedious), but layout and
legend placement is more difficult, but labels absolutely require both a
scripting capability to allow for automated label placement algorithms
(eg simulated annealing) and then an interactive environment to catch
what is lost and possibly allow for drawing program features like bezier
curves and fitting text to curves. In addition, these labels must be
defined in terms to the size of the printed document but linked to the
underlying geography to allow for expansion or shifting of the
underlying geographic region without having to start over. What is
needed is a environment where the output is "What You See Is EXACTLY
What You Get" not "WYSI sort of WYG". To me this means interactive
display and editing of postscript; this AFAIK is not trivial. 

Thus it is clear that to answer the question of cartography, both more
powerful CLI modules are needed as well as top notch GUI. 

In Michael's other reply which has just been posted as I write, he
mentions the concept of using a plugin for Inkscape, etc to allow for
this type of capability. I'm not sure it is the best solution but
definitely a step in the right direction. There is a commercial
application called Canvas which is in process of adding more and more
geographic capabilities into a pretty nice drawing program. This is
definitely much better than just about anything else out there for
people who don't have 5 figures or more to spend on cartographic
software.

Now to the shell...

Interesting idea. I've never used Matlab but I have some experience
with R and I never use the GUI because it sucks (IMAO); it is easier
to just code what I need. In fact, however I dislike the R language so I
use RPy and only write the functions I needed to in R and script
everything in Python. It is slower to run, but much quicker to code
for me.

The concept of providing an obvious link between the GUI and the CLI is
a good one. GIS is by its nature visual, much more so than statistical
analysis (IMHO) so I'm not sure that the Matlab or R paradigm is the
right one. One of the things that I've discussed with Michael B. off
list is the toolbox concept. The big problem with modern GUI software
is menu hell; sprawling menus that go on and on and on. Anytime you
want to do anything it takes forever to find where that thing was which
you did last month.... Drawing programs have used the toolbox
abstraction quite successfully and I think it is potentially very
useful for GIS and GRASS. The current command listing is certainly a
step in the right direction and I wonder about using a toolbox where
users can choose the display to be either icons, icons and text,
icons and command names, or just command names. In this way providing
baby steps to users who have been ignoring the commands listed in the
command window when the pointed and clicked. A proper GUI integrated
with a nice CLI (I like the idea of a Python shell, but we need to
allow for different shells such as bash, etc.) is in my mind a good
vision for GRASS and I think the one we already working toward.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)