[GRASS-dev] porting r.in.wms to python
Glynn Clements
glynn at gclements.plus.com
Wed Oct 8 18:50:12 EDT 2008
Michael Barton wrote:
> >> However, I
> >> suggested that matplotlib might be quite suitable for this kind of
> >> task. It is a free, pure Python library that can do very
> >> sophisticated
> >> graphing very easily. It can be 1) wrapped into the GUI display, 2)
> >> set to create it's own simple display in a couple of GUI toolkits, or
> >> 2) set to output to a graphic file. It is scriptable. I submitted a
> >> couple of test scripts to show how this might be accomplished.
> >
> > We would need to determine how to make it respect the various
> > environment variables so that commands which use matplotlib can be
> > mixed with those which use the display/raster libraries.
>
> Sorry, but I don't understand. It is an external library (like
> gnuplot, but seems a bit easier to work with for me at least). It can
> plot to graphic files or a display canvas it creates, OR it can be
> included in the GUI (though this takes somewhat different programming
> to make it plot to the GUI display canvas). It was fairly easy to
> include this in scrips. But maybe you are thinking of using it in a
> more sophisticated way than I am.
The intention is to have a single graphics architecture whose
components can be combined in arbitrary ways. Not a bunch of disparate
scripts, generating different formats, recognising different options,
using different sets of fonts, etc.
AFAICT, we would need either a wrapper around matplotlib so that it
honours all of the GRASS_* variables related to graphics, or a
matplotlib "backend" which uses the display library.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list