On Oct 8, 2008, at 6:38 PM, <grass-dev-request@lists.osgeo.org> wrote:
Date: Wed, 8 Oct 2008 23:50:12 +0100
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] porting r.in.wms to python
To: Michael Barton <michael.barton@asu.edu>
Cc: grass-dev@lists.osgeo.org
Message-ID: <18669.14628.849746.322999@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-asciiMichael 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.
OK. This is more sophisticated than I was what I was thinking of. More work, but probably much better in the long run--whether we use this library or an in-house one. My primary concern is that there are a number of situations in GRASS where we need graphs, and we have not had a consistent or flexible solution to making them. I'm supportive of anything that moves toward an improvement of that situation.
Michael
Michael