[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