On Oct 8, 2008, at 6:38 PM, <[EMAIL PROTECTED]> wrote:
Date: Wed, 8 Oct 2008 23:50:12 +0100
From: Glynn Clements <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] porting r.in.wms to python
To: Michael Barton <[EMAIL PROTECTED]>
Cc: grass-dev@lists.osgeo.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
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.
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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
