[GRASS-dev] discussion: replacing ps.map

[Glynn Clements]

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 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.

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.

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