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

[Michael Barton]

David,

Making final, complete publication quality map output has never been a
strength of GRASS. The first script I wrote, d.out.png, was a result of
frustration at having so few options of getting output from GRASS. It's
major strengths has been as a research, analysis, and modeling package. The
main way to do nice output has been to dump GRASS display to a graphics file
and work on it in that. This is not such a bad model, given that very nice
graphics layout and high-quality decorations requires quite a bit of
programming to achieve. So it's not that bad an idea to leave it to InkScape
or similar program to do that.

That said, we are closer now to having publication-quality output than ever
before. A simple example of this is that postscript text can now be added to
the display. 

However, doing more of this will either involve a more sophisticated
text/command file method like now in ps.map and gmt, or much heavier use of
a GUI platform for text, decorations, and vectors. Improvements to the first
method are not closely tied to the GUI, but require more enhancements to
ps.map (quite a bit has been done in this regard over the past year). For
the 2nd method, text and decorations are relatively straightforward, created
in the same way as the zoom boxes and postscript text is now done in the GIS
Manager. It just takes some programming drudgery, but this is the way that
most people will want to make higher quality maps so it will need to be
done. 

I've simply been too tied up with getting other parts done (profiler,
georectifier, legend for thematic maps, etc) to rewrite the GRASS decoration
display modules into TclTk (all were written to render in what is now
considered a low-resolution display). If we are switching to a new GUI
platform, I'd rather put the effort into doing nice display decorations in
the new platform.

The real sticker is vector rendering. Currently, vectors display just like
rasters. Changing this requires changing how vector information is sent to a
display. Different models for doing this are being worked on. An example is
Jachym's prototype v.pydigit. One reason for a new GUI platform is that it
could make more versatile visualization easier than it is under TclTk.

How far to take this is another matter. Good cartographic output and layout
requires a whole 'nother layer of programming on top of the display
interface. It's generally done poorly in GIS packages for that reason.
ArcGIS is finally getting close to something that works pretty well--after
how long?--and this is an important component of its business. It's a good
idea and it would be great if someone is willing to tackle it. However, I'd
simply like to first get the current design into a new platform over the
next year before we invest additional effort in adding new major interface
features. For an alternative idea, it might be worth looking at the Cavnas
(commercial graphics program) model. Add rudamentary GIS capabilities in a
plugin to a good drawing or layout program like InkScape or Scribus, so that
GRASS output or even GIS files could be brought into these for high-quality
output. Just a rambling thought.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

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



> From: David Finlayson <david.p.finlayson at gmail.com>
> Date: Thu, 8 Jun 2006 21:55:35 -0700
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: grass-dev Digest, Vol 2, Issue 19
> 
> As far as I am concerned, there are more pressing issues for GRASS than the
> GUI.
> 
> #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.
> 
>