[GRASS-dev] Re: [GRASS-user] ps.map dilemma

[Hamish]

Glynn:
> > > FWIW, I'm planning to remove ps.map from 7.x.
> > >
> > > Equivalent functionality will be available through d.*
> > > commands.
Hamish:
> > any reason other than redunancy?
Glynn:
> Partly redundancy, mainly to ensure that people complain
> about any deficiencies with the alternative.

ok. As d.* is the main track and ps.map is mostly a periphery I wouldn't
get too worried about that. But I really have no idea how many people
use ps.map versus d.out.file/Cairo, or the PNG driver, or QGIS, or ..
You are correct in that I expect the hard core ps.map users will probably
be among the better/noisier testers for the next generation d.* PS driver.

FWIW once grass7 goes mainstream if I still need ps.map for work, I'll
port it (can't afford downtime, etc). The question then becomes whether
to include it [back] in the main distro or keep it as an addon. I don't
see much point in debating that too much until both grass7 and the port
actually exist.


wrt ps.map usability: In my experience, once you have spent the time to
learn how to use it, ps.map rocks for publication quality stuff- where you
don't mind throwing in a bit more time. Maybe "oh, just edit the PostScript file by hand to fix that" is a bit over the top, but part of my point in
doing that is to show that it really isn't that scary, it's just a text
file with commands in it and the user is in charge. I will try and add a
few more tips&hints onto the wiki page.

wrt GMT: perhaps the output is more refined, but the learning curve and
command line comfort is about the same and the integration not as good
so far. I look forward to seeing improved *.out.gmt scripts and hope the
ones we have now can be consolidated. Maybe a nice (albeit perhaps
off-topic enough to not make the cut) Google Summer of Code project for
next year would be to improve GRASS<->GMT flow.


enjoys choices and working on clunky old sports cars,
Hamish