[moving this to the grass-dev list..]
Glynn:
FWIW, I'm planning to remove ps.map from 7.x.
Equivalent functionality will be available through d.*
commands.
any reason other than redunancy?
It is highly useful to some and currently outpaces d.* for quality.
Duplicate functionality is only a reason if:
a) it does a worse job for the task (debatable->personal choice), or
b) it distracts the developer pool too much from working on new things.
c) adds too much bulk
none of which are the case, IMO. it does a good job and the code hardly changes (I think I'm the only one who actually works on it). It doesn't touch anything outside its directory and the code is a fairly small portion of the overall tarball.
i.e., what is the cost of leaving it there for those who depend on it?
AFAICS the primary thing it lacks is a nice GUI frontend composer.
Hamish
Hamish wrote:
> FWIW, I'm planning to remove ps.map from 7.x.
>
> Equivalent functionality will be available through d.*
> commands.
any reason other than redunancy?
Partly redundancy, mainly to ensure that people complain about any
deficiencies with the alternative.
It is highly useful to some and currently outpaces d.* for quality.
Just about anything currently outpaces d.* for quality. That will
change once the graphics architecture is re-written.
Duplicate functionality is only a reason if:
a) it does a worse job for the task (debatable->personal choice), or
b) it distracts the developer pool too much from working on new things.
c) adds too much bulk
The main reasons are b) and:
d) it distracts the user pool from testing new things.
Essentially, if ps.map is left, it will "steal" both developers and
testers from d.*, which (AFAIK) is still the primary mechanism for
graphics.
[Unless you're planning on entirely replacing d.* with ps.map, in
which case ps.map is going to have to become a great deal simpler
(code-wise) and more flexible.]
--
Glynn Clements <glynn@gclements.plus.com>
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
Hamish ha scritto:
enjoys choices and working on clunky old sports cars,
talking about choices and duplication, please note that work is also
well underway for a new printing mechanism for qgis
https://trac.osgeo.org/qgis/browser/branches/advanced_printing_branch
due probably in a month or two, I guess.
all the best.
pc
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *