[GRASS-dev] porting r.in.wms to python

[Michael Barton]

On Oct 8, 2008, at 6:38 PM, <grass-dev-request at lists.osgeo.org> wrote:

> Date: Wed, 8 Oct 2008 23:50:12 +0100
> From: Glynn Clements <glynn at gclements.plus.com>
> Subject: Re: [GRASS-dev] porting r.in.wms to python
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass-dev at lists.osgeo.org
> Message-ID: <18669.14628.849746.322999 at cerise.gclements.plus.com>
> 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