[GRASS-dev] discussion: replacing ps.map

[Trevor Wiens]

On Tue, 27 Mar 2007 22:22:26 +0100
Glynn Clements wrote:

> 
> Jachym Cepicky wrote:
> 
> > while ps.map is nice tool for creating hard copy maps in GRASS, it is
> > not sufficient for some more complicated tasks and correct me if I'm
> > wrong, there is no _real_ maintainer of it's code, who would be able
> > to write new functions for it.
> > 
> > Now, when new wxPython GUI is stepping forward, I'm thinking about,
> > how to write future GRASS mapcomposer.
> > 
> > I see two interesting tools in today's FOSS4G world, which could be
> > used as back end for new Mapcomposer, and which would so replace
> > functionality of ps.map:
> > 
> > 1) UMN MapServer
> > 2) GMT
> 
> > Both solutions are introducing new dependency. The benefit would be
> > "outsourcing" of our efforts. Why to reinvent a wheel, if there are
> > already tools, which are able to produce nice maps, tested and used?
> > 
> > What do you think? Any experience with some of this tools? I would
> > vote for MapServer.
> 
> I have no experience with MapServer. I have a bit of experience with
> GMT, and am subscribed to its mailing list.
> 
> I don't think that we should try to "integrate" GMT with GRASS beyond
> facilitating export of GRASS data to formats which GMT supports.

I agree with this point. GMT is useful, but fairly limited. For example
right now I'm using GMT to produce a very large number of maps for a
book and it works OK, but in order to get islands to display properly I
would have to manually edit the vector file. This is poor beyond words.
As a result, I've just rendered those river sections using thicker
lines and not bothered to fill them, because it was just to much
hassle to try to find all the river islands in the GMT xy file. If we
can improve export to GMT formats, that would be nice, in the short
term, but there must be postscript generation in process colours from
directly within GRASS. As Dylan says, GMT isn't perfect (IMHO it is
pretty horrible actually) but it is the best we've got right now.

> 
> I do think that we should provide our own facilities for generating
> PostScript, and that ps.map isn't a particularly good tool. I would
> much prefer a set of distinct tools, analogous to the d.* commands,
> which output specific types of graphics as PostScript, and leave the
> composing mainly to external tools such as Illustrator or psutils.

I completely disagree with your point about composition. This is the
common approach taken, but if one looks at the latest offerings from
ESRI for professional map creation, the advantage of not having to
switch formats to something that isn't geographic becomes obvious. The
level of composition required for professional map composition isn't so
demanding that if we are going to build functions to do insets,
legends, etc, that the additional functionality would be that much
further a stretch as to be unattainable.

> My first preference is to enhance the graphics architecture so that
> d.* commands can generate PostScript. But this requires some
> fundamental architectural changes which can't happen in the 6.x
> timeframe.

This brings up a point worth thinking about. There has been much
discussion about the current image rendering in GRASS, which right now,
generates an image and displays it. People have discussed direct
drawing of vectors, etc. Now as Glynn has pointed out in the past, ps
isn't designed for fast rendering, but if display ps files were kept to
low enough resolutions, the speed of display would still be pretty fast
and then there would be no need for two library options. The quality of
the basic output could be adjusted and other tools could be used to
convert the eps or ps files to images as needed. Now this may not work,
but some time tests might be worth doing to see how much of a penalty
would be paid for taking this approach. 

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)