[GRASSLIST:7816] Re: Synergy between Grass/Python/GMT revisited

[Glynn Clements]

David Finlayson wrote:

> Ultimately, GRASS's postscript/presentation facilities should be
> enhanced. I can't help with that right now because I don't know
> postscript (truthfully, I don't really know C that well either!).

I'm reasonably familiar with PostScript.

> > Making hard copy maps is such an important part of any research project
> > that deals with the spatial arrangement of object -- and yet there are
> > not many ways of doing it efficiently with open source software. GMT
> > provides a means to get the heavy lifting done, however the creation of
> > complex maps  from multiple sources can be a bear. In addition, getting
> > data from GRASS into GMT can be somewhat of a headache, especially
> > vector data.
> 
> Ultimately, GRASS's postscript/presentation facilities should be
> enhanced. I can't help with that right now because I don't know
> postscript (truthfully, I don't really know C that well either!). One
> day I'll have the time to start hacking on that...

It would take a long time to catch up to GMT, and I'm not sure there's
much point in duplicating all that effort. It seems (to me) to make
more sense to leverage what GMT already provides by making it easier
to export data from GRASS into GMT. The reverse isn't nearly as
useful.

Although some of the more fundamental features should be implemented
directly. E.g. r.out.ps, v.out.ps.

The main issue is that the flexibility of PostScript means that there
are an unlimited number of options which you could reasonably
implement, e.g. line and fill styles, text formatting etc. We need to
avoid trying to implement too much.

> > 1. monolithic or modular?
> 
> Definitely modular. GRASS's real strength is it's Unix heritage. One
> tool does one thing well, pipe the tools together.

Agreed.

Personally, I'd prefer PostScript versions of the main d.* commands
rather than something like ps.map.

The hardest part is designing the framework. Actually implementing a
program which reads a raster and emits PostScript is simple enough.

> > I can provide a place to post this discussion, and any progress via our
> > lab's content management system.

The actualy discussion should ideally occur on the development list
(grass5 at grass.itc.it) and/or here.

-- 
Glynn Clements <glynn at gclements.plus.com>